# CodeArtifact

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/codeartifact

## Quick definition

CodeArtifact is a service that stores software packages like libraries and dependencies in a central place. It helps developers share code components safely within a team or organization. Instead of downloading packages from the public internet each time, you can pull them from your own private repository in AWS. This makes your builds faster, more reliable, and easier to control.

## Simple meaning

Imagine you are building a complex LEGO castle. You don’t make every brick yourself, you use many different bricks from different sets. In software, those bricks are called dependencies: pre-built pieces of code that do common jobs like handling dates, connecting to a database, or making HTTP requests. Normally, when you build your software, your computer reaches out to the public internet, like going to a giant LEGO warehouse, to fetch these bricks. That works, but it can be slow, and sometimes the warehouse is down or the bricks change versions unexpectedly. CodeArtifact is your own private, secure LEGO warehouse inside your organization. You or your team can copy all the needed bricks (packages) into your warehouse once. Then, whenever anyone builds software, they grab bricks from your warehouse instead of the public one. This is much faster because the warehouse is close by inside AWS. It is also safer because your team controls exactly which bricks are available and which versions are approved. You can even set up policies that say, “only use bricks that passed our security check.” CodeArtifact supports many package types: npm for JavaScript, Maven for Java, PyPI for Python, NuGet for .NET, and generic packages. You connect your build tools to CodeArtifact using simple commands, and it acts as a proxy, it can fetch new bricks from the public internet on demand and cache them for future use. That way, the first time a developer asks for a package, CodeArtifact goes and gets it, stores a copy, and next time serves it instantly. This caching speeds up builds dramatically and reduces dependency on external networks. You also get detailed logs of who accessed which package, which helps with auditing and compliance. For IT teams managing many projects, CodeArtifact provides a single source of truth for all code components, reducing version conflicts and security risks.

## Technical definition

AWS CodeArtifact is a fully managed artifact repository service designed to store, retrieve, and share software packages used during development and deployment. It supports popular package formats including npm, PyPI, Maven, NuGet, and generic packages, making it compatible with a wide range of programming languages and ecosystems. Under the hood, CodeArtifact creates a namespace called a domain, which acts as a container for repositories. A domain can hold multiple repositories, each representing a logical collection of packages. You can configure repositories to be either internal (private) or external (proxied from public registries). When you connect a repository to an external public repository (like npmjs.org or Maven Central), CodeArtifact acts as a proxy cache. The first time a client requests a package version, CodeArtifact fetches it from the upstream public registry, stores it in your repository, and serves it to the client. Subsequent requests for the same package version are served directly from the cache, reducing latency and eliminating external network dependency. This proxy behavior is critical for build reliability in cloud environments where network access to public registries can be intermittent or restricted. Authentication to CodeArtifact is handled through AWS Identity and Access Management (IAM). Developers authenticate using temporary credentials issued by AWS CLI or the CodeArtifact login command, which generates authentication tokens. The login command configures your local package manager (like pip or npm) to point to your CodeArtifact repository endpoint. All package metadata and content are encrypted at rest using AWS Key Management Service (KMS) and in transit using TLS. CodeArtifact integrates tightly with other AWS services such as AWS CodeBuild, AWS CodePipeline, and AWS Lambda. During a build in CodeBuild, you can specify a CodeArtifact repository as the package source, ensuring builds use approved dependencies. You can also set up lifecycle policies to automatically delete old package versions, manage storage costs, and enforce version retention. CodeArtifact supports package version tracking, enabling you to see all versions of a package, their publishing dates, and their dependencies. You can also use the AWS SDK or CLI to programmatically manage repositories, publish packages, and query metadata. Organizations with multiple accounts can share a single domain across accounts using resource-based policies, enabling centralized governance of software components while allowing decentralized consumption.

## Real-life example

Think of a large public library system in a big city. Normally, if you want a specific book, you have to go to the main city library, which might be far away and have long wait times. Also, other branches might have the same book, but you don’t know which one has it available. This is like every developer in your company downloading packages from the public internet, each person makes a separate trip, and sometimes the book is checked out (package version removed) or the library is closed (registry downtime). Now imagine your company builds a private internal library network. Every time a branch library needs a book, instead of going to the city library, they request it from a central warehouse that already has a copy. The first time a book is requested, the central warehouse sends someone to the city library, buys a copy, and puts it on its own shelf. After that, any branch can just walk into the central warehouse and grab the book instantly. That central warehouse is CodeArtifact. The books are software packages. The branches are your development teams or CI/CD build servers. The central warehouse stores one master copy for everyone. If the city library changes the book’s content (a new version), the central warehouse can either update automatically or wait for approval. This saves time, reduces traffic, and ensures everybody uses the same version of a book. In real IT, this means faster builds, fewer network failures, and consistent environments across your entire organization. Plus, the library has a checkout log, just like CodeArtifact logs every package download, so you know exactly who borrowed what. If a security vulnerability is found in a package, you can lock that package and prevent anyone from borrowing it again until you replace it with a secure version.

