ECR

On this page

• Coverage by target cloud
• How the targets compare
  • Infrastructure-only adaptation
• On Google Cloud
• On Azure
• On OCI
• On Private Kubernetes
  • Via Zot Registry
  • Via Distribution Registry
  • Via Harbor Registry

​

Coverage by target cloud

​

How the targets compare

Each row compares a capability of ECR with its adaptation on each target. A dash means this row is not stated for that target.

​

Infrastructure-only adaptation

​

On Google Cloud

​

How it works

On AWS your build pushes container images to Amazon ECR and your workloads pull from it. Google Artifact Registry is Google Cloud’s unified artifact service: one system that hosts many package formats, governs access with per-repository IAM, and integrates with VPC Service Controls and customer-managed encryption. At the build, Tensor9 reads your ECR repositories and provisions a Docker-format Artifact Registry repository for each one; afterward your own docker push and docker pull reach it directly, without routing image traffic through Tensor9. The image itself never changes. ECR and Artifact Registry both speak the OCI Distribution v2 protocol, so your image manifest, its layer blobs, and their content digests are byte-identical on both sides; docker and containerd are untouched. The target reference includes the <location>-docker.pkg.dev host, project, repository and image path. This mapping provisions a target registry and updates image references. Docker and containerd use the target’s registry protocol and credentials. It does not provide the AWS ECR management or authorization-token API. Applications that call ECR directly, including GetAuthorizationToken, need a separate integration.

Your ECR repositories are provisioned as Docker-format Artifact Registry repositories at the build; afterward your push and pull reach them directly and the image is unchanged.

​

Artifact Registry features

Artifact Registry hosts Docker/OCI images alongside Maven, npm, Python, Apt, Yum, and Go artifacts, so a container registry and a language-package registry are one system. Your ECR repositories map to Docker-format repositories, one per ECR repository, so the per-repository topology is preserved. Access is per-repository IAM, with read and write roles bound at the repository level rather than a single registry-wide policy. GKE pulls images using the node pool’s IAM service account, including when Workload Identity Federation is enabled for applications. Grant that node identity Artifact Registry Reader on the target repository. Remote repositories act as a pull-through cache of an upstream, and virtual repositories aggregate several repositories behind one endpoint. VPC Service Controls place the registry inside a service perimeter, and customer-managed encryption keys (CMEK) encrypt contents with your own Cloud KMS keys. Cleanup policies apply keep/delete rules per repository. For a repository containing one image package, an unfiltered count policy keeps the ten newest versions by combining a delete rule for all versions with a keep rule for the ten most recent. Keep rules take precedence. This count mapping requires mutable tags, one count rule, and a version population whose target creation order matches its source push order. A single unfiltered age rule maps to a delete rule only when source and target age clocks agree. Additional image packages, tag selectors and overlapping ECR rules need a separate policy review; the target cleanup rules do not encode every ECR rule.

Artifact Registry package formats, authentication, and retention.

​

Limitations

△ Where ECR and Artifact Registry stay different

• Access control is Google IAM. Image pulls use the node identity or separately configured registry credentials; the permission model is per-repository IAM rather than ECR resource policies.
• Scanning moves to Artifact Analysis. On-push and continuous analysis replace ECR’s enhanced scanning, with its own coverage and cadence.
• Lifecycle rule languages differ. The count/age mapping covers one image package with no tag filter or overlapping priorities. ECR requires all listed tag selectors to match; Google prefix lists match any prefix. Google recent-count rules cannot also select tagged or untagged versions. Keep wins over delete, and immutable tagged versions cannot be deleted. Target age starts at creation in Artifact Registry; source image ages and archive transitions are not preserved.
• ECR destination replication is not mapped. Multi-region storage does not select ECR destination regions or accounts. Remote repositories cache on the first pull and need their upstream for uncached content. Virtual repositories aggregate upstreams in the same region or multi-region; neither mechanism supplies destination push replication. Deliver required regional copies through your pipeline.

​

Other considerations

Plan image delivery, credentials, and storage costs for the target registry.

