Day 1 - CodeCommit Deep Dive: What Changes When Git Hosting is Integrated with IAM

CodeCommit appears on the surface to be "a Git server built by AWS". However, falling for this one-liner explanation leads to confusion in both exam questions and real-world operations. The true identity of CodeCommit is a managed repository with the Git protocol layered on top of the IAM/STS authentication system, and this single design decision makes its security model, automation patterns, and cross-account operations fundamentally different from GitHub.

Today's discussion covers: ① how IAM underpins Git and its four authentication variants ② how Git events flow into EventBridge as automation entry points ③ how Approval Rules emulate GitHub's Required Reviewers with branch protection ④ how cross-account CodeCommit works in multi-account environments ⑤ what exam patterns emerge after the July 2024 new customer signup discontinuation.

Once you internalize this picture, it naturally becomes clear where CodeCommit stands in its trade-offs compared to GitHub Enterprise, GitLab, and Bitbucket.

How CodeCommit Integrates with IAM — Internal Workings of Four Authentication Methods

GitHub authenticates via OAuth tokens or SSH keys. GitLab works similarly. CodeCommit, however, regardless of which authentication method is used, ultimately routes through temporary credentials issued by STS to be evaluated by IAM Policy. Let's first understand what this means.

Git protocol (HTTPS or SSH) is originally based on username/password or SSH keys. CodeCommit keeps that protocol intact while diverting the authentication information flowing through it to the IAM evaluation engine. So even though the same git clone command is used, one of four different mechanisms occurs on the backend.

🔍 Deep Dive: Git Credentials (first method) can only be issued to IAM Users, not IAM Roles. Why? Because a Role's credentials are temporary (STS), while Git Credentials must be permanent username/password form. Therefore, in Role-based environments like EC2/Lambda, Credential Helper or GRC is mandatory. This is a decisive hint in exam questions like "how to git push from EC2?"

💡 Related Theory: These four authentication paths are fundamentally an Adapter pattern (Gamma et al., Design Patterns 1994) that bridges the gap between "credential types Git understands" and "credentials IAM requires". When Linus Torvalds designed Git in the late 1990s as a BitKeeper alternative, it only assumed username/password or SSH keys. IAM, by contrast, standardizes on SigV4 signatures + temporary credentials. CodeCommit supporting all four authentication paths is a design compromise to work around this impedance mismatch.

⚠️ Trap: A common exam choice says "storing IAM User's access key in ~/.aws/credentials enables git push". False. That's a credential meant for AWS CLI, not one Git protocol recognizes. Git would need to convert that credential to SigV4 signature to send it, and the tool that performs this conversion is exactly the Credential Helper (!aws codecommit credential-helper $@). Without registering this helper in git config, IAM credentials alone won't make git work.

# Register Credential Helper (standard on EC2/Cloud9/CodeBuild)
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
# Afterward: git clone https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/MyApp

📚 Case Study: A fintech company migrating from GitHub Enterprise to CodeCommit in the early 2020s hit a roadblock with their "MFA enforcement" policy. Federated SSO developers logging into the console couldn't git push. Reason: HTTPS Git Credentials are IAM User-only, so federated users couldn't obtain them. Solution: switch to git-remote-codecommit (GRC). GRC generates SigV4 signatures on every git request using the current AWS profile's credentials (including SSO tokens), so it integrates naturally with MFA and SSO. This case study frequently appears in exams as "CodeCommit access in MFA-enforced organizations" variants.

How Git Events Flow into EventBridge — Automation Entry Point

The point where CodeCommit decisively differs from GitHub is that all repository events are natively published to EventBridge by default. GitHub requires separate webhook setup, you must operate a webhook reception endpoint, and you implement retry, signature verification, and deduplication yourself. CodeCommit delegates that work to EventBridge.

The types of events published are:

After these events flow into EventBridge, usage patterns are nearly limitless. A few standard patterns:

// Auto-trigger build on PR creation
{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Pull Request State Change"],
  "detail": {
    "event": ["pullRequestCreated", "pullRequestSourceBranchUpdated"],
    "repositoryNames": ["MyApp"]
  }
}

