AWS ECR EU Alternative 2026: Container Registry, GDPR, and Supply Chain Data Under US Jurisdiction

Post #689 in the sota.io EU Compliance Series

AWS Elastic Container Registry (ECR) is the default container image store for organizations running workloads on EKS, ECS, Fargate, and Lambda container deployments. It integrates natively with AWS CI/CD pipelines, handles image vulnerability scanning through Amazon Inspector, and provides pull-through caching for public registries like Docker Hub and GitHub Container Registry.

The compliance concern with ECR is not the container images themselves in isolation — but what travels alongside them: vulnerability scan results, pull event logs, image lifecycle metadata, build provenance, and signing certificates. These create a data profile of your application's entire container supply chain, stored under AWS infrastructure and US jurisdiction.

This article examines what AWS ECR stores, how it interacts with GDPR, CRA, and NIS2 obligations, and what EU-native alternatives exist for organizations that need container registry services without US-entity control over their supply chain data.

What AWS ECR Stores and Processes

ECR is primarily a regional service — your container images are stored in the AWS region you specify. Choosing eu-central-1 (Frankfurt) means your image layers physically reside on AWS infrastructure in Germany. That sounds like good news, but several dimensions of ECR operation extend beyond the image storage layer:

ECR Public Gallery is US-only. ECR Public (public.ecr.aws) is hosted exclusively in us-east-1. There is no EU-region option. If you publish base images or open-source distributions to ECR Public, that data is stored and served from the United States. Any organization that uses ECR Public images in their build pipelines has a dependency on US-jurisdiction infrastructure.

Amazon Inspector vulnerability scanning. ECR Enhanced Scanning uses Amazon Inspector to analyze container images for known CVEs. Inspector maintains a vulnerability database, scans image layers, and produces findings stored as ECR scan results. Inspector is a regional service, but the vulnerability intelligence and your image's specific CVE exposure profile are processed by AWS Inspector infrastructure. The findings reveal your application's software composition: which libraries, which versions, which known vulnerabilities exist in your stack — organizational intelligence under AWS control.

ECR pull-through cache. Pull-through cache lets ECR act as a caching proxy for upstream registries (Docker Hub, GitHub Container Registry, Quay.io, Kubernetes registries). Each cache hit or miss, each pull-through request, generates metadata stored in ECR. The upstream registry authentication credentials are stored in AWS Secrets Manager (linked to the pull-through cache configuration). Pull-through cache rules and namespace mappings reveal your organization's dependency graph — which upstream images you consume and at what frequency.

Image signing via AWS Signer. ECR supports container image signing through AWS Signer and the Notation signing standard. Signing certificates are managed by AWS Signer, a managed AWS service. Your image signing policy — which signing profiles are trusted, which signing keys are active — is stored in AWS-managed infrastructure. The trust policy for your container supply chain is an AWS-controlled asset.

CloudTrail ECR events. All ECR API calls are logged in CloudTrail: ecr:GetAuthorizationToken, ecr:BatchGetImage, ecr:PutImage, ecr:StartImageScan, ecr:DescribeImages. CloudTrail records the IAM principal making each call, the source IP address, and the event time. Pull events tell you exactly which image was deployed where and when — a detailed operational history of your container deployments under AWS's logging infrastructure.

Cross-region replication. ECR supports replicating images across AWS regions and across AWS accounts. Replication rules and their destinations are configuration data managed in ECR's control plane. Cross-account replication creates copies of your images in other AWS accounts, all under AWS's S3-backed storage with AWS encryption.

GDPR Analysis of AWS ECR

Container images are typically not personal data — they are compiled software artifacts. But the surrounding data layer that ECR accumulates around your images raises several GDPR concerns.

Operational data as personal data. ECR pull events logged in CloudTrail record the IAM principal pulling each image. In environments where human developers pull images directly — during debugging, local development, incident response — the IAM principal is linked to an individual. Pull event logs then constitute personal data: a record of which developer accessed which container at what time. This is directly analogous to access logs for other systems, which supervisory authorities consistently treat as personal data under GDPR Art.4(1).