• Push images from your build pipeline: the build creates one Docker-format Artifact Registry repository per ECR repository; your pipeline repoints to <location>-docker.pkg.dev and pushes, since the image data path stays yours.
• Authorize the image-pulling identity. Grant the GKE node service account read access to the target repository, including for cross-project pulls. Application workload federation does not grant this node permission.
• Review retention before deletion. Use Artifact Registry’s cleanup dry run to inspect the versions selected by the keep/delete policy. Preserve deployment and rollback images, and review policies outside the single-image-package count/age mapping separately.
• Deliver regional image copies explicitly. Push the required digests to each selected target repository. A multi-region location or an uncached remote repository does not replace the ECR destination rule set.
• Storage and network egress are billed. Artifact Registry bills for stored bytes and network egress rather than an ECR-style model, and CMEK ties contents to your Cloud KMS keys if you enable it.

​

On Azure

​

How it works

On AWS your build pushes container images to Amazon ECR and your workloads pull from it. Azure Container Registry is Microsoft’s managed OCI registry, with a tiered service model (Basic, Standard, Premium), Microsoft Entra identity, and, on Premium, geo-replication, content trust, and private networking. At the build, Tensor9 reads your ECR repositories and provisions an Azure Container Registry to match; afterward your own docker push and docker pull reach it directly, without routing image traffic through Tensor9. The image itself never changes. ECR and Azure Container Registry both speak the OCI Distribution v2 protocol, so your image manifest, its layer blobs, and their content digests are byte-identical on both sides; docker and containerd are untouched. The target reference uses <registry>.azurecr.io and the mapped repository path. Registry administration and policy differences are described below. This mapping provisions a target registry and updates image references. Docker and containerd use the target’s registry protocol and credentials. It does not provide the AWS ECR management or authorization-token API. Applications that call ECR directly, including GetAuthorizationToken, need a separate integration.

Your ECR repositories are provisioned as an Azure Container Registry at the build; afterward your push and pull reach it directly and the image is unchanged.

​

Azure Container Registry features

Azure Container Registry offers Basic, Standard, and Premium tiers. The Basic, Standard, and Premium SKUs scale storage, throughput, and features, with Premium providing additional features: geo-replication turns one registry into a set of regional replicas behind a single login server, so each region pulls locally; content trust lets you push and enforce signed images; and ACR Tasks build and patch images inside the registry, including automatic rebuilds when a base image changes. For AKS image pulls, grant the kubelet managed identity access to the registry. Use AcrPull for a registry using the conventional RBAC model, or the repository-reader role required by an ABAC-enabled registry. Other clusters can use an imagePullSecret. The application’s workload identity is separate from the identity that pulls its image. Private Link keeps the registry on a private endpoint. A single Azure Container Registry holds many repositories as paths beneath one host. ECR also groups repositories within an account-and-region registry. Tensor9 provisions one ACR registry for the repository set and rewrites each image reference to its target repository path.

Azure Container Registry tiers, authentication, and optional features.

​

Limitations

△ Where ECR and Azure Container Registry stay different

• Repositories share one registry. Tensor9 provisions one ACR registry for the ECR repository set. Repository paths remain distinct; review the rewritten image references and shared registry settings.
• Tag locks and retention use different controls. ACR can lock individual images or entire repositories against writes. These locks differ from ECR’s immutable-tag setting: locking a repository also blocks new pushes. Configure the needed locks separately. Registry-wide retention requires Premium.
• Scanning moves to Microsoft Defender for Containers. It has its own coverage and cadence, different from ECR’s enhanced scanning.
• Geo-replication and private networking need Premium. On the Basic and Standard tiers those capabilities are not available.

​

Other considerations

Plan image delivery, credentials, and storage costs for the target registry.

• Push images from your build pipeline: the build stands up the Azure Container Registry to match your ECR repositories; your own pipeline repoints to <registry>.azurecr.io and pushes images, since the image data path is yours, not the appliance’s.
• Configure Microsoft Entra pull credentials: a workload that pulled under ECR’s caller IAM now pulls with an AcrPull managed identity (or an imagePullSecret), so the pull credential is established on Azure rather than inherited from AWS.
• Microsoft operates the registry; you choose the tier: availability and the control plane are Azure’s, and the SKU you pick (Basic, Standard, Premium) sets storage, throughput, and which features are available.
• Cost depends on the selected tier. Azure Container Registry bills per tier plus storage, and geo-replication and Private Link require Premium, so the feature set you rely on drives the tier and its cost.

​

On OCI

​

How it works