## Why it matters

In professional software development, using third-party packages is standard practice. Modern applications can depend on hundreds or even thousands of external libraries. Without a managed artifact repository, each developer’s machine and each build server independently downloads packages from the public internet. This creates several serious problems. First, builds become non-deterministic, if a public registry updates a package between builds, the same source code might produce different results. Second, builds slow down significantly because every download travels over the public internet, especially in regions with limited bandwidth. Third, security risks increase because you have no control over which versions are used; a compromised package upstream can infect your entire pipeline. CodeArtifact solves all of these. It provides a single, authoritative source for your dependencies. You approve which package versions enter your repository, and every build uses only those. Because CodeArtifact caches packages after the first download, subsequent builds are extremely fast, often seconds instead of minutes. It also gives you full audit trails so you know exactly which package was used when and by whom, critical for compliance frameworks like SOC 2 or PCI DSS. For organizations with multiple teams, CodeArtifact enables sharing of proprietary or internal packages across projects without exposing them publicly. You can publish your own libraries (like shared utilities or SDKs) into CodeArtifact and treat them as first-class dependencies. This encourages code reuse and reduces duplication. In CI/CD pipelines, CodeArtifact can be integrated directly with AWS CodeBuild and CodePipeline, making the build process seamless and secure. During incidents where a public registry goes down, your builds continue uninterrupted because CodeArtifact already has cached copies. For a developer, the experience is nearly transparent: after a one-time login command, your package manager automagically uses CodeArtifact. The service also handles package retention policies, automatically cleaning up old versions to save storage costs. In short, CodeArtifact is not just a convenience, it is a foundational component for any serious DevOps practice, ensuring reliability, speed, security, and compliance in dependency management.

## Why it matters in exams

AWS CodeArtifact is a core topic for the AWS Certified Developer – Associate exam. It appears under Domain 3: Security, Domain 4: Deployment, and Domain 5: Refactoring. Specifically, questions test your understanding of how to use CodeArtifact to manage dependencies securely and efficiently in a CI/CD environment. Exam objectives include setting up a private repository, configuring authentication with IAM, integrating CodeArtifact with CodeBuild and CodePipeline, and understanding caching behavior. You will see scenario-based questions where a developer’s build fails because of network timeouts reaching the public npm registry. The correct answer will involve configuring a CodeArtifact repository as a proxy to cache packages. Another common pattern is a security question: a developer accidentally introduces a vulnerable package. The best solution is to store all approved packages in CodeArtifact and configure build projects to use only that repository. The exam also tests knowledge of CodeArtifact domains and repositories. For example, a question might describe a company with multiple AWS accounts wanting to share packages centrally. The answer is to create a single CodeArtifact domain and configure cross-account access using resource-based policies. You should be familiar with the CodeArtifact login command pattern: aws codeartifact login --tool pip --domain my-domain --repository my-repo. Also know that authentication tokens expire after some time and must be renewed. Difference between upstream repositories and direct repositories is important: an upstream repository is one that is proxied from a public registry; a direct repository stores packages you publish yourself. The exam may ask about package versioning and lifecycle policies, for instance, how to automatically delete outdated packages to reduce costs. CodeArtifact integrates with AWS KMS for encryption, so you might see questions about encryption at rest. Finally, be aware of supported package formats: npm, PyPI, Maven, NuGet, and generic. In multiple-choice questions, the distractor often says “Docker images”, but Docker images are stored in Amazon ECR, not CodeArtifact. Knowing this distinction is crucial. Study the AWS documentation on setting up CodeArtifact with different package managers and practice the CLI commands. Hands-on experience will help you answer troubleshooting questions about authentication errors, proxy failures, and version conflicts.

## How it appears in exam questions

