- Coverage by target cloud
- How the backends compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
- Debug this service
Coverage by target cloud
How the backends compare
Each row compares a capability of ECR with its adaptation on each backend. A dash means this row is not stated for that backend.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 owndocker 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 registry’s own protocol and credentials. It does not provide the AWS ECR management or authorization-token API: an application that calls ECR directly, including GetAuthorizationToken, needs 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 Artifact Registry 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 behaves differently: it uses 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.
- ECR enhanced scanning is not supported. Artifact Analysis replaces it with on-push and continuous analysis, which have their own coverage and cadence.
- Lifecycle rules behave differently. 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 replication rules are not supported. 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. Point your pipeline at
<location>-docker.pkg.devand push there yourself; image traffic does not go through Tensor9. - Authorize the image-pulling identity. Grant the GKE node service account read access to the Artifact Registry 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 owndocker 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.
This mapping provisions a target registry and updates image references. Docker and containerd use the target registry’s own protocol and credentials. It does not provide the AWS ECR management or authorization-token API: an application that calls ECR directly, including GetAuthorizationToken, needs 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, which differ in storage, throughput and features. Premium adds geo-replication, which 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 animagePullSecret. 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- Repository layout behaves differently: all repositories share one registry. Tensor9 provisions one ACR registry for the ECR repository set. Repository paths stay distinct; review the rewritten image references and the shared registry settings.
- Tag immutability and retention behave differently. 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 locks you need separately. Registry-wide retention requires Premium.
- ECR enhanced scanning is not supported. Scanning moves to Microsoft Defender for Containers, which has its own coverage and cadence.
- Geo-replication and private networking are not supported on Basic or Standard. Both require the Premium tier.
Other considerations
Plan image delivery, credentials, and storage costs for the target registry.- Push images from your build pipeline. The build creates the Azure Container Registry to match your ECR repositories. Point your pipeline at
<registry>.azurecr.ioand push images there yourself; image traffic does not go through Tensor9. - Configure Microsoft Entra pull credentials. A workload that pulled with its AWS IAM identity now pulls with an AcrPull managed identity (or an
imagePullSecret). Set up that credential on Azure; it is not copied from AWS. - Microsoft operates the registry; you choose the tier. Azure runs the registry and its availability. The tier 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 owndocker 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.
This mapping provisions a target registry and updates image references. Docker and containerd use the target registry’s own protocol and credentials. It does not provide the AWS ECR management or authorization-token API: an application that calls ECR directly, including GetAuthorizationToken, needs 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 features, organized around your tenancy and compartments.
Limitations
Where ECR and OCI Container Registry stay different- Lifecycle rules behave differently: 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.
- ECR enhanced scanning is not supported. OCI Vulnerability Scanning replaces it, with its own coverage.
- ECR cross-region replication is not translated. OCIR replication is a separate feature that you configure yourself; the default configuration does not set it up.
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. Point your pipeline at
<region>.ocir.ioand push there yourself; image traffic does not go through Tensor9. - Pull identity moves to OCI IAM. A workload pulls with an auth token or an instance or workload principal in the tenancy, instead of its AWS IAM identity. Set up that credential 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 becomesregistry.<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 registry’s own protocol and credentials. It does not provide the AWS ECR management or authorization-token API: an application that calls ECR directly, including GetAuthorizationToken, needs 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
You operate the registry and configure the features of the software you choose. 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 delivers images and can garbage-collect unused layers, but has 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 injectedimagePullSecret; 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- Pulling through to ECR is not supported. 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 behave differently: they depend on the registry you run. Harbor supports most ECR management features, Zot some of them, and Distribution, a bare registry, none of them built in.
- Cross-region replication is not supported. An in-cluster registry is for the cluster it runs in. Images are loaded through the appliance, not replicated across regions.
Other considerations
Plan image delivery, credentials, and storage costs for the target registry.- Images are loaded through the appliance, then pulled locally. The registry is deployed empty and your images are loaded through the appliance before any workload pulls. There is no pull-through cache back to ECR, so the running cluster does not depend on AWS.
- You operate the registry. There is no cloud service behind it. 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 image layers live on a PersistentVolume in the cluster, so backup and retention of the image store are yours.
- Budget for cluster compute and storage. The registry uses the cluster’s own compute and storage rather than a managed per-tier or per-byte charge. Scanning, immutability and retention depend on 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 becomesregistry.<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 registry’s own protocol and credentials. It does not provide the AWS ECR management or authorization-token API: an application that calls ECR directly, including GetAuthorizationToken, needs 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
You operate the registry and configure the features of the software you choose. 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 delivers images and can garbage-collect unused layers, but has 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 injectedimagePullSecret; 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- Pulling through to ECR is not supported. 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 behave differently: they depend on the registry you run. Harbor supports most ECR management features, Zot some of them, and Distribution, a bare registry, none of them built in.
- Cross-region replication is not supported. An in-cluster registry is for the cluster it runs in. Images are loaded through the appliance, not replicated across regions.
Other considerations
Plan image delivery, credentials, and storage costs for the target registry.- Images are loaded through the appliance, then pulled locally. The registry is deployed empty and your images are loaded through the appliance before any workload pulls. There is no pull-through cache back to ECR, so the running cluster does not depend on AWS.
- You operate the registry. There is no cloud service behind it. 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 image layers live on a PersistentVolume in the cluster, so backup and retention of the image store are yours.
- Budget for cluster compute and storage. The registry uses the cluster’s own compute and storage rather than a managed per-tier or per-byte charge. Scanning, immutability and retention depend on 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 becomesregistry.<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 registry’s own protocol and credentials. It does not provide the AWS ECR management or authorization-token API: an application that calls ECR directly, including GetAuthorizationToken, needs 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
You operate the registry and configure the features of the software you choose. 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 delivers images and can garbage-collect unused layers, but has 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 injectedimagePullSecret; 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- Pulling through to ECR is not supported. 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 behave differently: they depend on the registry you run. Harbor supports most ECR management features, Zot some of them, and Distribution, a bare registry, none of them built in.
- Cross-region replication is not supported. An in-cluster registry is for the cluster it runs in. Images are loaded through the appliance, not replicated across regions.
Other considerations
Plan image delivery, credentials, and storage costs for the target registry.- Images are loaded through the appliance, then pulled locally. The registry is deployed empty and your images are loaded through the appliance before any workload pulls. There is no pull-through cache back to ECR, so the running cluster does not depend on AWS.
- You operate the registry. There is no cloud service behind it. 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 image layers live on a PersistentVolume in the cluster, so backup and retention of the image store are yours.
- Budget for cluster compute and storage. The registry uses the cluster’s own compute and storage rather than a managed per-tier or per-byte charge. Scanning, immutability and retention depend on which registry you chose.