Supply chain intelligence under US jurisdiction. Your ECR repository structure — names, tags, lifecycle policies — reveals how your application is organized. Repository names often mirror application component names. Tag patterns reveal your deployment cadence. Lifecycle policies reveal your retention strategy. This organizational intelligence is stored in ECR's metadata layer under AWS's infrastructure.

Vulnerability scan findings as sensitive technical data. Inspector scan findings document which specific CVEs exist in which versions of which libraries in which image layers. This is a detailed map of your application's known weaknesses. For organizations in regulated industries — financial services, healthcare, critical infrastructure — this vulnerability map is sensitive operational data whose unauthorized disclosure could facilitate targeted attacks. Under NIS2 Art.21(2)(e) (vulnerability handling), organizations in essential and important sectors must implement processes for handling vulnerability information. Storing that information under US jurisdiction contradicts the spirit of the obligation.

ECR Public and US-jurisdiction base images. Organizations that pull base images from ECR Public have an indirect dependency on US-jurisdiction infrastructure. While AWS images themselves are not personal data, automated pipelines that pull from public.ecr.aws in production create a runtime dependency on a US-hosted service — a business continuity risk distinct from, but related to, GDPR compliance.

CRA and NIS2 Implications

Container registries gained new regulatory relevance with the EU Cyber Resilience Act and NIS2.

CRA Art.13: Software Bill of Materials. The Cyber Resilience Act (entered into force October 2024, compliance deadline October 2027) requires manufacturers of products with digital elements to provide an SBOM to users. Container images are products with digital elements under the CRA definition when they are distributed commercially. If your organization distributes containerized software, your ECR vulnerability scan results and image manifest data constitute part of the SBOM evidence chain. Storing that chain under a US-entity cloud complicates the audit trail for CRA compliance.

CRA Art.14: Vulnerability reporting. CRA requires manufacturers to report actively exploited vulnerabilities to ENISA and national authorities within 24 hours. If your vulnerability detection pipeline routes through ECR Enhanced Scanning (AWS Inspector), the triggering event — Inspector detecting an exploited vulnerability in a deployed image — occurs in AWS infrastructure. Your obligation to ENISA is triggered by data first observed under US-jurisdiction processing.

NIS2 Art.21(3): Supply chain security. Essential and important entities under NIS2 must address supply chain security risks. Container registries are a supply chain node: a compromised or manipulated registry could deliver malicious images to production. The security controls you implement on your container registry — image signing policies, access controls, pull event audit logs — are part of your NIS2 supply chain risk management. Hosting those controls and their audit logs in US-jurisdiction infrastructure is a supply chain risk concentration that NIS2 auditors are beginning to examine.

EU-Native Container Registry Alternatives

Option 1: Harbor (Self-Hosted)

Harbor is the leading open-source container registry, a CNCF graduated project. Originally developed by VMware (now Broadcom), Harbor provides a production-grade container registry with features that match or exceed ECR:

• OCI-compliant image storage
• Role-based access control (RBAC) with LDAP/OIDC integration
• Replication to and from other registries (ECR, Docker Hub, other Harbor instances)
• Built-in vulnerability scanning via Trivy (open-source, Aqua Security) or Clair
• Image signing support (Cosign, Notation)
• Helm chart repository
• Audit logging
• Multi-tenancy via projects and registries

Self-hosting Harbor on EU infrastructure — Hetzner (Germany), Scaleway (France), OVHcloud (France), or sota.io — puts your registry entirely under your control. Vulnerability scan results, pull event logs, image signing policies, and all metadata stay on your infrastructure. Your vulnerability scanner (Trivy) runs on your machines and its findings are not shared with any third party.

The operational overhead of self-hosting Harbor is real but manageable. Harbor ships as a Docker Compose stack or Helm chart, supports external PostgreSQL (for HA) and Redis (for caching), and S3-compatible object storage for image layers (Hetzner Object Storage, Scaleway Object Storage, or MinIO on your own storage).

Jurisdictional status: Self-hosted on EU infrastructure of your choice. Zero US-entity data exposure.

