3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3

Enterprise Artifact Management Overview

In continuous integration and continuous deployment (CI/CD) pipelines, artifact management forms the operational bridge between source code builds and production runtime environments. For the AWS Certified DevOps Engineer - Professional (DOP-C02) exam, you must master the lifecycle, security, access control, and cross-account distribution patterns across three primary AWS artifact repositories:

1. AWS CodeArtifact: A fully managed, polyglot package repository service for application software dependencies (npm, PyPI, Maven, NuGet, Swift, and RubyGems).
2. Amazon Elastic Container Registry (ECR): A high-performance, managed OCI container image registry supporting private and public repositories, automated image vulnerability scanning, and cross-region replication.
3. Amazon Simple Storage Service (S3): An object store utilized for deployable runtime bundles (ZIP, tarballs), CloudFormation nested templates, AWS Lambda code deployment archives, and static application assets.

Securing artifacts requires decoupling build pipelines from public open-source registries, establishing Write-Once-Read-Many (WORM) immutability, and enforcing least-privilege resource policies across multi-account AWS Organizations hierarchies.

---

AWS CodeArtifact: Architecture, Upstreams & Multi-Account Sharing

AWS CodeArtifact organizes software packages into a two-tier hierarchy: Domains and Repositories.

Domains vs. Repositories

• Domain: An administrative boundary that groups repositories together. Physical package assets (the underlying .tgz, .whl, or .jar binaries) are stored and deduplicated at the domain level using SHA-256 content addressing. Even if a specific package version is referenced across twenty different repositories in the same domain, it is stored only once. Domains are encrypted with a single AWS Key Management Service (AWS KMS) Customer Managed Key (CMK) or AWS-managed key.
• Repository: A polyglot logical container within a domain where client tools (such as npm, pip, mvn, gradle, nuget) publish and consume packages. A single CodeArtifact repository natively handles multiple package formats simultaneously.

+-------------------------------------------------------------+
|                  AWS CodeArtifact Domain                    |
|  - Encryption: KMS CMK                                      |
|  - De-duplicated Asset Storage (SHA-256)                    |
|                                                             |
|  +-----------------------+     +-------------------------+  |
|  | Upstream Repository   |     | Downstream Repository   |  |
|  | (e.g., external-cache)|<----+ (e.g., team-repo)       |  |
|  +-----------+-----------+     +-------------------------+  |
|              |                                              |
|              v                                              |
|  +-----------------------+                                  |
|  | External Connection   |                                  |
|  | (public:npmjs, pypi)  |                                  |
|  +-----------------------+                                  |
+-------------------------------------------------------------+

Upstream Repositories and External Connections

A central design pattern in CodeArtifact is upstream repository aggregation. A repository can declare up to 10 direct upstream repositories. When a client requests a package from a downstream repository, CodeArtifact searches the downstream repository first. If the package version is not found, it queries the upstream repositories in the configured priority order.

To consume public open-source software securely, you attach an External Connection to a repository. Supported external connections include:

• public:npmjs (npm Registry)
• public:pypi (Python Package Index)
• public:maven-central, public:maven-google, public:maven-gradle-plugins
• public:nuget-org (NuGet Gallery)
• public:ruby-gems-org (RubyGems)

Exam Watch: When an external package is requested for the first time through a repository with an external connection, CodeArtifact fetches the asset, ingests it into the domain, and retains it permanently as an internal package version. This caching protects pipelines against external registry downtime, upstream package deletion (the "left-pad" incident), and unauthorized remote tampering.

Cross-Account Package Distribution Pattern

In enterprise AWS Organizations setups, organizations adopt a hub-and-spoke artifact architecture:

1. Shared Services Account (Hub): Hosts the CodeArtifact Domain, the external-connection cache repository, and the central enterprise release repository.
2. Development & Production Accounts (Spokes): Contain build agents and deployment runtimes that read from and publish to the central repositories.

To enable cross-account access, both Domain Policies and Repository Policies are applied:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": [
        "codeartifact:GetAuthorizationToken",
        "codeartifact:GetRepositoryEndpoint",
        "codeartifact:ReadFromRepository"
      ],
      "Resource": "*"
    }
  ]
}

Authentication requires generating a temporary authorization token using aws codeartifact get-authorization-token (or aws codeartifact login), which provides a 12-hour STS-backed credential for CLI package managers.

Package Retention, Immutability & Package Statuses

CodeArtifact enforces immutability: once a specific package version (e.g., lib-auth@1.2.0) is published, it cannot be overwritten. To manage the package lifecycle, CodeArtifact provides distinct package version statuses:

