> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # ECR > AWS ECR. A private registry for container images, with per repository IAM permissions, image scanning and lifecycle rules that expire old tags. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Infrastructure-only adaptation](#infrastructure-only-adaptation) * [On Google Cloud](#on-google-cloud) * [On Azure](#on-azure) * [On OCI](#on-oci) * [On Private Kubernetes](#on-private-kubernetes) * [Via Zot Registry](#via-zot-registry) * [Via Distribution Registry](#via-distribution-registry) * [Via Harbor Registry](#via-harbor-registry) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | ✓ | | Private Kubernetes | ✓ | ## 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 | Capability | ECR | Google Cloud | Azure | OCI | Private Kubernetes · Zot Registry | Private Kubernetes · Distribution Registry | Private Kubernetes · Harbor Registry | | --------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Repository topology · repository organization | ECR: repositories within an account-and-region registry | Artifact Registry: one Docker-format repository per ECR repository (N to N), topology preserved | ACR: one provisioned registry contains distinct repository paths; image references change | OCIR: one repository per ECR repository (N to N), repository organization preserved | in-cluster: the ECR repository set becomes the registry's repositories/namespaces (N to N) | in-cluster: the ECR repository set becomes the registry's repositories/namespaces (N to N) | in-cluster: the ECR repository set becomes the registry's repositories/namespaces (N to N) | | Tag immutability | Yes - image\_tag\_mutability | Yes - IMMUTABLE\_TAGS setting | - | Yes - is\_immutable per-repo flag | Partial - Zot has no per-repo immutable-tag lock | No - Distribution has no immutable-tag control | Yes - Harbor immutable-tag rules (per-repo) | | Lifecycle / retention · scope | ECR: per-repository expiry rules | per-repository keep/delete rules; the bounded single-image-package count/age mapping does not preserve the full ECR policy | ACR: registry-wide retention (Premium tier), a scope change that is surfaced | OCIR: image retention policies, region-wide by default and overridable per repository, surfaced at the build | Zot retention policies (registry-level) | Distribution offers blob garbage-collection only, not tag/age retention | Harbor tag-retention is per-repository, the closest in-cluster analog to ECR lifecycle rules | | Vulnerability scanning | Yes - ECR enhanced (Inspector) | Partial - Container Analysis: on-push + continuous | Partial - Microsoft Defender for Containers: native scanner, different coverage | Partial - OCI Vulnerability Scanning: native scanner, different coverage | Partial - Zot exposes CVE search via an optional Trivy-DB extension (not built-in scan-on-push) | No - CNCF Distribution has no built-in vulnerability scanner | Partial - Harbor ships a built-in Trivy integration (scan-on-push) | | API coverage | full | high | high | high | high | high | high | | Tag immutability | Yes - per-repo image\_tag\_mutability | - | Partial - image and repository write locks; different from ECR tag immutability | - | - | - | - | | Data path · managed vs in-cluster | ECR: AWS-managed registry | - | - | - | in-cluster registry starts empty: deploy + load (via the appliance) + rewrite refs; no pull-through to AWS | in-cluster registry starts empty: deploy + load (via the appliance) + rewrite refs; no pull-through to AWS | in-cluster registry starts empty: deploy + load (via the appliance) + rewrite refs; no pull-through to AWS | ## On Google Cloud | Operation | Area | Support | Depth | Notes | | ------------------------ | ------------ | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Registry authentication | Auth | Supported | Common | Native registry credentials: the GKE node service account needs Artifact Registry Reader; application workload federation is separate | | docker push / pull | Image path | Supported | Common | byte-identical OCI Distribution v2; the host changes to \-docker.pkg.dev | | Image tag policy mapping | Immutability | Supported | Most usage | IMMUTABLE\_TAGS repository setting | | Lifecycle policy mapping | Lifecycle | Partial | Most usage | Per-repository cleanup policies provide count or age retention for one image package. Keeping ten versions combines delete and keep rules. Tag selectors, ECR rule priority, age clocks and immutable tags require separate policy decisions; the full ECR rule language is not preserved. | | Replication config | Replication | Out of scope | Full surface | ECR destination push replication is not mapped. Multi-region storage, pull-through caches and virtual repositories do not create the specified regional or account replicas; deliver required image copies through your pipeline. | | Repository provisioning | Repositories | Supported | Common | one Docker-format repository (format = DOCKER) per ECR repository (N to N) | | Scan-on-push findings | Scanning | Partial | Most usage | Container Analysis / Artifact Analysis (on-push + continuous) | #### 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 `-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.
Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach Google Artifact Registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path. Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach Google Artifact Registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path.

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](https://docs.cloud.google.com/kubernetes-engine/security/configure-node-service-accounts), 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.
Google Artifact Registry control plane Google Artifact Registry control plane

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 `-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 | Operation | Area | Support | Depth | Notes | | ------------------------ | ------------ | --------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry authentication | Auth | Supported | Common | the AcrPull managed identity takes over; the registry admin user is disabled | | docker push / pull | Image path | Supported | Common | byte-identical OCI Distribution v2; the host changes to \.azurecr.io | | Image tag policy mapping | Immutability | Partial | Most usage | ACR image and repository write locks differ from ECR tag immutability; configure the required locks explicitly | | Lifecycle policy mapping | Lifecycle | Partial | Most usage | registry-wide retention (Premium); a scope change from per-repo, surfaced at the build | | Replication config | Replication | Partial | Full surface | Azure geo-replication (Premium-only); not emitted on the Standard default | | Repository provisioning | Repositories | Supported | Common | Provisions one ACR registry with a distinct path for each ECR repository. The registry name must be globally unique, alphanumeric, and 5-50 characters. | | Scan-on-push findings | Scanning | Partial | Most usage | scanning moves to Microsoft Defender for Containers | #### 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 `.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.
Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach Azure Container Registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path. Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach Azure Container Registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path.

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](https://learn.microsoft.com/en-us/azure/container-registry/authenticate-kubernetes-options) 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 control plane Azure Container Registry control plane

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 `.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 | Operation | Area | Support | Depth | Notes | | ------------------------ | ------------ | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry authentication | Auth | Supported | Common | handled by the OCI instance-principal credential helper, in-tenancy; no static secret in the pull path | | docker push / pull | Image path | Supported | Common | byte-identical OCI Distribution v2; manifest, layers and SHA-256 digest unchanged; host and repository references are rewritten | | Image tag policy mapping | Immutability | Supported | Most usage | per-repository immutability, set from your ECR tag-mutability setting | | Lifecycle policy mapping | Lifecycle | Partial | Most usage | ECR per-repo lifecycle rules are surfaced at the build; OCIR provides its own image retention policies (region-wide by default, overridable for specific repositories) that you configure separately | | Replication config | Replication | Out of scope | Full surface | OCIR replication is configured separately and is not translated by default | | Repository provisioning | Repositories | Supported | Common | one OCI repository per ECR repository (N to N); the repository name is normalized to lowercase with slash-nesting and no underscore | | Scan-on-push findings | Scanning | Partial | Most usage | served by OCI Vulnerability Scanning, a native scanner with different coverage than ECR enhanced | #### 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 `.ocir.io//`, 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.
Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach OCI Container Registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path. Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach OCI Container Registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path.

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 (`/`, 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 control plane OCI Container Registry control plane

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 `.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 | Operation | Area | Support | Depth | Notes | | ------------------------ | ------------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry authentication | Auth | Supported | Common | in-cluster imagePullSecret; Harbor also supports robot accounts | | Reference rewrite | Image path | Supported | Common | every consumer's ECR image ref is rewritten to the in-cluster host; the imagePullSecret is injected and the ECR auth helper dropped | | docker push / pull | Image path | Supported | Common | byte-identical OCI Distribution v2; the host changes to registry.\.svc | | Lifecycle policy mapping | Lifecycle | Partial | Most usage | Zot retention policies (registry-level) | | Image load (bootstrap) | Migration | Supported | Common | The appliance loads images before workloads pull them. Images are identified by content, so repeating the load does not duplicate them. | | Cross-region replication | Replication | Out of scope | Full surface | an in-cluster registry has no cross-region replica; the pull-through cache to ECR is deliberately not used, so there is no outbound AWS dependency | | Repository provisioning | Repositories | Supported | Common | the registry is deployed in-cluster and the ECR repository set becomes its repositories/namespaces (N to N) | | Scan-on-push findings | Scanning | Partial | Most usage | Zot exposes CVE search via an optional Trivy-DB extension (not built-in scan-on-push) | #### 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..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.
Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach in-cluster registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path. Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach in-cluster registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path.

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.
In-cluster registry model In-cluster registry model

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 | Operation | Area | Support | Depth | Notes | | ------------------------ | ------------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry authentication | Auth | Supported | Common | in-cluster imagePullSecret; Harbor also supports robot accounts | | Reference rewrite | Image path | Supported | Common | every consumer's ECR image ref is rewritten to the in-cluster host; the imagePullSecret is injected and the ECR auth helper dropped | | docker push / pull | Image path | Supported | Common | byte-identical OCI Distribution v2; the host changes to registry.\.svc | | Lifecycle policy mapping | Lifecycle | Partial | Most usage | Distribution offers blob garbage-collection only, not tag/age retention | | Image load (bootstrap) | Migration | Supported | Common | The appliance loads images before workloads pull them. Images are identified by content, so repeating the load does not duplicate them. | | Cross-region replication | Replication | Out of scope | Full surface | an in-cluster registry has no cross-region replica; the pull-through cache to ECR is deliberately not used, so there is no outbound AWS dependency | | Repository provisioning | Repositories | Supported | Common | the registry is deployed in-cluster and the ECR repository set becomes its repositories/namespaces (N to N) | | Scan-on-push findings | Scanning | Out of scope | Most usage | CNCF Distribution has no built-in vulnerability scanner | #### 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..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.
Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach in-cluster registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path. Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach in-cluster registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path.

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.
In-cluster registry model In-cluster registry model

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 | Operation | Area | Support | Depth | Notes | | ------------------------ | ------------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry authentication | Auth | Supported | Common | in-cluster imagePullSecret; Harbor also supports robot accounts | | Reference rewrite | Image path | Supported | Common | every consumer's ECR image ref is rewritten to the in-cluster host; the imagePullSecret is injected and the ECR auth helper dropped | | docker push / pull | Image path | Supported | Common | byte-identical OCI Distribution v2; the host changes to registry.\.svc | | Lifecycle policy mapping | Lifecycle | Partial | Most usage | Harbor tag-retention is per-repository, the closest in-cluster analog to ECR lifecycle rules | | Image load (bootstrap) | Migration | Supported | Common | The appliance loads images before workloads pull them. Images are identified by content, so repeating the load does not duplicate them. | | Cross-region replication | Replication | Out of scope | Full surface | an in-cluster registry has no cross-region replica; the pull-through cache to ECR is deliberately not used, so there is no outbound AWS dependency | | Repository provisioning | Repositories | Supported | Common | the registry is deployed in-cluster and the ECR repository set becomes its repositories/namespaces (N to N) | | Scan-on-push findings | Scanning | Partial | Most usage | Harbor ships a built-in Trivy integration (scan-on-push) | #### 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..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.
Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach in-cluster registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path. Before: on AWS your build pushes images to Amazon ECR and your workloads pull from it. After: on the target cloud the same docker push and pull reach in-cluster registry, provisioned at the build. Only the registry address is rewritten; the image is unchanged and Tensor9 is not in the pull path.

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.
In-cluster registry model In-cluster registry model

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](/service-adapters/catalog).