What is version control?

Version control is a system that remembers every change ever made to a set of files, who made it, when, and why. Instead of one file called report_final_v3_REALLYFINAL.docx, version control keeps one file with a complete, searchable history of every edit — so you can always go back to any earlier version, compare two versions, or figure out exactly which change broke something.

What is Git?

Git is the most widely used version control system in the world, created in 2005 by Linus Torvalds (the same person who created Linux). Git stores a project as a series of snapshots called commits. Each commit is like a save-point in a video game — you can jump back to any save-point at any time. A collection of commits lives inside a repository (or “repo” for short), which is really just a folder that Git is watching closely.

What is AWS CodeCommit, specifically?

AWS CodeCommit is a fully managed source control service that hosts private Git repositories in the AWS Cloud. “Fully managed” means AWS runs the servers, handles the storage, replicates your data, patches the software, and scales the service — you never provision a server or worry about disk space. You simply create a repository and start pushing (uploading) and pulling (downloading) code using the same git commands developers already use with services like GitHub or GitLab. The difference is that CodeCommit repositories live entirely inside your AWS account, protected by AWS Identity and Access Management (IAM) instead of a separate username-and-password system.

Why would a team choose it (or have chosen it)?

Three reasons kept teams on CodeCommit for years: it lives inside the same AWS account as everything else, so permissions are managed with the same IAM roles used for EC2, S3, and Lambda; it never leaves AWS’s network boundary, which matters for regulated industries like banking and healthcare; and it plugs directly into AWS’s own build and deploy tools — CodeBuild, CodeDeploy, and CodePipeline — with almost no configuration.

When you interact with CodeCommit, you never see AWS’s internal machinery — you just run familiar git commands. But underneath, several components cooperate to make that possible.

flowchart TB
    Dev1["Developer A
(git client)"] -->|"git push (HTTPS/SSH)"| Endpoint["CodeCommit
Git Protocol Endpoint"]
    Dev2["Developer B
(git client)"] -->|"git push (HTTPS/SSH)"| Endpoint
    Endpoint --> IAM["AWS IAM
Authentication & Authorization"]
    IAM --> Repo["CodeCommit Repository
(commits, branches, tags)"]
    Repo --> Storage["Durable Storage Layer
(replicated across AZs)"]
    Repo --> KMS["AWS KMS
Encryption at Rest"]
    Repo -->|"push event"| EventBridge["Amazon EventBridge / SNS"]
    EventBridge --> Pipeline["AWS CodePipeline"]
    Pipeline --> Build["AWS CodeBuild
(compile & test)"]
    Build --> Deploy["AWS CodeDeploy
(release to EC2/ECS/Lambda)"]
    Repo --> CW["Amazon CloudWatch
Metrics & Logs"]
    Repo --> CT["AWS CloudTrail
API Audit Log"]
        

Notice that CodeCommit itself only handles the “storage and version history” job. Everything else — building the code, running tests, deploying it — is deliberately handed off to specialist services. This is a hallmark of AWS’s design philosophy: small, focused services connected by events, rather than one giant service trying to do everything.

Step 1 — Clone. A developer runs a clone command to download a full copy of the repository, including its entire history, onto their laptop. From this point on, they have every past commit available locally, even without internet access.

Step 2 — Branch. Rather than editing the shared main branch directly, the developer creates a new branch — a separate, safe line of work — to build their feature without disturbing anyone else.

Step 3 — Commit locally. As they work, they save snapshots (commits) to their local copy of the branch. Nothing is uploaded yet; this is all happening on their own machine.

Step 4 — Push. When ready, they push their branch up to CodeCommit, making their work visible to the team for the first time.

Step 5 — Pull request. They open a pull request (CodeCommit calls it exactly that), which is a formal proposal to merge their branch into main. Teammates can leave comments on specific lines, request changes, and approve.

Step 6 — Merge. Once approved, the pull request is merged, combining the feature branch’s commits into main. CodeCommit supports three merge strategies: fast-forward, squash (combining all commits into one), and three-way merge.

Step 7 — Automated reaction. The merge event fires, and a connected CodePipeline pipeline can automatically build, test, and deploy the newly merged code — all without a human manually triggering anything.

Git itself is already efficient — it only transfers the differences between what you have and what has changed, not the entire repository every time. CodeCommit inherits this efficiency and adds AWS’s own scaled storage infrastructure underneath, so repository size and commit history length are handled transparently as they grow.

Scalability here means two different things: how large a single repository can grow, and how many repositories and users an organization can operate. CodeCommit scales along both axes automatically — you never provision more “capacity” the way you would size an EC2 instance. Very large monorepos (single repositories holding an entire company’s code) can, however, hit practical Git performance limits regardless of hosting provider, which is a Git characteristic rather than something specific to CodeCommit.

CodeCommit stores repository data redundantly across multiple Availability Zones within a Region — physically separate data centers connected by low-latency links. If one Availability Zone experiences a problem, your repository data remains accessible from the others, without any action needed from you.

Because CodeCommit is a regional service, a full AWS Region outage would affect it — the same as almost every other regional AWS service. For most teams, Multi-AZ durability within a Region is more than sufficient, since local Git clones (every developer’s laptop already has a full copy of the history) act as an additional layer of resilience.

Visibility into a source control system answers two questions: “is the service healthy?” and “who did what, and when?” CodeCommit answers both through existing AWS observability services rather than a bespoke dashboard.

A typical AWS-native continuous delivery setup looks like this: code lives in CodeCommit; a push or merge event triggers AWS CodePipeline, which orchestrates the release process; AWS CodeBuild compiles the code and runs automated tests inside a temporary, isolated container; and AWS CodeDeploy ships the tested build out to its destination — whether that’s a fleet of EC2 instances, an ECS cluster running containers, or a Lambda function.

Because every one of these services is IAM-aware, permissions flow naturally: a CodePipeline service role is granted read access to a specific CodeCommit repository, and nothing more — following the security principle of least privilege discussed in Chapter 8.