On AWS your build pushes container images to Amazon ECR and your workloads pull from it. OCI Container Registry is Oracle Cloud’s managed registry, organized around your tenancy: repositories live under your tenancy’s namespace, are scoped to compartments, and authenticate through OCI IAM. At the build, Tensor9 reads your ECR repositories and provisions one OCI repository for each; afterward your own docker push and docker pull reach it directly, without routing image traffic through Tensor9. The image itself never changes. ECR and OCI Container Registry both speak the OCI Distribution v2 protocol, so your image manifest, its layer blobs, and their content digests are byte-identical on both sides; docker and containerd are untouched. The target image reference uses <region>.ocir.io/<namespace>/<repo>, with the mapped repository path. Registry administration and policy differences are described below. This mapping provisions a target registry and updates image references. Docker and containerd use the target’s registry protocol and credentials. It does not provide the AWS ECR management or authorization-token API. Applications that call ECR directly, including GetAuthorizationToken, need a separate integration.

Your ECR repositories are provisioned as tenancy-namespaced OCI repositories at the build; afterward your push and pull reach them directly and the image is unchanged.

​

OCI Container Registry features

OCI Container Registry is organized around your tenancy. Every repository name is prefixed by your tenancy’s object-storage namespace (<namespace>/<repo>, with slash-nested paths), and repositories are scoped to compartments for access control and billing. Your ECR repositories map one-to-one to OCI repositories, so the per-repository topology is preserved, and each keeps an immutability flag matching your ECR tag-mutability setting. Authentication is OCI IAM: a workload pulls with an auth token, or with an instance or workload principal through the configured credential helper. An auth token is a credential that you must store and rotate; the principal-based helper avoids a static registry token. The registry is regional, with cross-region image copy for multi-region estates, and OCI Vulnerability Scanning provides native image scanning. Image retention policies apply region-wide by default and can be overridden with custom policies for specific repositories, deleting images that have not been pulled or versioned within a set number of days.

OCI Container Registry’s control plane, organized around your tenancy and compartments.

​

Limitations

△ Where ECR and OCI Container Registry stay different

• Image retention is configured separately. ECR’s per-repository lifecycle rule has no direct analog; OCIR applies a region-wide retention policy by default that you can override for specific repositories.
• Scanning moves to OCI Vulnerability Scanning. A native scanner with its own coverage, different from ECR’s enhanced scanning.
• Cross-region replication is a separate feature. OCIR replication is configured on its own and is not translated on the default configuration.

​

Other considerations

Plan image delivery, credentials, and storage costs for the target registry.

• Push images from your build pipeline: the build creates one tenancy-namespaced OCI repository per ECR repository; your pipeline repoints to <region>.ocir.io and pushes, since the image data path stays yours.
• Pull identity moves to OCI IAM: a workload pulls with an auth token or an in-tenancy instance or workload principal, replacing the ECR caller-IAM pull; the pull credential is established on OCI.
• Repositories live under your tenancy namespace and compartments. Oracle operates the registry, and the compartment placement that scopes access and billing is set on OCI rather than inherited from AWS.
• Image storage is billed to the tenancy. OCIR bills stored image data under your tenancy, retention applies region-wide by default, and cross-region copy is configured separately when a multi-region estate needs it.

​

On Private Kubernetes

​

Via Zot Registry

​

How it works

On AWS your build pushes container images to Amazon ECR and your workloads pull from it. When the target is your own Kubernetes cluster, the registry runs inside the cluster: an open-source registry you operate, with no cloud registry service behind it. Harbor is the recommended registry; Zot is a smaller alternative; Distribution provides basic image storage and delivery. At the build, Tensor9 provisions the registry, loads your images into it through the appliance, and rewrites every image reference to the in-cluster host; afterward your workloads pull directly from it. The image itself never changes. ECR and the in-cluster registry both speak the OCI Distribution v2 protocol, so your image manifest, its layer blobs, and their content digests are byte-identical; docker and containerd are untouched. The one thing rewritten at the build is the registry address: your ECR host becomes registry.<ns>.svc. You operate the registry and configure its policies. This mapping provisions a target registry and updates image references. Docker and containerd use the target’s registry protocol and credentials. It does not provide the AWS ECR management or authorization-token API. Applications that call ECR directly, including GetAuthorizationToken, need a separate integration.

Your images are loaded into an in-cluster registry through the appliance at the build; afterward your workloads pull from it directly and the image is unchanged.

​

Registry features and operation