• Published: Fully available for consumption.
• Unfinished: Package assets are in the process of uploading.
• Archived: Package can be read by existing consumers but cannot be resolved as the latest dependency for new builds.
• Disposed: Assets are purged from the repository; package version metadata remains to prevent republishing the same version string.
• Deleted: Completely erased from the repository.

---

Amazon ECR: Registry Governance, Immutability & Lifecycle Automation

Amazon ECR provides managed container registries for Docker and OCI images, Helm charts, and deployment manifests.

Private vs. Public Repositories & Authentication

• Private Repositories: Scoped to individual AWS accounts and regions. Authentication uses the aws ecr get-login-password command, which generates an authorization token valid for 12 hours via the AWS STS ecr:GetAuthorizationToken API. Runtimes authenticate against aws_account_id.dkr.ecr.region.amazonaws.com.
• Public Repositories: Registered under Amazon ECR Public Gallery (public.ecr.aws) with global public read access and optional AWS Marketplace monetization.

Image Tag Immutability

By default, ECR repositories allow tag mutability, meaning pushing an image with an existing tag (such as :latest or :release-v1) silently overwrites the previous image manifest. In production CI/CD pipelines, you must enable Image Tag Immutability:

• Prevents tag overwriting: Any docker push attempting to push a pre-existing tag fails with an ImageTagAlreadyExistsException.
• Guarantees deterministic deployments: Assures that task definitions referencing :v2.4.1 always pull the exact digest evaluated during staging testing.
• Blocks rogue tampering: Untrusted actors cannot overwrite a trusted image tag with malicious code.

ECR Lifecycle Policies

ECR lifecycle policies automate repository hygiene, preventing unchecked storage cost growth caused by untagged intermediate layer builds and stale feature branch containers. Lifecycle policies are JSON documents containing ordered rules:

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Purge untagged images older than 7 days",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "Retain only the last 30 release images",
      "selection": {
        "tagStatus": "tagged",
        "tagPatternList": ["release-*"],
        "countType": "imageCountMoreThan",
        "countNumber": 30
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

Lifecycle Policy Evaluation Mechanics

1. Priority Ordering: Rules are evaluated strictly in ascending numerical order (rulePriority: 1 executes before rulePriority: 2).
2. Single Match Rule: Once an image matches an active rule, it is subject to that rule's action and is excluded from evaluation by subsequent rules.
3. Tag Status Options: tagged (requires tagPrefixList or tagPatternList), untagged (matches images whose tags were removed or overwritten), or any.

Cross-Region and Cross-Account Replication

ECR provides registry-level, push-triggered replication. When enabled, pushing an image to a repository in us-east-1 automatically replicates the image layers and manifests to specified destination accounts and regions (e.g., eu-west-1, ap-southeast-1).

• Encryption in Transit & at Rest: Destination repositories can re-encrypt replicated layers using region-specific KMS Customer Managed Keys.
• Repository Creation Templates: Automatically apply repository policies, tag immutability, and lifecycle rules to newly auto-created destination repositories.
• Cross-Account Pulls: If replication is not used, cross-account pulling requires an ECR Repository Policy granting ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, and ecr:BatchCheckLayerAvailability to external IAM principals.

---

Amazon S3: Immutable Deployment Bundles, Object Lock & Lifecycle Rules

Amazon S3 serves as the backbone for raw application deployment archives (AWS Lambda .zip artifacts, Elastic Beanstalk source bundles, and CodeDeploy application revisions).

S3 Versioning and MFA Delete

Enabling S3 Versioning ensures that every PUT, POST, or DELETE creates a distinct version ID rather than overwriting existing objects. When an object is deleted without a version ID, S3 applies a Delete Marker. To prevent malicious or accidental permanent deletion of release binaries, enable MFA Delete on the release bucket, requiring hardware or virtual multi-factor authentication tokens to purge specific object versions.

S3 Object Lock: Compliance vs. Governance Modes

For regulated workloads requiring absolute Write-Once-Read-Many (WORM) storage, S3 Object Lock prevents object deletion or overwriting for a fixed retention period:

S3 Object Lock also supports Legal Holds, which place an indefinite retention lock on an artifact independent of retention dates until explicitly cleared by an authorized identity.

S3 Lifecycle Rules for Build Artifacts

Build pipelines generate thousands of transient artifacts. A production S3 artifact lifecycle policy manages costs by:

1. Transitioning current versions from S3 Standard to S3 Standard-Infrequent Access (Standard-IA) after 30 days.
2. Moving historical noncurrent versions to S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive after 60 days.
3. Expiring and permanently deleting noncurrent versions after 180 days.
4. Aborting incomplete multipart uploads via AbortIncompleteMultipartUpload after 7 days to eliminate orphaned upload segments.

---

Architectural Comparison: CodeArtifact vs. ECR vs. S3