Amazon ECR: 6 Habits That Keep Your Container Images Fast, Small, and Secure
Six small ECR habits I follow — lean images, immutable tags, scan-on-push, and lifecycle cleanup — that cut pull times and kill zombie images eating my storage.
My ECR repositories used to look like a junk drawer. Every image ever pushed stayed there forever, tags were a mess, and pulls took ages because each image was over a gigabyte. It cost me storage money and deployment time. Six small habits fixed it.
**1. Keep images lean — multi-stage builds or it didn't happen**
Build in one stage, ship in another. Copy only your compiled artifact and runtime deps into the final image. I went from 1.2 GB Node images to under 200 MB by starting from the slim runtime image instead of the full SDK one. Smaller images pull faster, scan faster, and cost less to store.
Build in one stage, ship in another. Copy only your compiled artifact and runtime deps into the final image. I went from 1.2 GB Node images to under 200 MB by starting from the slim runtime image instead of the full SDK one. Smaller images pull faster, scan faster, and cost less to store.
**2. Tag immutable, never mutable-latest**
Turn on tag immutability in ECR. If `:latest` can be overwritten, you can never reproduce a broken deploy. I use `appname-<git-sha>` tags for deploys and keep `:latest` as a pointer only. This one setting has saved me from "works on my cluster" arguments more than once.
Turn on tag immutability in ECR. If `:latest` can be overwritten, you can never reproduce a broken deploy. I use `appname-<git-sha>` tags for deploys and keep `:latest` as a pointer only. This one setting has saved me from "works on my cluster" arguments more than once.
**3. Scan on push, read the report before prod**
Enable "scan on push" so every image gets a vulnerability scan automatically. The scan won't fix anything for you, but it turns "I hope this base image is fine" into a list you can actually act on. I check the scan tab before promoting anything to production.
Enable "scan on push" so every image gets a vulnerability scan automatically. The scan won't fix anything for you, but it turns "I hope this base image is fine" into a list you can actually act on. I check the scan tab before promoting anything to production.
**4. Set a lifecycle policy on day one**
An ECR repo without a lifecycle policy is a storage bill that only grows. Mine keeps the last 10 tagged images per repo and expires untagged images after 7 days. It took five minutes to write and quietly deletes hundreds of stale images a month.
An ECR repo without a lifecycle policy is a storage bill that only grows. Mine keeps the last 10 tagged images per repo and expires untagged images after 7 days. It took five minutes to write and quietly deletes hundreds of stale images a month.
**5. Cross-region replication only where you actually run**
Replicating every repo to every region is the easiest way to multiply your storage cost. I replicate only the repos that real production workloads in those regions pull from. Everything else stays in the build region.
Replicating every repo to every region is the easiest way to multiply your storage cost. I replicate only the repos that real production workloads in those regions pull from. Everything else stays in the build region.
**6. Cache smart in CI, not harder**
In my CI pipeline I pull the previous build's image as a cache source so Docker reuses unchanged layers. Combined with lean images, my build times dropped by roughly half. The flag costs nothing; it just needs to be set.
In my CI pipeline I pull the previous build's image as a cache source so Docker reuses unchanged layers. Combined with lean images, my build times dropped by roughly half. The flag costs nothing; it just needs to be set.
**Key takeaways**
- Multi-stage builds are the single biggest lever for image size and pull time.
- Immutable tags make deploys reproducible and rollbacks sane.
- Scan-on-push plus lifecycle policies turn ECR from a junk drawer into a managed pipeline.
- Only replicate what you run, and let layer caching do the heavy lifting in CI.
ECR is free to start and quiet to ignore. Ten minutes of setup — immutability, scan-on-push, lifecycle policy — pays you back every single deploy.
- Multi-stage builds are the single biggest lever for image size and pull time.
- Immutable tags make deploys reproducible and rollbacks sane.
- Scan-on-push plus lifecycle policies turn ECR from a junk drawer into a managed pipeline.
- Only replicate what you run, and let layer caching do the heavy lifting in CI.
ECR is free to start and quiet to ignore. Ten minutes of setup — immutability, scan-on-push, lifecycle policy — pays you back every single deploy.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article