On the AWS Developer – Associate exam, CodeArtifact questions usually appear as scenario-based problems. A typical question: A developer team is experiencing slow builds because every time a build runs, it downloads npm packages from the public internet. The build server is in a VPC without internet access. What should you do? The answer will involve setting up a VPC endpoint for CodeArtifact and configuring npm to use a CodeArtifact repository with an upstream connection to npmjs.org. Another frequent pattern asks about security: A security audit reveals that developers are using packages directly from the public registry without any control over versions. Which solution provides the most secure way to manage third-party dependencies? The correct answer is to use CodeArtifact to store approved packages and enforce their use in all build projects. Questions also test your understanding of authentication. For example: A developer runs aws codeartifact login and then tries to install a package but gets a 403 error. What is the likely cause? Possible answers: the IAM role does not have permission to read from the repository, or the authentication token has expired. You need to know that tokens expire after a default of 12 hours (configurable). Another question type involves cross-account sharing. A company has two AWS accounts: one for development and one for production. They want to share a common set of packages. How can CodeArtifact help? You would configure the development account’s CodeArtifact domain to grant read access to the production account’s IAM role. There are also questions about lifecycle policies. Which feature allows you to automatically delete packages older than 90 days? CodeArtifact lifecycle policies. You might be asked to choose between different services: “Which service would you use to store and manage Maven packages?” CodeArtifact is correct; distractor options might include S3 (too low-level), ECR (for Docker images), or Systems Manager Parameter Store (for config values). Exam questions may also mix CodeArtifact with CodeBuild. They might describe a buildspec.yaml file that uses a package manager; you must know how to configure buildspec to authenticate with CodeArtifact using the aws codeartifact login command before installing dependencies. Finally, a troubleshooting question might involve a build failing because a package version requested does not exist in the repository. The fix is to either publish the package or configure an upstream repository to fetch it from the public registry. These questions generally require you to combine knowledge of IAM permissions, VPC endpoints, package managers, and CI/CD integration. Practice with sample questions on AWS Skill Builder.

## Example scenario

An organization, FinServCorp, is building a new financial reporting application. The development team uses Python with many third-party libraries like pandas, numpy, and fastapi. Until now, each developer installed these libraries directly from PyPI (the public Python package index) on their local machines. The build server also fetched them fresh each time. This caused several problems. The builds were slow, taking over 20 minutes just to download all dependencies. Sometimes PyPI was unreachable, causing build failures. Worse, a library called 'requests' released a new version that broke their code. Different developers had different versions installed on their machines, leading to 'works on my machine' bugs. The security team was worried because they had no way to vet every library version. FinServCorp decides to use AWS CodeArtifact to fix this. A DevOps engineer creates a new CodeArtifact domain called finserv-domain and a repository called python-shared. They configure the repository with an upstream connection to the public PyPI repository. Then they set up a lifecycle policy to delete any package version older than one year. The team then runs the command aws codeartifact login --tool pip --domain finserv-domain --repository python-shared on their build server and local machines. This configures pip to always use the CodeArtifact repository. The first time the build server runs, it requests pandas version 1.5.0. CodeArtifact fetches it from PyPI, stores it, and serves it. The build takes 5 minutes instead of 20 because subsequent runs use the cached copy. The security team enables a policy that only allows packages that have been manually vetted. Now, before any new version can be used, a security engineer approves it in CodeArtifact. If a critical vulnerability is found in 'requests', they can delete that version from the repository, and no one can use it again. The team also publishes their own internal library, finserv-utilities, to the same repository. Other teams within FinServCorp can now depend on it by simply adding it to their requirements.txt. The result is faster builds, consistent environments, improved security, and better collaboration across teams. The exam question might ask: What was the main reason for the build speed improvement? The caching behavior of CodeArtifact.

## Common mistakes

- **Mistake:** Thinking CodeArtifact can only store custom packages published by your team, not third-party packages.
  - Why it is wrong: CodeArtifact is designed to store both internal packages you publish and external packages fetched from public registries via upstream repositories. It acts as a proxy cache that stores copies of external packages locally.
  - Fix: Understand that upstream repositories are a key feature. You configure a repository to connect to a public registry like npmjs.org or PyPI, and CodeArtifact automatically caches every package you request from that source.
- **Mistake:** Assuming that once a package is cached in CodeArtifact, it is never updated even if a new version is published upstream.
  - Why it is wrong: CodeArtifact caches each package version individually. When a new version is requested, it fetches it from the upstream if not cached. However, it does not automatically pull newer versions of an already cached version, you must request the new version explicitly.
  - Fix: Understand that caching is per version, not per package. If you need the latest version, your build must request that specific version. Lifecycle policies can remove old versions, but new versions are only added when requested.
- **Mistake:** Confusing CodeArtifact with Amazon ECR (Elastic Container Registry).
  - Why it is wrong: ECR is specifically for Docker container images. CodeArtifact is for software packages such as npm, Maven, PyPI, and NuGet. The two services are completely separate and serve different purposes in the CI/CD pipeline.
  - Fix: Remember: CodeArtifact = code dependencies (libraries). ECR = container images. If a question mentions Docker images, think ECR. If it mentions Java JARs or Python wheels, think CodeArtifact.