Option 2: Scaleway Container Registry

Scaleway is a French cloud provider (Iliad Group subsidiary, Paris-listed company). Scaleway's Container Registry service provides managed OCI-compliant registry storage hosted in Scaleway's Amsterdam and Paris regions. Data never leaves EU jurisdiction.

Scaleway Container Registry supports:

• Private and public namespaces
• OCI v1.1 image and artifact storage
• Authentication via Scaleway IAM (EU entity)
• Integration with Scaleway's Kubernetes Kapsule
• Webhook notifications
• CLI and Terraform support

Limitations compared to Harbor or ECR: no built-in vulnerability scanning (Scaleway does not provide an integrated scanner), no pull-through cache. For vulnerability scanning, organizations pair Scaleway registry with Trivy running in their CI/CD pipeline or as a Kubernetes admission controller.

Jurisdictional status: French company (GDPR directly applicable, no US parent), EU-only infrastructure.

Option 3: OVHcloud Managed Private Registry

OVHcloud is a French cloud provider headquartered in Roubaix, France — publicly listed on Euronext Paris. OVHcloud Managed Private Registry is a managed Harbor instance, combining Harbor's feature set with OVHcloud's managed operations:

• Managed Harbor with automated updates and backup
• Available in OVHcloud EU regions (Gravelines/FR, Strasbourg/FR, Warsaw/PL, Frankfurt/DE, London/UK)
• Trivy vulnerability scanning built-in
• OIDC integration
• Kubernetes integration with OVH Managed Kubernetes Service

OVHcloud hosting Harbor provides the functionality of self-hosted Harbor without the operational overhead of managing Harbor upgrades, PostgreSQL replication, and TLS certificate rotation yourself. For organizations that want Harbor features with managed operations and EU jurisdiction, OVHcloud Managed Private Registry is the best option in this tier.

Jurisdictional status: French company (GDPR directly applicable, no US parent, no CLOUD Act).

Option 4: GitLab Container Registry (EU SaaS)

GitLab is a US-incorporated company, which means GitLab.com SaaS is subject to the CLOUD Act like AWS or GitHub. However, GitLab CE/EE is open-source and can be self-hosted. Organizations that self-host GitLab on EU infrastructure get the GitLab Container Registry included — images stored on your infrastructure, integrated with GitLab CI/CD, with no US-entity involvement.

For organizations already using self-hosted GitLab, the built-in container registry is the zero-overhead path to EU-jurisdiction image storage. Vulnerability scanning via GitLab's Trivy integration works on-premises.

Jurisdictional status: Self-hosted GitLab: user-controlled. GitLab.com SaaS: US entity (CLOUD Act applies).

Comparison Table

Migration Strategy

Step 1: Audit Your ECR Usage

Inventory what you are storing in ECR and how it is consumed:

# List all ECR repositories
aws ecr describe-repositories --region eu-central-1 \
  --query 'repositories[*].[repositoryName,repositoryUri,imageTagMutability]' \
  --output table

# Check for pull-through cache rules
aws ecr describe-pull-through-cache-rules --region eu-central-1

# Check ECR Public repositories
aws ecr-public describe-repositories --region us-east-1

Categorize repositories by sensitivity: application images vs. base images vs. build tooling. Identify which repositories your production Kubernetes deployments pull from — these are your highest-priority migration targets.

Step 2: Deploy Harbor on EU Infrastructure

The fastest path to a production Harbor instance on Hetzner or sota.io:

# Harbor Helm chart on Kubernetes
helm repo add harbor https://helm.goharbor.io
helm install harbor harbor/harbor \
  --namespace harbor-system \
  --create-namespace \
  --set expose.type=loadBalancer \
  --set expose.tls.enabled=true \
  --set externalURL=https://registry.yourdomain.eu \
  --set persistence.persistentVolumeClaim.registry.size=50Gi \
  --set persistence.persistentVolumeClaim.database.size=10Gi

