Skip to main content
Welcome. This lesson explains artifact lifecycles and secure storage patterns for build outputs in AWS. You’ll learn what artifacts are, common artifact types, AWS services used to store and distribute artifacts, how artifacts move through a CI/CD pipeline, and recommended practices for retention, immutability, metadata, and security.

​
What is an artifact?

An artifact is a point-in-time, build-produced package or file that represents a specific version of software or infrastructure. Artifacts are the canonical, deployable outputs of CI/CD pipelines and can be promoted across environments (dev → test → prod) while remaining immutable and traceable. Common artifact types:
  • Compiled binaries and archives (ZIP, JAR, WAR)
  • Container images and layers (Docker, OCI)
  • Cloud images (AMIs)
  • Package manager artifacts (npm, Maven, PyPI, NuGet)
  • Infrastructure-as-code outputs (CloudFormation templates, CDK synth artifacts)
  • Manifests and configuration (YAML, JSON, Helm charts)
Key attributes of high-quality artifacts:
  • Versioned and immutable: each artifact version is a permanent record.
  • Traceable: include provenance (commit SHA, builder identity, build ID), signatures, and vulnerability scan results.
  • Reusable & cacheable: maximize build performance by caching layers and packages.
A slide titled "What Is an Artifact?" that lists three artifact types. It shows Source Code Artifacts (ZIP, JAR, WAR), Container Artifacts (Docker images, container layers), and Infrastructure as Code Artifacts (CloudFormation templates, CDK outputs).
Artifacts can be application code outputs, IaC artifacts, container layers, or any build output you must version, sign, scan, and distribute.

​
Artifact storage options in AWS

AWS provides purpose-built and general-purpose stores for artifacts. Choose the service that matches the artifact format, access controls, immutability needs, and distribution patterns.
  • AWS CodeArtifact — Managed package repository for package formats such as npm, Maven, PyPI, and NuGet. Ideal for internal package hosting, dependency caching, and proxying public registries. Integrates with IAM for fine-grained access.
  • Amazon S3 — General-purpose object storage for arbitrary build outputs (ZIPs, serverless assets, large binaries). Use S3 when you need flexible storage classes, lifecycle transitions, or long-term archival.
  • Amazon ECR — Container registry for Docker/OCI images and layers. ECR supports image scanning and integrates with ECS, EKS, and Lambda.
Choose the storage service based on artifact type and governance needs: CodeArtifact for packages, S3 for arbitrary build outputs and serverless artifacts, and ECR for container images and layers.
A slide titled "Artifacts in Different AWS Services" showing AWS service icons (CodeArtifact, S3, ECR) on the left. Numbered bullets on the right list features like managed repositories for Docker/OCI images, vulnerability scanning, integrations with Lambda/ECS/EKS/CodeBuild, and storing Docker images.
Comparison at a glance: For scanning, ECR supports Amazon ECR image scanning (powered by Amazon Inspector). You can also integrate third-party scanners such as Trivy in your pipeline for additional checks.

​
Artifacts in a CI/CD pipeline

Typical artifact flow:
  1. Developer pushes code to a source repo (e.g., CodeCommit, GitHub).
  2. CI system (e.g., CodeBuild) fetches sources, installs dependencies, runs tests, and produces artifacts.
  3. CI publishes artifacts to the appropriate store (S3, CodeArtifact, ECR).
  4. CD system (CodeDeploy, ECS, Lambda, or custom scripts) pulls artifacts and deploys them to target environments.
A slide titled "Artifacts in CI/CD Pipeline" showing a workflow of a developer committing code to AWS CodeCommit, then moving to AWS CodeBuild and AWS CodeDeploy. AWS CodeArtifact is shown below, feeding artifacts into the CodeBuild step.
CodeBuild commonly performs two artifact-related roles:
  • Pull dependencies from package registries (CodeArtifact, public registries cached by CodeArtifact).
  • Push produced artifacts (built files, images) to storage or registries.

​
CodeBuild build phases and artifacts

CodeBuild lifecycle phases: install → pre_build → build → post_build. The post_build phase is typically where artifacts are uploaded and publication tasks occur (e.g., push a Docker image to ECR or upload ZIP to S3). Example minimal buildspec.yml that uploads a directory to S3 as artifacts:
Pushing a Docker image to ECR typically requires authenticating Docker, building, tagging, and pushing:
Publishing packages to CodeArtifact (npm example) usually begins with logging in:
Automating these steps in buildspec.yml (or your CI configuration) ensures reproducible and auditable artifact creation and publication.
A diagram titled "CodeBuild Artifact Generation Flow" showing AWS CodeCommit being fetched by AWS CodeBuild. CodeBuild then uploads build artifacts to AWS CodeArtifact, Amazon S3, and Amazon ECR.

​
Retention and lifecycle management

Define and automate retention and cleanup strategies for artifacts so storage remains cost-effective and your pipeline remains performant. Per-service guidance:
  • S3: enable bucket versioning, use lifecycle rules to transition older objects to cheaper storage classes (Glacier, Intelligent-Tiering) and to expire objects after a retention period.
  • ECR: use lifecycle policies to prune images by tag patterns, age, or count.
  • CodeArtifact: configure repository policies and retention rules as supported; clean up unused package versions and enforce access control.
A presentation slide titled "Retention and Clean Up Stages." It shows three colored icons labeled "S3 Lifecycle Policies" (green bucket), "ECR Lifecycle Policies" (orange cube), and "CodeArtifact Retention" (purple hexagon with a code symbol).
Automate lifecycle operations using IaC (CloudFormation, Terraform, or S3 lifecycle rules) and CI jobs so cleanup is auditable, repeatable, and adheres to compliance requirements.

​
Best practices

  • Immutability: treat artifacts as immutable records. Never overwrite published artifact versions; create new versions for fixes.
Do not modify published artifacts in-place. Treat each artifact version as a permanent, traceable record of a build.
  • Versioning: adopt semantic versioning or a deterministic scheme that includes build metadata (commit SHA, CI build number).
  • Metadata & provenance: record build metadata (commit SHA, build ID, builder identity), dependency lists, and SBOMs alongside artifacts or in your CI system.
  • Vulnerability scanning: integrate scanning (ECR image scanning, Amazon Inspector, Trivy) and gate promotions on critical/high findings.
  • Access control: apply least privilege using IAM policies, repository-level permissions, and centralized auditing (CloudTrail).
  • Automation & reproducibility: automate artifact creation, signing, publishing, and promotion. Keep build definitions under source control and document the release process.
  • Traceability: record deployments and artifact promotions so you can answer “what was deployed where and when?”

​
Summary and further resources

Artifacts are versioned, immutable build outputs that you publish and promote across environments. AWS provides:
  • CodeArtifact for package registries,
  • S3 for general-purpose artifact storage,
  • ECR for container images.
CI systems (e.g., CodeBuild) should produce, sign, scan, and publish artifacts to the appropriate store; CD systems then consume them. Apply lifecycle policies, vulnerability scanning, strict access controls, and metadata capture to keep your artifact lifecycle secure, auditable, and repeatable. Useful references: Practical labs and demos for artifact creation, storage, scanning, and promotion are included in the course materials.

Watch Video