Prevent Tag Override

Tag immutability forces each image under the repository to have a unique tag, which can’t be overridden after push. Having a unique association between the image and tag is an important feature for production environments because you want to be sure that the images you have deployed on your clusters (EKS, ECS, EC2) are the same images you have stored on your ECR repository. As it doesn’t allow us to push a new image with an existing tag, it’s considered a security feature.

Supply chain attack example

Let’s imagine a scenario where an attacker gains access only to the ECR repository, with permissions to push images, but the attacker doesn’t have access to the container platform; one thing he/she can do is modify a production image to inject some malicious code, and wait until a new instance of the service is launched using the poisoned image. This is a very common scenario nowadays since a simple autoscaling event could trigger the deployment of new resources.

CRR: Cross-Region Replication

Cross-region replication is designed to replicate the repository images across regions. As you can imagine, the main focus of this feature is to implement a DR (Disaster Recovery) strategy in the production repositories. When enabled, each image pushed to the repository, will be replicated across all the repositories specified in the configuration, as simple as it sounds.

Of course, nothing is free, and cost is an important factor to consider as well. You need to take into consideration the balance between your DR strategy and the cost of storing the replicas across different regions. AWS only bills the storage of the images, but not the replication itself.

There are a few things to consider when enabling CRR:

• Images that were stored before enabling the replication won’t be replicated automatically; it needs to be done manually.

• The repository name must be the same across regions.

• The service doesn’t allow to chain replication rules. For example, if you have a rule to replicate from us-east-2 to us-east-1, and another rule for replicating from us-east-1 to us-west-2, only the first image push (from us-east-2 to us-east-1) will be replicated.

• Repository settings, resource-based policies, and lifecycle rules aren’t replicated. They only apply to the repository where they’re configured.

Replicating to a different account is supported as well; this is useful when you have a specific account for storing backups, separated from the production account.

The replication rules allow the use of prefixes to filter repository names, so for example, you can create a rule to replicate all the repositories that start with prod .

Example

Supposing that the account where you have your main repository is 111122223333, let’s configure a rule for replicating all the repositories starting with prod, to the regions us-east-1 and us-east-2 in the account 444455556666 :

{
  "rules": [{
    "destinations": [{
      "region": "us-east-1",
      "registryId": "444455556666"
    }],
    "repositoryFilters": [{
      "filter": "prod",
      "filterType": "PREFIX_MATCH"
    }]
  },
  {
    "destinations": [{
      "region": "us-east-2",
      "registryId": "444455556666"
    }],
    "repositoryFilters": [{
      "filter": "test",
      "filterType": "PREFIX_MATCH"
    }]
  }
  ]
}

{
  "rules": [{
    "destinations": [{
      "region": "us-east-1",
      "registryId": "444455556666"
    }],
    "repositoryFilters": [{
      "filter": "prod",
      "filterType": "PREFIX_MATCH"
    }]
  },
  {
    "destinations": [{
      "region": "us-east-2",
      "registryId": "444455556666"
    }],
    "repositoryFilters": [{
      "filter": "test",
      "filterType": "PREFIX_MATCH"
    }]
  }
  ]
}

Control Who Can Push

Controlling access to the ECR repository is crucial, especially for production images. AWS ECR lets you define resource-based policies (like S3 bucket policies) for your repositories. In other words, it allows putting the permissions control closer to the container images.

Resource-based policies allow you to specify which users/roles can access your images, which actions they can do, and under what conditions. It has the same syntax and almost all features of IAM policies, but the difference lies in where the policy is applied; while IAM policies are applied directly to the entity (user or roles), the resource-based policies are applied to the resource itself (as its name suggests).

In a production ECR repository, you may want only your CI system to be able to push images to the repository so you can be sure that the image was built by a trusted source that your company controls. To implement this strategy, you can make use of repository policies.

Example: Only allow CI build users to push images

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushFromCI",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::account-id:user/ci-build-user"
        ]
      },
      "Action": [
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ]
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushFromCI",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::account-id:user/ci-build-user"
        ]
      },
      "Action": [
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ]
    }
  ]
}

Scan Images for Vulnerabilities

Scanning your images stored helps you identify (and remove) images that have vulnerabilities inside them. ECR offers two types of scanning, and the main difference is that one includes only the OS software packages scanned (basic), and the other includes OS packages plus the software packages deployed on the image (enhanced).

Basic

The basic scanning uses the CVE database to classify the vulnerable software, and in the case it’s not available, it assigns a score based on CVSS (Common Vulnerability Scoring System). It supports only scanning OS packages, and it doesn’t scan the application software running in the container.

When using basic scanning, you can enable the scan-on-push, or you can do manual scans whenever you decide. Both solutions use the same scanning database, the only difference is the triggering of the scan process.

Enhanced

The enhanced scanning uses the Inspector service behind the scenes, and this means it uses a different database to classify the vulnerabilities. Inspector not only scans your OS packages, but it also includes your programming language packages.

With enhanced scanning, you can choose the frequency at which your container images are scanned. It allows you to choose between continuous scanning or scan-on-push. ECR lets you specify the scanning configuration on the registry, and the frequency can be set as filter rules

Example of scanning configuration with filter rules:

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{"repositoryFilters" : [{"filter":"prod","filterType" : "WILDC
  --region us-east-2

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{"repositoryFilters" : [{"filter":"prod","filterType" : "WILDC
  --region us-east-2

Encryption

ECR uses the S3 service as the backend for storing the container images. By default, it uses encryption-at-rest with Amazon S3-managed encryption keys, which encrypts the data at rest using the AES-256 encryption algorithm. The service provides this at no additional cost.

You can also use a different service-side key using the KMS (Key Management Service) keys. When using KMS, you can choose between the default AWS-managed key, which is managed by the ECR service, or specify your own KMS key, known as a customer-managed key (CMK).

Image Promotion

Having multiple environments and promoting the new image version across them is a common scenario everyone faces. As you can imagine, good and bad practices for promoting images exist.

If I had to name the #1 anti-pattern, it would be rebuilding the image for every environment; in a healthy environment design, you should build once and deploy multiple times, so rebuilding images is not the best strategy in terms of cost and environment parity. Keeping your environments as similar as possible is considered one of the best practices for building and testing modern applications (or old ones as well).

The solution is very easy: you need to be sure that the same image version is deployed across the environments (dev, QA, Prod). Depending on how you configured your ECR repository, you can use the tag or image SHA to reference the container. In case you don’t have the tag immutability enabled, you should use the SHA of the image to reference the deployment.

Using this strategy has a few benefits:

• Environment disparity is easy to spot: You just need to check what image is deployed across environments.

• Rollback is easy: It only requires a deployment pointing to the previous version of the container.

Conclusion

Getting Amazon ECR to a production-ready state requires more than just storing container images. It involves applying the right mix of automation, access control, lifecycle management, and security best practices. By proactively addressing these areas, you lay the groundwork for more reliable, scalable, and cost-effective deployments.

At Betta, we help teams like yours design and implement container strategies that follow AWS best practices—without adding complexity. If you're looking to make your ECR setup production-ready (or aren’t sure where to start), we’d love to talk.