For production: use external PostgreSQL (Hetzner Managed Databases or self-hosted) and external Redis. S3-compatible storage (Hetzner Object Storage) for image layers decouples storage from the Harbor pod lifecycle.

Step 3: Replace AWS Signer with Cosign

Cosign (Sigstore project, Linux Foundation) is the open-source standard for container image signing. Cosign does not require AWS Signer — signing keys can be stored in your infrastructure (on a hardware security module, in HashiCorp Vault, or in Kubernetes secrets):

# Generate a signing key pair (store private key in Vault or HSM)
cosign generate-key-pair --kms vault://transit/cosign-key

# Sign an image after push to Harbor
cosign sign --key vault://transit/cosign-key registry.yourdomain.eu/app/api:v1.2.3

# Verify signature in admission controller / CI
cosign verify --key vault://transit/cosign-key registry.yourdomain.eu/app/api:v1.2.3

Sigstore's Rekor transparency log provides a public audit trail of signatures without relying on any AWS-managed signing infrastructure.

Step 4: Integrate Trivy into CI/CD

Replace ECR Enhanced Scanning with Trivy running in your own CI/CD pipeline:

# GitLab CI example
container-scan:
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH
        registry.yourdomain.eu/app/api:$CI_COMMIT_SHA
  only:
    - main
    - /^release\/.*/

Trivy runs locally in your CI infrastructure. Vulnerability findings are logged to your CI system — not transmitted to any AWS service. For Kubernetes admission control, Trivy Operator runs as a cluster-native scanner that posts findings to Kubernetes CRDs.

Step 5: Update Pull Policies and Kubernetes ImagePullSecrets

Kubernetes clusters pulling from Harbor need an imagePullSecret:

kubectl create secret docker-registry harbor-credentials \
  --docker-server=registry.yourdomain.eu \
  --docker-username=robot\$your-robot-account \
  --docker-password=<robot-account-token> \
  --namespace your-namespace

Reference the secret in your Deployment manifests. Automate secret rotation via cert-manager or external-secrets-operator with your EU-hosted secret backend (Vault, Infisical).

What This Means for Your GDPR Article 30 Record

After migrating container images to Harbor on EU infrastructure, the GDPR record of processing for your container registry simplifies considerably:

Before (ECR):

• Controller: Your organization
• Personal data: Pull event logs (IAM principals), vulnerability scan findings, operational metadata
• Recipients: Amazon Web Services, Inc. (US processor, DPA + SCCs)
• Third-country transfers: USA under Standard Contractual Clauses
• Residual risk: CLOUD Act exposure for vulnerability findings and pull event logs

After (Harbor on EU infra):

• Controller: Your organization
• Personal data: Pull event logs (if any human pull events; typically only CI service accounts)
• Recipients: None (self-hosted on EU infrastructure)
• Third-country transfers: None
• Residual risk: Operational (availability, backup) — not jurisdictional

For regulated organizations conducting DPIAs for their container infrastructure, eliminating the US-entity processor from the container registry layer removes an Art.46 transfer and its associated CLOUD Act risk.

Conclusion

AWS ECR's regional storage for image layers is real, but the surrounding data layer — vulnerability scan results, pull event logs, signing certificates, pull-through cache metadata — creates a supply chain data profile under US jurisdiction. For organizations in regulated sectors where NIS2 Art.21(3) supply chain security applies, or those preparing for CRA Art.13 SBOM obligations, keeping that supply chain intelligence under EU-jurisdiction infrastructure is increasingly a compliance requirement, not just a preference.

Harbor on EU infrastructure is the technically complete replacement for ECR: it matches ECR's feature set, adds open-source vulnerability scanning via Trivy, supports Cosign signing without AWS Signer, and runs entirely under your control. Scaleway and OVHcloud Container Registry provide managed alternatives with lower operational overhead and EU-entity jurisdiction.

The broader AWS compliance picture continues: container images run your application, but they're built from AWS Lambda functions, stored alongside AWS S3 data, accessed via AWS IAM roles, and monitored through AWS CloudWatch. Each service adds to the jurisdictional footprint. The container registry is where your supply chain starts.