- **Mistake:** Believing that CodeArtifact repositories are publicly accessible by default and require no authentication.
  - Why it is wrong: CodeArtifact repositories are private by default. To access them, you must authenticate using AWS IAM credentials. The `aws codeartifact login` command configures local tools to use temporary tokens. Without IAM permissions, access is denied.
  - Fix: Always check IAM policies for any CodeArtifact question. The repository must be granted explicit read permissions to users or roles. Use resource-based policies for cross-account access.
- **Mistake:** Thinking that you must delete and recreate a repository to change its upstream source.
  - Why it is wrong: You can modify a repository's upstream connections after creation. You can add, remove, or change upstream repositories using the AWS CLI or console without affecting existing packages.
  - Fix: Learn the CLI commands: `aws codeartifact update-repository` to modify upstreams. This is a common exam scenario.

## Exam trap

{"trap":"The exam presents a scenario where a developer wants to share a proprietary library across multiple AWS accounts. The developer creates a CodeArtifact repository in each account and manually uploads the package to both repositories.","why_learners_choose_it":"Learners think that because each account is separate, they need separate repositories. They also may not be familiar with CodeArtifact domains and cross-account sharing features. The idea of ‘keeping things separate’ seems safer.","how_to_avoid_it":"Understand that CodeArtifact domains can span multiple AWS accounts. You create one domain in a central account, and then use resource-based policies to grant read access to other accounts. Developers in other accounts can then access packages from that single domain without duplicating repositories. This is more efficient and ensures consistency. Always look for solutions that reduce duplication in cross-account scenarios."}

## Commonly confused with