// main branch merge → start prod pipeline
{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "detail": {
    "event": ["referenceUpdated"],
    "referenceType": ["branch"],
    "referenceName": ["main"]
  }
}

🔍 Deep Dive: Don't forget EventBridge's at-least-once delivery characteristic. The same PR creation event can rarely be delivered twice. If a single build should run per PR, you must create an idempotency key from pullRequestId + sourceCommit in Lambda and prevent duplicates via DynamoDB conditional write. CodePipeline has built-in behavior to not create new executions for the same source revision (behavior varies by change detection enabled/disabled), but Lambda direct invocation paths must handle dedup themselves.

💡 Related Theory: EventBridge's PutEvents is the practical consequence of "exactly-once is impossible in distributed systems" (Two Generals Problem, 1975, Akkoyunlu·Ekanadham·Huber). All AWS event buses (SQS, SNS, EventBridge, Kinesis) choose at-least-once and shift idempotency responsibility to the consumer. This contrasts with Kafka's exactly-once semantics (EOS), which imposes transactional IDs and sequences on both producer and consumer.

📚 Case Study: A game company built an "auto-Slack notification on PR creation" system with CodeCommit + Lambda. A month later, the same PR alerts occasionally appeared twice in Slack. Root cause: EventBridge's at-least-once delivery occurred once or twice monthly. Solution: Lambda added DynamoDB TTL 5-minute conditional put using pullRequestId + eventVersion as key, and the function exits immediately if already exists. This experience taught the team: "dedup in event-driven automation is not optional; it's mandatory".

Legacy trigger menus (the Triggers tab in the repository) can only directly connect to SNS and Lambda, with limited event filtering. Modern recommendation: EventBridge single path, and AWS official guidance explicitly states that new automations should standardize on EventBridge. In exams, if "latest recommended pattern" is mentioned, EventBridge is the answer.

Approval Rule Template — IAM Version of GitHub's Required Reviewers

GitHub's Required Reviewers operate based on GitHub users/teams. CodeCommit performs the same function based on IAM Principal. This difference becomes its strength in multi-account and federation environments.

Approval Rule Template is structured as follows:

{
  "Version": "2018-11-08",
  "DestinationReferences": ["refs/heads/main", "refs/heads/release/*"],
  "Statements": [
    {
      "Type": "Approvers",
      "NumberOfApprovalsNeeded": 2,
      "ApprovalPoolMembers": [
        "arn:aws:sts::123456789012:assumed-role/SeniorDeveloperRole/*",
        "arn:aws:sts::123456789012:assumed-role/SecurityReviewerRole/*"
      ]
    }
  ]
}