The customer operates the registry and configures the features provided by the selected software. The registry is deployed empty : your images are loaded into it through the appliance’s image delivery service before any workload pulls, and there is deliberately no pull-through cache back to ECR, which removes the outbound AWS dependency entirely. Harbor, the recommended registry, ships built-in Trivy scan-on-push, robot accounts, per-repository retention, and immutable-tag rules, the closest match to ECR’s registry-management features. Zot is lightweight and OCI-native, with vulnerability (CVE) search available through an optional extension. Distribution is the bare reference registry: it stores and serves images and offers blob garbage-collection, but no scanning or tag controls. Whichever you run, your ECR repositories map one-to-one to the registry’s repositories, and a workload pulls with an injected imagePullSecret; Harbor’s robot accounts provide the richer, scoped path.

Choose the registry features your application needs: Harbor, Zot, or Distribution.

​

Limitations

△ Where ECR and an in-cluster registry stay different

• The registry starts empty. Your images are loaded through the appliance before any workload pulls; there is deliberately no pull-through cache back to ECR.
• Scanning, immutability, and retention depend on which registry you run. Harbor supports most ECR management features; Zot covers it partially; Distribution is a bare registry with none of it built in.
• There is no managed cross-region replica. An in-cluster registry serves the cluster it runs in; images are seeded through the appliance rather than replicated across regions.

​

Other considerations

Plan image delivery, credentials, and storage costs for the target registry.

• Images are seeded through the appliance, then served locally: the registry is deployed empty and your images are loaded through the appliance before any workload pulls, with no pull-through cache back to ECR, so the running cluster has no outbound AWS dependency.
• You operate the registry: there is no cloud control plane; Harbor, Zot, or Distribution is yours to run, and its availability, upgrades, and access model are your responsibility.
• Back up the registry’s persistent volume: the registry’s blobs live on a PersistentVolume in the cluster, so backup and retention of the image store are yours, not a managed registry’s.
• Budget for cluster compute and storage: the registry consumes the cluster’s own compute and storage rather than a managed per-tier or per-byte charge, and the feature depth (scanning, immutability, retention) follows which registry you chose.

​

Via Distribution Registry

​

How it works

On AWS your build pushes container images to Amazon ECR and your workloads pull from it. When the target is your own Kubernetes cluster, the registry runs inside the cluster: an open-source registry you operate, with no cloud registry service behind it. Harbor is the recommended registry; Zot is a smaller alternative; Distribution provides basic image storage and delivery. At the build, Tensor9 provisions the registry, loads your images into it through the appliance, and rewrites every image reference to the in-cluster host; afterward your workloads pull directly from it. The image itself never changes. ECR and the in-cluster registry both speak the OCI Distribution v2 protocol, so your image manifest, its layer blobs, and their content digests are byte-identical; docker and containerd are untouched. The one thing rewritten at the build is the registry address: your ECR host becomes registry.<ns>.svc. You operate the registry and configure its policies. This mapping provisions a target registry and updates image references. Docker and containerd use the target’s registry protocol and credentials. It does not provide the AWS ECR management or authorization-token API. Applications that call ECR directly, including GetAuthorizationToken, need a separate integration.

Your images are loaded into an in-cluster registry through the appliance at the build; afterward your workloads pull from it directly and the image is unchanged.

​

Registry features and operation

The customer operates the registry and configures the features provided by the selected software. The registry is deployed empty : your images are loaded into it through the appliance’s image delivery service before any workload pulls, and there is deliberately no pull-through cache back to ECR, which removes the outbound AWS dependency entirely. Harbor, the recommended registry, ships built-in Trivy scan-on-push, robot accounts, per-repository retention, and immutable-tag rules, the closest match to ECR’s registry-management features. Zot is lightweight and OCI-native, with vulnerability (CVE) search available through an optional extension. Distribution is the bare reference registry: it stores and serves images and offers blob garbage-collection, but no scanning or tag controls. Whichever you run, your ECR repositories map one-to-one to the registry’s repositories, and a workload pulls with an injected imagePullSecret; Harbor’s robot accounts provide the richer, scoped path.

Choose the registry features your application needs: Harbor, Zot, or Distribution.

​

Limitations

△ Where ECR and an in-cluster registry stay different

