Skip to content

AWS Updated 2025-12-07

AWS CodeCommit vs GitHub: when CodeCommit is still the right call (and when it isn't)

AWS stopped onboarding new CodeCommit customers in 2024. For existing users the question is now binary — keep it for the residency and IAM wins, or migrate before deprecation forces a rushed cutover.

A founder forwards the AWS announcement: as of July 25, 2024, no new customers can onboard to CodeCommit. Existing repos keep working, existing accounts keep access, but the service has been moved into “maintenance mode” with no roadmap. The team’s CodeCommit repos still run CodePipeline triggers, the IAM model is wired into their identity strategy, and migrating off would touch CI, build, and the developer experience. The right call is not “panic-migrate” and not “ignore” — it’s a deliberate read of where CodeCommit still wins, where GitHub wins, and where the deprecation horizon changes the math.

What’s happening

CodeCommit shipped in 2015 as the AWS-native answer to hosted Git. Its design value was never the Git UX — the web UI was always thin, the PR review experience was always weaker than GitHub. The value was three things: identity flowed through IAM (no separate user directory), data stayed inside the AWS account boundary (residency, audit logs in CloudTrail), and CodePipeline / CodeBuild integrated natively without an OAuth handshake.

In July 2024, AWS announced no new customers. The wording was careful: existing customers retain access, the service is not “deprecated” with a sunset date, but there’s no new feature work. The pattern matches what AWS did with CodeStar — quiet retirement over multi-year horizons. The right read is that CodeCommit will keep running for years for existing accounts, and the migration cost will only grow as your repo count, history, and CI dependencies grow.

GitHub’s design value moved in the opposite direction. The PR experience is the industry default for code review. Actions ate most of the standalone CI market. Copilot inverted the cost calculus on closed source — engineers expect the assist, and CodeCommit has no equivalent. Open-source visibility on GitHub is a hiring signal; on CodeCommit it doesn’t exist.

The honest read on where each still wins:

  • CodeCommit wins when the workload must stay inside one AWS account boundary (data residency, regulated workloads where the customer’s audit perimeter ends at the AWS account), when IAM federation is the only identity story (no SAML/OIDC to GitHub), and when CodePipeline integration is the dominant deploy path and the team has no appetite to maintain GitHub Actions or a webhook bridge.
  • GitHub wins in every other case. Open-source code, Copilot in the IDE, Actions ecosystem (Marketplace, reusable workflows, OIDC-to-AWS without long-lived keys), and the deeper PR review tooling (CODEOWNERS, branch protection rules, required reviewers tied to teams, merge queue) all live on GitHub and are not coming to CodeCommit.

The single asymmetry that matters: a CodeCommit-to-GitHub migration is mechanical and well-trodden. A GitHub-to-CodeCommit migration in 2026 is a choice nobody is making. The deprecation announcement turned a two-way decision into a one-way ratchet.

How to verify

Three questions resolve which side of the line your workload sits on. Run them on a representative repo before deciding.

# 1. How tightly is the repo wired to CodePipeline triggers vs generic webhooks?
aws codepipeline list-pipelines --query 'pipelines[].name' --output text | \
  while read p; do
    aws codepipeline get-pipeline --name "$p" \
      --query 'pipeline.stages[].actions[?actionTypeId.provider==`CodeCommit`].configuration' \
      --output json
  done

Output that returns a long list means CodePipeline is the deploy path and a migration must replace those triggers. Empty output means CodePipeline is decorative and the repo is migration-ready.

# 2. How many distinct IAM principals hold codecommit:* permissions?
aws iam get-account-authorization-details \
  --query 'Policies[?DefaultVersion.Document.Statement[?Action[?contains(@, `codecommit`) == `true`]]].PolicyName' \
  --output text

A small list (under 10) means the identity model is contained; you can recreate equivalent GitHub team permissions in an afternoon. A long list spanning custom inline policies on dozens of roles means the migration touches IAM widely.

# 3. How much history does the repo carry?
git clone codecommit::us-east-1://my-repo /tmp/audit && \
  cd /tmp/audit && \
  echo "Commits: $(git rev-list --all --count)" && \
  echo "Refs: $(git for-each-ref | wc -l)" && \
  echo "LFS objects: $(git lfs ls-files | wc -l)" && \
  echo "Size: $(du -sh .git | cut -f1)"

Repos under 1 GB with simple ref trees migrate in an afternoon. Repos with LFS, hundreds of branches, or submodules need the migration runbook and a longer cutover window.

The fix

The decision flow, sequenced by what changes the math:

  1. Confirm the workload’s residency constraint. If the contract or regulator requires that source code stays inside a Canadian AWS region under the customer’s AWS account, CodeCommit is the only Git-on-AWS service that satisfies that today without standing up Gitea or GitHub Enterprise Server on EC2. The trade-off is accepting the deprecation overhang. See Git-on-AWS options after CodeCommit deprecation for the alternatives if the residency story can move.

  2. Audit CI and identity surface area. Use the queries above to enumerate CodePipeline triggers and IAM principals. A repo with two CodePipeline triggers and a handful of IAM roles is a half-day migration. A repo whose triggers fan out to twelve pipelines, each with custom IAM, is a multi-week project — and the deprecation horizon is still long enough to plan it properly rather than panic-cutover.

  3. Decide on a horizon, not a date. AWS has not announced a CodeCommit shutdown date. Acting as if there is one tomorrow leads to rushed cuts; acting as if there will never be one leads to a panic migration when the date does land. Set an internal horizon (we use Q4 2026 for any repo that doesn’t have a hard residency constraint) and migrate against it deliberately.

  4. Migrate the easy repos first. Repos with shallow CodePipeline integration, small history, and no LFS are the warm-up. They surface the GitHub Actions patterns, the OIDC-to-AWS federation, and the team workflow changes. By the time the harder repos need to move, the pattern is in muscle memory.

  5. Keep the IAM perimeter even after migration. GitHub Actions calling AWS via OIDC (aws-actions/configure-aws-credentials) gives you short-lived credentials and a cleaner audit story than long-lived access keys. The IAM control you had with CodeCommit doesn’t go away — it moves to the role-assumption boundary. Many teams use the migration as the occasion to retire static AWS keys altogether.

Two rules we hold across migrations:

Don’t argue the migration on developer preference alone. The PR review experience on GitHub is better, but that’s not the case for moving an organization’s source of truth. The cases that move repos are deprecation risk, CI velocity, and identity simplification. Lead with those.

Don’t migrate the audit perimeter without re-doing the threat model. CodeCommit data is inside the customer’s AWS account; GitHub data is in GitHub’s tenant. For most workloads that’s fine. For workloads where the contract specifies data location, the move is a contract amendment, not a deploy. Surface that early.

A team that decides today to stay on CodeCommit for two more years is making a defensible call. A team that finds out from a deprecation banner that they have ninety days to migrate is making a much worse one. The point of the decision is to own the horizon.

Stack Harbor runs CodePipeline + CodeCommit (and the GitHub-on-AWS variants) as part of Managed AWS onboarding and ongoing Managed Cloud Ops. If you need to read the CodeCommit horizon honestly before committing to a migration, start with an infrastructure consult.