- **CodeArtifact vs Amazon ECR:** Amazon ECR stores Docker container images, while CodeArtifact stores software packages (like npm, PyPI, Maven). ECR is used for containerized applications; CodeArtifact is used for source code dependencies. Both are used in CI/CD but for different artifact types. (Example: You store a compiled .jar file in CodeArtifact. You store a Docker image that runs your application in ECR.)
- **CodeArtifact vs AWS CodeCommit:** CodeCommit is a version control service for storing source code (like Git repositories). CodeArtifact stores compiled packages and dependencies, not source code. You use CodeCommit to manage your codebase, and CodeArtifact to manage the libraries your code depends on. (Example: Your Python script is stored in CodeCommit. The 'requests' library your script uses is stored in CodeArtifact.)
- **CodeArtifact vs Amazon S3:** S3 is an object storage service for any file type. While you could theoretically store packages in S3, S3 lacks the package indexing, versioning, proxy caching, and integration with package managers that CodeArtifact provides. CodeArtifact is purpose-built for dependency management. (Example: You could store a .zip file of a package in S3, but npm install wouldn't know how to find it. CodeArtifact exposes a native npm endpoint that pip/npm/Maven can talk to directly.)

## Step-by-step breakdown

1. **Create a CodeArtifact Domain** — A domain is a top-level container that holds repositories. It provides a namespace and allows cross-account sharing. You create one domain per organization or team, usually in a central AWS account.
2. **Create a Repository** — Within the domain, you create one or more repositories. A repository is a logical collection of packages. You can have separate repositories for different package types (npm, PyPI) or different purposes (dev, test, prod).
3. **Configure Upstream Repository (Optional)** — To cache packages from a public registry, you add an upstream connection. For example, you connect your PyPI repository to the public PyPI endpoint. CodeArtifact will then fetch packages from that upstream on demand and cache them.
4. **Authenticate Your Package Manager** — Run the `aws codeartifact login` command. This configures your local package manager (npm, pip, etc.) to point to your CodeArtifact repository. It creates an authentication token that is valid for a configurable period (default 12 hours).
5. **Install or Publish Packages** — Now you can use your normal package manager commands. For example, `npm install` will pull packages from CodeArtifact. To publish your own package, use `npm publish` after configuring the repository as a publish target.
6. **Set Lifecycle Policies (Optional)** — Create lifecycle policies to automatically delete old package versions. For example, you can delete all versions older than 90 days. This saves storage costs and keeps your repository clean.
7. **Monitor and Audit** — Use AWS CloudTrail to log all API calls to CodeArtifact. You can track who published or downloaded which package. These logs are useful for security audits and compliance requirements.

## Practical mini-lesson

Let's walk through a real-world implementation of CodeArtifact for a team building a Node.js application. The goal is to make builds fast, secure, and reliable. Start by creating your domain. In the AWS console, go to CodeArtifact and create a domain named 'my-company-domain'. This domain is regional, so choose a primary region. Then create a repository named 'npm-store' and choose npm as the package format. Add an upstream connection to the public npm registry by selecting 'npmjs.com' from the list. This is the proxy behavior. Now, your developers need to connect. On their local machines, they install the latest AWS CLI and run: `aws codeartifact login --tool npm --domain my-company-domain --repository npm-store`. This command writes an `.npmrc` file that points npm to your CodeArtifact endpoint with an auth token. The token expires, so they might need to rerun the command periodically, ideally in a startup script. For the build server (like CodeBuild), you do the same in the `install` phase of your buildspec. You can use the AWS CLI to fetch a token and configure npm. Now, when the build runs `npm install`, something interesting happens. If the package is already cached in CodeArtifact, it serves instantly, no internet call. If it's the first request for a specific version, CodeArtifact downloads it from the public npm registry, stores it, and serves it. All subsequent builds then get the cached copy. This can cut build times from minutes to seconds. Now, say your team publishes an internal utility package called '@my-company/logger'. You can publish it to the same repository using `npm publish --registry https://my-company-domain-123456.d.codeartifact.us-east-1.amazonaws.com/npm/npm-store/`. Other developers then install it with `npm install @my-company/logger`. No part of this package ever goes public. Security-wise, you can implement package approval workflows. When a new vulnerability is announced, you can delete the affected version from your repository. Then, even if a developer's package.json still asks for that version, the install will fail because the package is no longer available. This forces the team to move to a secure version. A common issue is token expiration in long-running builds. The fix is to refresh the token in the build script before the install step. For example, in buildspec.yml: ` - aws codeartifact login --tool npm --domain my-company-domain --repository npm-store && npm install`. The token lasts for 12 hours by default, which is usually enough for a single build, but for multi-hour tests, consider generating a token with a longer duration. Another issue is that if you change the upstream repository URL, existing cached packages remain untouched, but new packages will come from the new source. Always test changes in a non-production repository first. Professionals also set up separate repositories for different environments: dev, staging, and prod. This prevents accidental use of unapproved packages in production. They also use lifecycle policies to automatically delete packages older than a year in dev repositories, but keep everything indefinitely in prod for audit purposes. By mastering these steps, you can manage dependencies at scale with confidence.

## Memory tip

CodeArtifact caches code components: it's like a library for your libraries, one central place, no more hunting on the internet.

## FAQ

**Can I use CodeArtifact without an AWS account?**

No, CodeArtifact is an AWS service that requires an AWS account. You must have IAM permissions to create and access repositories.

**Is CodeArtifact free?**

CodeArtifact has a free tier (first 2 GB of storage per month and 100,000 requests). After that, you pay for storage and requests. Check the AWS pricing page for current rates.

**Does CodeArtifact support Docker images?**

No, Docker images are stored in Amazon ECR. CodeArtifact is for software packages like npm, PyPI, Maven, and NuGet.

**Can I migrate my existing private npm registry to CodeArtifact?**

Yes, you can publish existing packages to a CodeArtifact repository using standard package manager commands. You may need to script the migration if you have many packages.

**What happens if the upstream registry (e.g., npmjs.org) is down?**

CodeArtifact continues to serve cached packages normally. Only requests for uncached packages will fail. This provides resilience to upstream outages.

**How long does an authentication token last?**

The default expiration is 12 hours, but you can configure it when generating the token using the `--duration-seconds` parameter.

## Summary

AWS CodeArtifact is a fully managed artifact repository service that solves a fundamental problem in modern software development: managing dependencies safely and efficiently. By acting as a central, private store for software packages, it eliminates the unpredictability of relying on public registries. It caches packages on first use, making subsequent builds dramatically faster. It enhances security because you control exactly which package versions are available, and you can remove compromised versions instantly. CodeArtifact supports the most common package formats, npm, PyPI, Maven, NuGet, and generic, and integrates with AWS CI/CD services like CodeBuild and CodePipeline. For the AWS Certified Developer – Associate exam, you must understand its key features: domains for cross-account sharing, upstream repositories for proxy caching, IAM-based authentication, and lifecycle policies for cost management. Common exam scenarios involve improving build speed, securing the supply chain, and sharing packages across accounts. Confusions with ECR and CodeCommit are frequent traps. CodeArtifact is not just a nice-to-have; it is a foundational component for any professional DevOps pipeline that values reliability, speed, and governance. Mastery of this service will serve you well in both the exam and real-world cloud development.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/codeartifact