• The registry starts empty. Your images are loaded through the appliance before any workload pulls; there is deliberately no pull-through cache back to ECR.
• Scanning, immutability, and retention depend on which registry you run. Harbor supports most ECR management features; Zot covers it partially; Distribution is a bare registry with none of it built in.
• There is no managed cross-region replica. An in-cluster registry serves the cluster it runs in; images are seeded through the appliance rather than replicated across regions.

​

Other considerations

Plan image delivery, credentials, and storage costs for the target registry.

• Images are seeded through the appliance, then served locally: the registry is deployed empty and your images are loaded through the appliance before any workload pulls, with no pull-through cache back to ECR, so the running cluster has no outbound AWS dependency.
• You operate the registry: there is no cloud control plane; Harbor, Zot, or Distribution is yours to run, and its availability, upgrades, and access model are your responsibility.
• Back up the registry’s persistent volume: the registry’s blobs live on a PersistentVolume in the cluster, so backup and retention of the image store are yours, not a managed registry’s.
• Budget for cluster compute and storage: the registry consumes the cluster’s own compute and storage rather than a managed per-tier or per-byte charge, and the feature depth (scanning, immutability, retention) follows which registry you chose.

​

Via Harbor Registry

​

How it works

On AWS your build pushes container images to Amazon ECR and your workloads pull from it. When the target is your own Kubernetes cluster, the registry runs inside the cluster: an open-source registry you operate, with no cloud registry service behind it. Harbor is the recommended registry; Zot is a smaller alternative; Distribution provides basic image storage and delivery. At the build, Tensor9 provisions the registry, loads your images into it through the appliance, and rewrites every image reference to the in-cluster host; afterward your workloads pull directly from it. The image itself never changes. ECR and the in-cluster registry both speak the OCI Distribution v2 protocol, so your image manifest, its layer blobs, and their content digests are byte-identical; docker and containerd are untouched. The one thing rewritten at the build is the registry address: your ECR host becomes registry.<ns>.svc. You operate the registry and configure its policies. This mapping provisions a target registry and updates image references. Docker and containerd use the target’s registry protocol and credentials. It does not provide the AWS ECR management or authorization-token API. Applications that call ECR directly, including GetAuthorizationToken, need a separate integration.

Your images are loaded into an in-cluster registry through the appliance at the build; afterward your workloads pull from it directly and the image is unchanged.

​

Registry features and operation

The customer operates the registry and configures the features provided by the selected software. The registry is deployed empty : your images are loaded into it through the appliance’s image delivery service before any workload pulls, and there is deliberately no pull-through cache back to ECR, which removes the outbound AWS dependency entirely. Harbor, the recommended registry, ships built-in Trivy scan-on-push, robot accounts, per-repository retention, and immutable-tag rules, the closest match to ECR’s registry-management features. Zot is lightweight and OCI-native, with vulnerability (CVE) search available through an optional extension. Distribution is the bare reference registry: it stores and serves images and offers blob garbage-collection, but no scanning or tag controls. Whichever you run, your ECR repositories map one-to-one to the registry’s repositories, and a workload pulls with an injected imagePullSecret; Harbor’s robot accounts provide the richer, scoped path.

Choose the registry features your application needs: Harbor, Zot, or Distribution.

​

Limitations

△ Where ECR and an in-cluster registry stay different

• The registry starts empty. Your images are loaded through the appliance before any workload pulls; there is deliberately no pull-through cache back to ECR.
• Scanning, immutability, and retention depend on which registry you run. Harbor supports most ECR management features; Zot covers it partially; Distribution is a bare registry with none of it built in.
• There is no managed cross-region replica. An in-cluster registry serves the cluster it runs in; images are seeded through the appliance rather than replicated across regions.

​

Other considerations

Plan image delivery, credentials, and storage costs for the target registry.

• Images are seeded through the appliance, then served locally: the registry is deployed empty and your images are loaded through the appliance before any workload pulls, with no pull-through cache back to ECR, so the running cluster has no outbound AWS dependency.
• You operate the registry: there is no cloud control plane; Harbor, Zot, or Distribution is yours to run, and its availability, upgrades, and access model are your responsibility.
• Back up the registry’s persistent volume: the registry’s blobs live on a PersistentVolume in the cluster, so backup and retention of the image store are yours, not a managed registry’s.
• Budget for cluster compute and storage: the registry consumes the cluster’s own compute and storage rather than a managed per-tier or per-byte charge, and the feature depth (scanning, immutability, retention) follows which registry you chose.

Service Catalog.