The key trick is using assumed-role ARN patterns in ApprovalPoolMembers. arn:aws:sts::ACCOUNT:assumed-role/RoleName/* means "any session that assumed that Role qualifies as an approver". This is why federated users entering via SSO in the console can naturally approve PRs.

⚠️ Trap: "Can I put IAM User ARN in ApprovalPoolMembers?" Yes, technically possible. However, in federation/SSO environments, users aren't IAM Users but assumed-roles, so User ARN won't match. In exam choices, answers with "User ARN for Approval Pool composition" are rare. The answer is almost always assumed-role ARN pattern.

🔍 Deep Dive: Approval Rule Template is created at the account level, not repository level. After creation, you connect it to repositories via the AssociateApprovalRuleTemplateWithRepository API. This separation is intentional—when you have 50 repositories in an account, you can define a standard like "main branch requires 2 approvals" in one template and apply it to all repositories. In exams, when the scenario says "enforce identical PR approval rules org-wide", the answer is Approval Rule Template + bulk association, not per-repository rules.

💡 Related Theory: This pattern is declarative separation of policy. Think Kubernetes's ClusterRole + ClusterRoleBinding, OPA's policy/data separation. Policy definitions are centralized, application happens through a separate mechanism. Without this separation, you'd copy-paste the same policy 50 times across repositories, and policy changes cause drift.

# Define template at account level
aws codecommit create-approval-rule-template \
  --approval-rule-template-name "Standard-Main-2Reviews" \
  --approval-rule-template-content file://template.json
 
# Apply to multiple repos in bulk (bash loop or IaC)
for REPO in app-frontend app-backend app-worker; do
  aws codecommit associate-approval-rule-template-with-repository \
    --approval-rule-template-name "Standard-Main-2Reviews" \
    --repository-name $REPO
done

CodeCommit vs GitHub Actions/GitLab CI/Bitbucket — Differences Pro Exams Ask About

Pro exams love tool comparisons. You must know exactly how CodeCommit differs from other Git hosting, and what trade-offs exist.

🔍 Deep Dive: Recent exam trends increasingly ask about "OIDC federation from GitHub Actions to AWS". The pattern is established: ① Register GitHub OIDC provider (https://token.actions.githubusercontent.com) in AWS IAM Identity Provider ② Create IAM Role with trust policy containing aud=sts.amazonaws.com + sub=repo:org/repo:ref:refs/heads/main conditions ③ In GitHub Actions workflow, use aws-actions/configure-aws-credentials@v4 with AssumeRoleWithWebIdentity. This is safer than storing static access keys because the keys don't exist. In exams, when asked "how should GitHub Actions safely access AWS?", the answer is almost always OIDC + Role assumption.

💡 Related Theory: OIDC (OpenID Connect, OpenID Foundation 2014) is a standard that adds an authentication layer on top of OAuth 2.0. The key is an ID Token, a JWT containing claims (iss, sub, aud, exp) that verify it was issued by a trustworthy IdP. AWS's OIDC federation converts this JWT via AssumeRoleWithWebIdentity. Compared to static access keys, it's superior in ephemerality, non-sharing, and auditability.

📚 Case Study: In early 2023, a SaaS company storing GitHub Actions AWS access keys statically suffered a key leak when PR logs exposed environment variables (reason: someone added debug echo in PR). Key revocation + rotation + impact analysis took 36 hours. The company then switched to OIDC + IAM Role pattern, making leaks impossible because keys themselves don't exist. In exams, "fork PR secrets access risk" phrasing is almost always a signal about OIDC.

Cross-Account CodeCommit — Standard Configuration for Hub/Spoke Pipelines

In multi-account environments, the standard pattern has CodeCommit in Account A and CodePipeline in Shared Services Account B. For this configuration to work, you must correctly align three IAM surfaces:

1. Account A's CodeCommit Resource Policy: Declares who can read this repository
2. Account B's Pipeline Role's Identity Policy: States that Role has permission to call CodeCommit
3. Pipeline's Source Action's roleArn: Which Role to assume when accessing CodeCommit

All three must align for cross-account to work. If even one is missing, the error message is cryptic (usually "access denied"), making debugging difficult.

// Account A: CodeCommit Repository Resource Policy
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "CrossAccountReadFromB",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::B-ACCOUNT-ID:role/CodePipeline-SourceAccess-Role"
    },
    "Action": [
      "codecommit:GitPull",
      "codecommit:GetBranch",
      "codecommit:GetCommit",
      "codecommit:GetCommitHistory",
      "codecommit:UploadArchive",
      "codecommit:GetUploadArchiveStatus",
      "codecommit:CancelUploadArchive"
    ],
    "Resource": "arn:aws:codecommit:ap-northeast-2:A-ACCOUNT-ID:MyApp"
  }]
}

// Account B: CodePipeline Source Action configuration
{
  "name": "Source",
  "actionTypeId": {
    "category": "Source",
    "owner": "AWS",
    "provider": "CodeCommit",
    "version": "1"
  },
  "roleArn": "arn:aws:iam::B-ACCOUNT-ID:role/CodePipeline-SourceAccess-Role",
  "configuration": {
    "RepositoryName": "MyApp",
    "BranchName": "main",
    "PollForSourceChanges": "false"
  }
}

⚠️ Trap: If KMS keys are missing from the above configuration, it will fail at the artifact encryption stage. CodePipeline's artifact bucket is usually encrypted with customer-managed KMS keys, and in cross-account scenarios, that key's key policy must grant Decrypt/GenerateDataKey permissions to the Role in Account A (or Principals that can assume that Role). In exams, when "cross-account pipeline works on all permissions but fails on artifacts", the answer is almost always missing KMS key policy.

🔍 Deep Dive: CodeCommit's cross-account pattern demonstrates AWS's design philosophy of separating data plane (Git protocol) from control plane (IAM). Git protocol itself uses the HTTPS endpoint directly (public internet), but authentication is handled by IAM, so you need neither VPC peering nor Direct Connect at the network level. This is a frequent exam trap—"VPC Peering required for cross-account CodeCommit access" is always wrong.

💡 Related Theory: Dual evaluation of Resource Policy + Identity Policy is IAM's core principle. In cross-account scenarios, both policies must Allow for access to be granted—"Both policies must allow" rule. Within the same account, only one policy needs to Allow (with certain service exceptions), but cross-account always requires both. This asymmetry, if confusing, warrants re-checking the evaluation order of SCP + Permission Boundary + Resource Policy + Identity Policy.

📚 Case Study: A media company operating CodePipeline across multi-accounts added an SCP guardrail saying "no PR can access prod account's CodeCommit". They wrote codecommit:GitPull with Deny in the SCP but incorrectly configured NotPrincipal, inadvertently blocking even Shared Services' Pipeline Role. Prod deployment was stuck for 30 minutes. Lesson: SCP Deny + NotPrincipal combination is tricky for allowlists—using aws:PrincipalArn conditions or aws:PrincipalOrgID to explicitly specify positive lists is safer.

CodeCommit Sunset — Exam Patterns After July 25, 2024

On July 25, 2024, AWS discontinued new customer signups for CodeCommit. This decision casts a subtle shadow on exam question patterns.

🔍 Deep Dive: The reason for CodeCommit's sunset is unstated, but industry speculation is twofold: ① GitHub (Microsoft)/GitLab's market dominance has stalled new CodeCommit adoption ② AWS internal Amazon Q Developer/CodeWhisperer prioritizes GitHub integration. Exams don't ask about politics, but migration patterns (CodeCommit → GitHub Enterprise → OIDC) are increasingly tested.

📚 Case Study: A large financial institution progressively migrated from CodeCommit to GitHub Enterprise Cloud in late 2024. Pattern: ① Add GitHub repo as mirror destination, sync all pushes bidirectionally via EventBridge → Lambda ② Incrementally transition CodePipeline source actions to GitHub ③ Migrate developer tool chains (Git Credentials → SSH/OIDC) ④ Finally archive CodeCommit repositories as read-only. This sequence is a textbook example of the dual-write/dual-read migration pattern.

Auto Mirroring and DR — Why CodeCommit Doesn't Do Native Cross-Region Replication

CodeCommit doesn't automatically replicate to other regions. This is intentional design. Git itself is a distributed VCS, so "replication" already happens through developer clones, and AWS views additional mirroring as operations responsibility. However, from a DR perspective, it's insufficient—a region-wide outage stops CI/CD.

The standard mirroring pattern is:

[Source Region: ap-northeast-2]
    CodeCommit MyApp
        |
        | EventBridge: referenceUpdated
        v
    Lambda Mirror Function
        |
        | git clone --bare + git push --mirror
        v
[DR Region: us-east-1]
    CodeCommit MyApp-mirror

⚠️ Trap: git push --mirror force-pushes all refs (refs/heads/*, refs/tags/*, refs/notes/* included). If someone pushed directly to the mirror destination, that change would be overwritten. Therefore, the mirror destination must always be read-only (GitPush blocked via Resource Policy).

💡 Related Theory: Git's term "distributed" is easily misunderstood. Git is distributed in data model (merkle DAG) but workflow is almost always centralized (GitHub, GitLab, CodeCommit, etc.). True distributed workflow (p2p, mesh) is used by only a tiny fraction like Linux kernel. So the assumption "it's distributed, so replication must be automatic" is broken—if the central host dies, developer local clones survive but CI/CD stops.

📚 Case Study: A global game studio running CodeCommit and CodePipeline in us-east-1 saw all deployments blocked during the 2021 us-east-1 IAM/STS outage. Post-analysis: ① Mirror CodeCommit to us-west-2, ② configure identical CodePipeline in us-west-2, connect both via EventBridge cross-region targets ③ use Route 53 health check for active/passive failover. After adopting this structure, the next us-east-1 outage saw us-west-2 deployment line automatically activate with ~8-minute RTO.

CodeCommit + CodeGuru Reviewer — Automation Layer for Code Review

CodeGuru Reviewer ML-analyzes PRs to add automated comments. When you associate a CodeCommit repository, automatic analysis starts at PR creation.

🔍 Deep Dive: From 2024 onward, CodeGuru Reviewer is essentially merging into Amazon Q Developer Code Review. Pro exams still ask "connect CodeGuru Reviewer" choices, but in practice Amazon Q is increasingly becoming standard. In exams, choose CodeGuru Reviewer for "automated PR analysis", but be aware that Amazon Q Developer may appear in that role in 2025+ materials.

Frequently Asked Traps and Scenario Patterns in Exams

🎯 Scenario: A company wants "direct push to Production branch (main) forbidden; PR + 2-approval only". Which answer best fits? (a) IAM Policy with codecommit:GitPush Deny + Resource ARN as main branch (b) Create Approval Rule Template requiring 2 approvals for main + Resource Policy blocking push (c) Approval Rule Template + IAM Policy with codecommit:GitPush Deny + Condition codecommit:References = refs/heads/main. Answer is c. CodeCommit's IAM Policy condition key codecommit:References controls push to specific branches, combined with Approval Rule for GitHub-equivalent Branch Protection.

🎯 Scenario: A company wants "auto-build + code coverage on PR creation, post coverage as PR comment". EventBridge → CodeBuild → on build end Lambda → CodeCommit PostCommentForPullRequest API. Which EventBridge event should trigger? (a) pullRequestCreated only (b) both pullRequestCreated and pullRequestSourceBranchUpdated (c) referenceUpdated. Answer is b. Build must re-run both when PR is first created and when source branch updates for PR to stay current.

⚠️ Trap Summary:

• Trap 1: IAM User access key usable directly in git → impossible. Requires Git Credentials or GRC/Credential Helper.
• Trap 2: Cross-account needs VPC Peering → unnecessary. IAM/Resource Policy + Pipeline roleArn suffices.
• Trap 3: CodeCommit auto cross-region replicates → doesn't. Lambda mirroring is standard.
• Trap 4: Approval Rule Template is per-repository → no. Defined at account level + association to repositories.
• Trap 5: Signup discontinued means existing customers can't create new repos → they can.
• Trap 6: CodeGuru Reviewer needs separate IAM Role → service-linked role auto-created, but analysis trigger is event-based after association.

⭐ Key Points (High Exam Frequency)

1. ⭐ CodeCommit's four authentication methods — Git Credentials (User-only), SSH (User-only), Credential Helper (Role possible), GRC (SSO/MFA). Answer hinges on whether scenario user is IAM User or Role/federation.
2. ⭐ All git events auto-published to EventBridge — automation entry point. No separate webhook operation.
3. ⭐ Approval Rule Template is account-level, applied via association to repos. ApprovalPoolMembers uses assumed-role ARN patterns.
4. ⭐ Cross-account = Resource Policy(A) + Identity Policy(B) + Pipeline Source Action's roleArn + KMS Key Policy. Missing even one causes failure.
5. ⭐ July 25, 2024 new signup discontinued; existing customers can still create new repos normally. Migration scenarios increasingly appear.
6. ⭐ No native cross-region replication. EventBridge → Lambda → git push --mirror pattern.
7. ⭐ GitHub Actions → AWS via OIDC + AssumeRoleWithWebIdentity is the answer pattern.

📌 Today's Summary

The value of CodeCommit is not the outer shell of "Git hosting made by AWS" but the combination of the Git protocol with IAM/STS. This combination makes possible all of the following: ① the four authentication methods, ② native EventBridge events, ③ Approval Rule Templates, and ④ multi-account Resource Policy patterns. Although migration scenarios have increased since new sign-ups were halted in 2024, it remains a frequently tested area on the exam, and it is also good to learn the newly emerging GitHub OIDC federation pattern together. Tomorrow we look more deeply at the Git workflow itself (trunk-based vs GitFlow) and branching strategies on top of CodeCommit.