Skip to main content
Welcome back. This lesson reviews common storage patterns for build outputs and application artifacts used in CI/CD pipelines on AWS. You’ll learn where to store different artifact types, why certain stores are preferred, and how those choices affect deployments, rollbacks, and traceability. Primary artifact repositories in AWS
  • AWS CodeArtifact — package registry for third‑party libraries and packaged application artifacts.
  • Amazon S3 — object storage for file-based artifacts, templates, and static assets.
  • Amazon Elastic Container Registry (ECR) — OCI/container images.
Build outputs and mutable artifacts from CI processes—libraries, binaries, config files, IaC templates, container images, AMIs—are pushed into one of these systems. For example, AMIs are created from EBS snapshots; the snapshot data is stored in AWS-managed S3 behind the scenes (not exposed as ordinary S3 objects).
A slide titled "Deployment Artifacts" showing four colored panels: Build Outputs, IaC Templates, Config Files & Binaries, and Container Images, each with a short description. It summarizes the types of artifacts produced for software deployment.
High-level CI/CD flow
  • Source code (Git) is checked out by the build system (e.g., AWS CodeBuild).
  • The build job compiles/packages the application and pushes artifacts to the target repository (S3, CodeArtifact, or ECR).
  • The deployment service (CodeDeploy, ECS, EKS, etc.) pulls artifacts from those repositories and performs the deployment.
When using infrastructure-as-code (CloudFormation, CDK), synthesized templates are typically uploaded to S3 so CloudFormation can access them during stack operations. For CDK, the cdk synth step produces CloudFormation templates that are stored or referenced in S3 for stack creation and rollbacks. IaC templates and S3 storage
A diagram titled "IaC Template Storage Pattern" showing AWS components (AWS Lambda, Amazon EC2, Amazon S3) and an AWS CloudFormation icon with an arrow indicating templates stored in S3. It illustrates using CloudFormation and S3 to manage infrastructure-as-code templates.
Why store IaC templates in S3?
  • Consistency: a declared, versioned artifact that can be used across environments.
  • Rollbacks: reference previous object versions to revert to a known-good template.
  • Team sharing: templates can be reused via StackSets or direct S3 references.
  • Chaining stacks: pass outputs between stacks reliably.
  • S3 versioning: provides object-level version control for templates and makes audits simpler.
Exam tip: The exam often highlights AWS-native IaC patterns such as CloudFormation and CDK. Focus on these for deployment workflows rather than third‑party tools.
Software and package artifacts Use repositories appropriate to the artifact type and usage pattern:
  • CodeArtifact
    • Use case: package management for npm, Maven, PyPI, NuGet and hosting your own packaged artifacts (JAR, WAR, ZIP).
    • Benefits: secure supply chain, dependency caching, and version pinning for repeatable builds.
  • S3
    • Use case: file-based artifacts (binaries, configs), static sites, and IaC templates.
    • Benefits: object versioning, event triggers (SNS/Lambda), lifecycle rules, CloudFront integration.
  • ECR
    • Use case: container images (ECS/EKS pull images directly).
    • Benefits: optimized image storage and integration with AWS container services.
Typical advantages of a package registry (CodeArtifact)
  • Centralized access controls and supply-chain security.
  • Local caching to speed up builds and reduce external dependency failures.
  • Dependency pinning ensures repeatable releases by locking versions.
A slide titled "Code Artifacts Pattern" showing a "Benefits" bar and three colorful icons labeled "Secure supply chain," "Faster builds (local cache)," and "Dependency version pinning." The icons are arranged side-by-side inside a dotted border.
Common artifact types by language/stack Use the appropriate repository for each artifact. For example, push container images to ECR and packaged libraries to CodeArtifact. Static site assets and IaC templates belong in S3.
A slide titled "Application Artifacts" showing a two-column table that maps stacks/languages to their typical artifact types. Examples include Java (.jar, .war, .ear), .NET (.dll, .exe), Python (.pyz, .whl), Docker (image:tag), and static site files (.html, .css, .js).
Block storage, snapshots, and AMIs Instances write to block volumes (EBS). When you create snapshots of those volumes, the snapshot data is managed by an S3-backed service. Use snapshot lifecycle policies to automate retention and cleanup. Snapshots are ideal for backups and for AMI creation workflows. Storing artifacts directly on EBS for distribution is generally not recommended; snapshots should be used for backups, not as a distribution mechanism.
A cloud architecture diagram titled "Block Storage Pattern" showing a Region and VPC with two Availability Zones, each containing instances and EBS volumes. On the right are EBS snapshots depicted as bucket icons.
Do not use EBS volumes as the primary distribution channel for deployment artifacts. EBS is attached to a single AZ and instance; S3 or registries (CodeArtifact/ECR) are the correct distribution mechanisms for shared artifacts.
When to use S3 S3 is ideal when you need:
  • A single source of truth for files and binary artifacts.
  • Object versioning for rollback support.
  • Fine-grained access control via IAM and bucket policies.
  • Event notifications to trigger downstream CI/CD steps (e.g., Lambda, SNS).
  • Lifecycle rules for cost management.
  • Integration with CloudFront for global content delivery.
A presentation slide titled "S3 for Application Artifacts" showing an Amazon S3 bucket icon. Three numbered points state S3 is a single source of truth, supports versioning/access control and event triggers, and integrates with CloudFront for global delivery.
Container images and registries
  • Use ECR (or another OCI-compliant registry) for container images. ECR is optimized for storage and serving of images to ECS, EKS, or other runtimes.
  • Build images in your CI (CodeBuild or other) and push to ECR as a pipeline step.
  • Deployments can be triggered from the CI/CD pipeline (e.g., kubectl apply or ECS task updates) or pulled by runtime agents that reference images in ECR.
Summary — pick the right store for the artifact Choosing the appropriate artifact store improves deployment reliability, enables repeatable builds, and simplifies rollbacks and auditing. Links and references

Watch Video