When Amazon ECR fits and when self-hosted Harbor fits better
Amazon ECR is the simpler choice when your container estate runs inside AWS and your access model already lives in IAM. Images, pull and push permissions, and encryption sit in the same control plane as the clusters that consume them, so there is no registry server for your team to patch, back up or scale. Harbor fits better when clusters run on premises, in several clouds or in air-gapped networks, or when you need project-level role-based access control, OIDC single sign-on, replication and proxy caching under your own control. Renewals, data residency rules and multi-cloud sprawl are the usual triggers, but the trigger alone does not settle the question.
The decision turns on three things. First, where your clusters run: if most image pulls come from workloads inside one AWS region, ECR keeps those pulls close to the compute, while a fleet spread across data centers and clouds gives one self-hosted Harbor a role as the shared point of distribution. Second, who operates the registry: Harbor is a platform your team installs, upgrades, backs up and supports, and its recent releases have included database and cache changes and breaking defaults that need planned upgrade windows. Third, which identity model you standardize on: if your organization runs one IAM model, ECR's policies may be enough, but if you need Harbor projects with their own members and roles, or a single identity provider across every registry, Harbor's OIDC and project model is the stronger fit.
Before you choose, confirm three points in your own environment: which clusters pull images and from which networks, whether your auditors expect registry access to be tied to your central identity provider, and whether any upstream registry you need to mirror or cache is outside AWS. If the answers point to AWS-only pulls, ECR is usually the lower-effort option. If they point to mixed locations and a need for central control, plan a Harbor pilot against a single cluster and review the Harbor documentation for installation prerequisites before you commit to a design.
Which registry fits which estate
This table matches common estate types to the registry that usually fits better, with the condition that drives each choice. Read each row against your own identity model, network boundaries and team capacity, since the right answer depends on where your clusters and pipelines run.
| Scenario | Better fit | Why, and the condition that decides it |
|---|---|---|
| AWS-only workloads with IAM already governing access | Amazon ECR | ECR uses IAM for push and pull, and it keeps image traffic inside AWS. Choose it unless you need a registry outside AWS or a second identity model. |
| On-premises or air-gapped clusters | Harbor | Harbor runs in your own data center or isolated network and can be populated through Skopeo or replication. ECR depends on AWS connectivity, so confirm your network rules before deciding. |
| Multi-cloud pipelines with clusters in several clouds | Harbor | One Harbor registry can replicate to and cache from ECR, Azure Container Registry and Google registries. Confirm which upstream registries your build and deploy tools must reach. |
| Helm chart distribution alongside images | Harbor | Harbor serves Helm charts as OCI artifacts in the same project model as images, so charts and images share one access policy. Confirm your Helm clients support OCI references. |
| Teams without dedicated platform operators | Amazon ECR | ECR has no servers, databases or upgrades for your staff to run. Harbor adds upgrades, backups and scanner maintenance, so weigh that work against your team size before choosing it. |
| Pull-heavy builds that hit public registry limits | Harbor as a proxy cache | A Harbor proxy cache can serve images locally and keeps cached copies when upstream is unreachable. ECR alone does not front Docker Hub, so the cache role is a reason to run Harbor even inside AWS. |
Where each registry can run
Amazon ECR runs as a regional service inside AWS, and clusters, build runners and workloads in the same account and region pull from it over AWS networking, with access governed by IAM policies and repository policies. AWS operates the service itself, so the platform team does not patch, scale or back up the registry. For a team whose estate sits entirely in one AWS account family, ECR is usually the lowest-friction choice, and the question is whether it still fits as the estate changes.
- Operations: AWS runs the registry, so no database, storage nodes or upgrade windows belong to your team.
- Identity: pulls and pushes are authorized through IAM, which matches how most AWS teams already manage roles.
- Network path: traffic from workloads in the same region stays on AWS networking, which simplifies private connectivity.
- Harbor option: a self-hosted Harbor can still run inside your AWS accounts on EC2 or Kubernetes, but your team then owns that service.
- Cross-region and internet pulls: images pulled from outside the region or from external clients are billed as data transfer, so check where consumers sit.
Before committing, confirm the current ECR data transfer and storage rates for your regions with AWS, and confirm that every consumer can authenticate through IAM.
Harbor runs in your own data center or in infrastructure you control, so images, Helm charts and scan results stay on hosts you operate, including networks with no route to the internet. ECR cannot be placed in your data center, so an on-premises or air-gapped estate needs a local registry. Harbor's installer and Helm chart let you deploy onto your hosts, and Skopeo can sync an external repository to an internal registry or to a local directory for transfer into an isolated network.
- Placement: Harbor runs on hosts in your data center, with storage and database on infrastructure you manage.
- Content transfer: Skopeo can copy images into a local directory or into an internal registry, which supports sneakernet-style transfer across an air gap.
- Scanning offline: Harbor's Trivy scanner needs vulnerability data kept current inside the isolated network, so plan how advisory updates arrive.
- Availability: a single node has no redundancy, so decide early whether you need the high availability deployment path.
- Ownership: your team handles backups, certificates, upgrades and capacity, because no managed service sits behind the registry.
Ask your Harbor implementer how offline vulnerability updates and upgrade bundles will reach the isolated network, and check whether your security policy permits the transfer method.
When clusters run in AWS, Azure and Google Cloud, teams often end up with one registry per cloud. Harbor can serve as a single control point for that estate: its replication endpoints include AWS ECR, Azure Container Registry and Google Artifact Registry, and its proxy cache projects can front those registries as well as Docker Hub. Replication rules can run push-based or pull-based, so the central registry can either publish images outward or pull them in on a schedule.
- Replication: pull-based rules copy selected repositories and tags from a cloud registry into Harbor, and push-based rules publish them outward.
- Proxy cache: a Harbor proxy cache project can serve images from an upstream registry and keep a cached copy, which can help when an upstream is unreachable.
- Filtering: rules filter by repository name, tag, label and resource type, so only the required artifacts move.
- Trigger options: rules can run manually, on a cron schedule or on push and retag events.
- Credentials and egress: each endpoint needs its own credentials, and cross-cloud transfers incur the provider's data transfer charges, so plan the replication schedule with those costs in mind.
Verify that each cloud registry endpoint you need is supported by your Harbor version, and test a replication rule with a small repository before scaling it up.
Many estates combine the above: ECR serves workloads inside AWS, while Harbor serves on-premises clusters or a shared control point. In this model the two registries are not competing for the same workloads. Instead, images are produced once, then either replicated into Harbor or pulled into ECR depending on where they are consumed. Consistent naming and tagging conventions matter more here than in a single-cloud setup, because the same image can exist in two places.
- Split responsibility: AWS operates ECR, while your team operates Harbor, so incident ownership must be assigned explicitly.
- Single source: choose one registry as the origin of truth and treat replicas as copies, to avoid drift between them.
- Access control: IAM governs ECR access, while Harbor uses projects, RBAC and OIDC single sign-on, so two identity models must be aligned.
- Scanning: scan results from ECR and Harbor may differ, so define which scanner is authoritative for release gates.
- Network reach: on-premises clusters need a route to Harbor, and AWS workloads need a route to ECR or to a Harbor instance in AWS.
Confirm the network paths, identity mapping and scanner policy with your team before choosing which registry consumers should reference.
Data location, identity and compliance implications
Moving from Amazon ECR to Harbor changes where image data lives, who authenticates to it and what audit evidence exists. Each card below is a decision or check that follows from those changes, and each one ends with work the organization still owns, including mapping Harbor's controls to its own control set.
Where image data physically sits
ECR stores images in the AWS region you select, while a Harbor registry stores blobs on the volume or object store you provision in your own data center or cloud account. Layers, manifests and Helm charts all follow that storage choice. Confirm which regions, data centers or air-gapped networks hold replicas, and whether proxy cache copies of upstream images count as regulated data in your register of processing locations.
Identity source and single sign-on
ECR authorizes pushes and pulls through IAM policies and temporary tokens tied to AWS principals. Harbor's projects use role-based access control and can authenticate users through LDAP, Active Directory or OIDC single sign-on. Decide which identity provider is authoritative, how robot accounts for CI are issued and rotated, and who approves group-to-role mappings.
Audit logs and evidence retention
Harbor records audit logs inside the registry, but retention, export and tamper protection depend on how you forward them to your SIEM and archive. CloudTrail covers ECR API calls in AWS. Before an assessment, confirm which events you need for each control (for example, who pushed, pulled, deleted or changed a project policy), where the evidence is stored and for how long.
Mapping Harbor controls to your control set
Harbor's access controls and audit logs are features, not a compliance mapping. Your control owner must map each feature to the controls in your own framework, document the configuration as code and show that it operates over time. Ask your auditor which evidence they will sample before you design the mapping.
Vulnerability scanning and policy gates
Harbor scans images with Trivy when it is enabled at install time, and it can connect to other scanners. ECR offers its own scanning integration. Scanner coverage, database update frequency and the policy that blocks deployment of images with findings are decisions your security team owns and must document for every registry in scope.
Independent assessment and DeployOpen's role
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines and evidence collection for the registry. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree with your assessor in advance which artifacts you will provide.
How Harbor replication and proxy caching change the registry design
Replication and proxy caching are the two Harbor features that most change how an ECR estate is laid out, so decide early which role each registry plays. Harbor replication rules can run push-based or pull-based, so the same tool can send images out to another registry or fetch them from an upstream such as an AWS ECR endpoint. Each rule filters by repository name, tag, label and resource type, and it fires manually, on a cron schedule or on push and retag events. Map every rule to a named owner, a source, a destination and a trigger, then decide whether a cron schedule or an event trigger is acceptable for each environment. The optional per-task bandwidth limit matters when replication crosses a constrained WAN link to an on-premises cluster.
Proxy cache projects are a different design choice. A proxy cache project fronts an upstream registry such as Docker Hub, AWS ECR, Azure ACR, Google GCR, Quay, GitHub Container Registry or JFrog Artifactory. It is read-only for pushes, serves the cached copy when the upstream cannot be reached, and gets a default 7-day retention policy that you should review against your release cadence. Harbor's documentation says the proxy cache checks cached images with HEAD requests, and those requests do not trigger the Docker Hub rate limiter, which is documented as 100 unauthenticated pulls per 6 hours per IPv4 address or IPv6 /64 subnet and 200 for Docker Personal accounts. Confirm with your Docker subscription terms and your own traffic whether that limit still applies to your pull pattern, and decide whether build nodes pull through Harbor or directly.
The practical decision is whether Harbor is the system of record, a cache in front of cloud registries, or both. Replicate what must survive an outage or move between clouds, cache what you only consume, and keep rules for each class of image explicit. Test the failure path by blocking the upstream in a non-production environment and confirming that cached images still pull, because the cache serves only what it already holds. Document which namespaces are authoritative and which are cached copies so that auditors and incident responders know where an image came from.
How the cost of each registry is built
What does Amazon ECR bill for, and what is quoted here?
Amazon ECR bills by what you store and what data leaves the registry, so the main line items are image storage and data transfer as AWS meters them. No ECR price is quoted on this page because AWS pricing changes by region and over time. Pull current figures from the AWS pricing pages for Amazon ECR and the region where your repositories live, and confirm whether any cross-region replication or internet egress applies to your pulls. Your AWS bill, filtered by the ECR usage types, shows what you pay today.
Which costs drive an ECR bill higher over time?
Three factors dominate. Image volume grows with the number of tags, base image layers and retained builds, so lifecycle policies that expire old images cut storage directly. Cross-region pulls add transfer charges when clusters in other regions or clouds pull the same image. Cluster count multiplies pulls, because every node that starts a workload pulls its images. Ask your team to measure monthly storage in gigabytes and monthly transfer by source region before comparing any alternative.
What does running Harbor cost in servers and storage?
Harbor itself is open source under the Apache-2.0 license, so there is no license fee. The recurring cost is the infrastructure that runs it: compute for the Harbor core services, a database, a cache, a registry storage backend and load balancing for high availability. These are usually cloud or data center resources you already pay for. Harbor's installation prerequisites list the supported runtime and resource requirements, so size the nodes from that page and your image volume rather than from a generic guess.
How do object storage and the database add to the Harbor bill?
Image layers in Harbor are kept in a storage backend, typically S3-compatible object storage, and the metadata lives in PostgreSQL. Object storage is billed per gigabyte stored and per request by whichever provider or hardware you choose, and it recurs as long as images are retained. The database is small compared with layers but needs backups, patching and monitoring. Ask for both to be priced separately in any quote so you can see the recurring storage line next to the ECR storage line.
What backup and disaster recovery costs should we plan for?
Backups cover the PostgreSQL metadata, the image storage bucket and the Harbor configuration, including the keys and secrets that the registry needs. Each copy adds storage cost, and a second region or site adds transfer cost. ECR is also a managed service, so compare the recovery and retention behavior you need rather than only the storage fee. Confirm the backup frequency, retention period and restore test schedule with your own risk owners, and make them part of the scope.
What does the operating work for Harbor cost in people time?
The largest cost for many teams is people time. Someone must upgrade Harbor, which is a planned activity because minor releases have included database and cache changes, patch security advisories, rotate credentials, manage projects and access control, watch scanners and handle on-call incidents. Those tasks recur every month. Estimate the hours from your own staffing model, and ask any implementation partner to separate one-time setup from ongoing support, upgrades and testing in the written scope.
What should we request in a DeployOpen fixed-scope quote?
DeployOpen does not publish prices. A quote follows from a written scope, which should list the registries and upstreams in scope, the target environment (cloud accounts, data centers or air-gapped networks), the migration of repositories and tags, the high-availability design, backup and restore testing, integrations with identity and CI, documentation and handover, and whether ongoing support or upgrades are a separate retainer. Ask for each deliverable and timeline to be stated in writing before work starts, and ask which infrastructure costs are yours and which are included.
Can our team cover the cost structure internally instead?
Yes, if you have platform engineers who already run Kubernetes, PostgreSQL and object storage. The cost then sits mostly in their time and in the infrastructure. A fixed-scope engagement makes sense when that capacity is not available or when you want the setup, hardening and evidence done before handover. Compare the monthly cost of your internal hours and infrastructure with the ECR bill, and include the cost of staying current with Harbor releases.
What a move from Amazon ECR to Harbor involves
The sequence moves images and Helm charts into a self-hosted Harbor registry in a controlled order, so each step is verified before traffic depends on it.
Inventory repositories, tags and consumers
Your platform team lists every ECR repository, the tags that are still referenced, and which clusters, pipelines and build jobs pull or push each one. Export repository names and tag lists from the AWS account, then mark which tags are live, which are stale and which are referenced by signatures or SBOMs. The step is done when every repository has an owner and a documented list of consumers, and the team agrees which tags will be carried over.
Stand up Harbor and its identity integration
Platform engineers install Harbor in your own infrastructure, choose a database and storage layout, and connect single sign-on through OIDC or LDAP/AD so that people and robot accounts map to Harbor projects with role-based access control. Confirm the current installation prerequisites and the release line you intend to run before installing. The step is done when a test user can sign in, a project exists for each team, and the audit log records their actions.
Configure a pull-based replication endpoint for ECR
Create a registry endpoint in Harbor that points at your AWS ECR account, using credentials scoped to read the repositories being migrated. Then create a pull-based replication rule that filters by repository name and tag, and run it manually against one non-production repository first. The step is done when the copied image digests match those in ECR and the manifests and Helm charts appear under the expected Harbor project.
Validate scanning and access rules
Enable vulnerability scanning in the Harbor projects, either with the bundled Trivy scanner selected at install time or with an external scanner, and compare the findings with the scan results you already rely on from ECR. Test that project roles allow pulls by build agents, block pushes where intended, and that any content trust or signature checks you enforce behave as expected. The step is done when a representative set of images is scanned, the access matrix matches your policy, and the security team signs off on the results.
Cut over Kubernetes image references
Update image references in Helm values, manifests and GitOps repositories so that workloads pull from the Harbor hostname, starting with a non-critical namespace. Confirm that image pull secrets exist in each namespace and that nodes can reach the Harbor endpoint, including any certificate trust chain for an internal certificate authority. The step is done when rollouts succeed in each namespace and no pods report image pull errors over a full deployment cycle.
Switch CI push targets and retire ECR writes
Point build pipelines at Harbor for pushes, rotate the credentials they use, and stop writing to ECR once every pipeline has produced a successful build against Harbor. Keep ECR read-only for a period you define so that rollback remains possible. The step is done when all pipelines publish to Harbor, no new artifacts land in ECR, and the rollback path has been tested.
Re-create lifecycle policies in Harbor
ECR lifecycle policies do not move with the images, so the team recreates equivalent retention rules as Harbor tag retention and garbage collection schedules, and sets proxy cache or replication policies where they still apply. Confirm with the team which tags must be kept indefinitely. The step is done when retention rules run on a schedule, a test cleanup removes only the intended tags, and the rules are documented in the runbook.
Questions buyers ask before choosing Harbor over ECR
How much effort does a self-hosted Harbor deployment take?
The effort depends mostly on the shape of the estate, not on Harbor's install process alone. The work divides into designing the topology (single host or high availability, where the database and object storage live), wiring identity and access control, enabling vulnerability scanning, setting up replication and proxy cache rules, and building backup and upgrade routines. Harbor's installation prerequisites and its high availability Helm guide list the components to plan for. Ask any provider to break its quote into these phases, and ask which parts of the estate (clusters, storage, DNS, certificates, identity provider) they expect your team to supply.
Can an in-house team run Harbor without outside help?
Yes, many platform teams run Harbor themselves, provided they have people who already operate Kubernetes or Linux servers, PostgreSQL, object storage and TLS certificates. The recurring work includes patching, upgrading across minor versions, restoring from backups and tuning garbage collection. Recent releases have changed bundled components and included breaking changes, so the upgrade path needs a tested runbook. Decide whether you want a retainer for ongoing support, upgrades and testing, or a one-time build with handover, and confirm which of those your staff can absorb.
How long does a migration from ECR to Harbor take?
The timeline depends on the number of repositories and tags in scope, how many clusters and CI pipelines point at ECR, whether images must stay pullable during cutover, and how many lifecycle rules and access policies must be rebuilt by hand. Harbor's pull-based replication from an ECR endpoint can copy content in bulk, so the copy itself is often not the longest step. The slower work is usually changing image references, CI push targets and IAM-to-project role mapping. Ask for a scope document that lists these counts before agreeing a schedule.
What does the work need from our staff?
Plan for time from platform engineers who own the clusters and CI systems, from security staff who approve the access model and scanning policy, and from whoever controls DNS, certificates and the identity provider. Someone must also own the decision about which AWS identities keep pushing or pulling after cutover. Without named owners for these inputs, fixed-scope timelines tend to slip. Confirm availability for workshops, change windows and sign-off before the engagement starts.
Can Harbor replace ECR inside AWS?
Harbor can serve as the registry for workloads inside AWS, but you take on the hosting, storage, patching and availability that ECR handles as a managed service. ECR integrates directly with IAM, Amazon EKS and AWS-native tooling, which many teams value. Harbor makes more sense when the same images must reach on-premises clusters or several clouds from one place, or when projects, OIDC-based access and replication need a single model. Compare the operating work and the AWS data transfer patterns against your current bill, and ask for a written view on which workloads should stay on ECR.
How do we request a fixed-scope quote?
Start with a written scope that names the clusters and CI systems involved, the number of repositories and tags to move or cache, the identity provider, the target hosting (AWS accounts, data center or air-gapped network), backup and retention requirements, and the compliance evidence you need. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list, so the quote follows from that document. Send the scope to DeployOpen and ask for the deliverables, assumptions and client responsibilities to be listed separately.
What drives Harbor's ongoing cost, and what should we ask about it?
Ongoing cost comes from the compute and storage that run Harbor, the database and object storage it depends on, backups and disaster recovery copies, and the staff time needed to patch and upgrade it. Storage grows with image volume and retention rules, and cross-network transfer depends on where the consumers sit. ECR bills for storage and data transfer, so the comparison hinges on your own usage figures. Ask a provider to separate one-time build effort from recurring support, and to state which of your costs the quote excludes.
Which Harbor capabilities should we confirm before committing?
Confirm the features your policy depends on, not only the headline ones. Check how Harbor's project roles map to the groups in your identity provider, whether vulnerability scanning with Trivy meets your severity thresholds, how replication filters handle tags and labels, and whether proxy cache behaves correctly during an upstream outage. Test these against a copy of your images before cutover. Where a behavior is unclear, confirm it in the Harbor documentation for your target version.
How DeployOpen works on this
DeployOpen starts by mapping which ECR features your teams depend on, such as IAM-based pushes, scanning and cross-region copies, against the Harbor features that would replace them. The work is then planned, built, documented and handed over inside your own cloud accounts, data centers or air-gapped networks.
How we scope
- Inventory the repositories, pull paths, IAM roles and CI push targets that currently depend on Amazon ECR
- Agree in writing which Harbor projects, RBAC roles and OIDC or LDAP sign-in settings are in scope
- Define whether Harbor replicates to or proxy-caches from ECR, and which scanning and retention policies apply
- Fix the deliverables, timelines and acceptance criteria before work starts, since most engagements are fixed-scope
How we build
- Install Harbor in your environment, including the optional Trivy scanner, and connect it to your identity provider
- Configure replication endpoints and rules with filters for repository name, tag and resource type for the ECR estate
- Run security testing against the Harbor deployment, its API and its webhooks before cutover
- Document backup, garbage collection and upgrade procedures so your operators can run the registry without us
How we hand over
- Deliver the architecture, configuration records and runbooks written for your own platform and security teams
- Walk through the migration cutover plan for Kubernetes image references and CI push targets with your engineers
- Provide evidence of configured access controls, audit log settings and scanning policies for your compliance assessors
- Confirm with your auditors which controls they expect to see, since DeployOpen prepares evidence but does not issue attestations
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete
- Plan Harbor version upgrades with a backup beforehand, reviewing each release's breaking changes first
- Retest the registry after major releases, configuration changes or new replication endpoints are added
- Agree the support scope, response expectations and upgrade cadence in writing as part of the retainer
