AWS CodeCommit

CodeCommit is closed to new customers. Since mid-2024, AWS has not onboarded new accounts to it, if your account has never created a CodeCommit repository, you cannot start now, and the service does not appear as an option. Accounts with prior usage keep full access, and AWS continues to operate and support existing repositories.

So this page is for two audiences: teams operating a repository they already have, and teams deciding whether to keep it. If you are choosing a Git host today, the answer is GitHub, GitLab or Bitbucket, and the migration section below is probably the part you want.

There is no announced end-of-life date. Existing repositories are not at immediate risk, but a service receiving no new customers is unlikely to receive significant new features either, which is the practical consideration.

Why it was used

It is worth being fair about the genuine advantages, because they are the things you lose by migrating.

IAM as the only access control. No separate user directory, no SSO integration to maintain, no license seats. Someone who leaves loses repository access when their IAM identity is removed, with nothing else to remember.

Nothing leaves your account. For organisations where code cannot sit with a third party, that is occasionally a hard requirement rather than a preference.

No per-user cost beyond a small free tier, and traffic to other AWS services stays inside AWS.

Against that: no pull request experience comparable to GitHub or GitLab, no built-in CI beyond CodePipeline, no issue tracking, no package registry, and an ecosystem of integrations that is essentially empty.

Working with an existing repository

The cleanest authentication is git-remote-codecommit, which uses your normal AWS credentials, including SSO and assumed roles, with no separate Git credentials to create:

pip install git-remote-codecommit
git clone codecommit::eu-west-1://orders-api

# With a named profile
git clone codecommit::eu-west-1://my-profile@orders-api

That codecommit:: URL form is the one to use. HTTPS Git credentials are generated per IAM user, which does not work with SSO or roles at all, and SSH keys mean uploading a public key to each IAM user. Both are legacy approaches that exist because git-remote-codecommit came later.

aws codecommit list-repositories --query 'repositories[].repositoryName' --output table

aws codecommit get-repository --repository-name orders-api \
  --query 'repositoryMetadata.[cloneUrlHttp,defaultBranch,lastModifiedDate]'

Approval rules are the closest thing to branch protection

aws codecommit create-approval-rule-template \
  --approval-rule-template-name require-two-reviews \
  --approval-rule-template-content '{
    "Version": "2018-11-08",
    "DestinationReferences": ["refs/heads/main"],
    "Statements": [{
      "Type": "Approvers",
      "NumberOfApprovalsNeeded": 2,
      "ApprovalPoolMembers": ["arn:aws:sts::123456789012:assumed-role/Developer/*"]
    }]
  }'

aws codecommit associate-approval-rule-template-with-repository \
  --approval-rule-template-name require-two-reviews \
  --repository-name orders-api

Note what this does not do: it requires approvals on pull requests, and it does not prevent a direct push to main. For that you need an IAM policy denying the push:

{
  "Effect": "Deny",
  "Action": ["codecommit:GitPush", "codecommit:DeleteBranch", "codecommit:PutFile"],
  "Resource": "arn:aws:codecommit:eu-west-1:123456789012:orders-api",
  "Condition": {
    "StringEqualsIfExists": { "codecommit:References": ["refs/heads/main"] },
    "Null": { "codecommit:References": "false" }
  }
}

That two-part arrangement, approval rule template plus IAM deny, is the CodeCommit equivalent of a single "protect this branch" checkbox elsewhere, and it is a fair illustration of the ergonomic gap.

Triggers and notifications

aws codecommit put-repository-triggers --repository-name orders-api \
  --triggers '[{
    "name": "build-on-main",
    "destinationArn": "arn:aws:sns:eu-west-1:123456789012:builds",
    "branches": ["main"],
    "events": ["updateReference"]
  }]'

EventBridge is the better route for anything beyond SNS, since it can target Lambda, Step Functions or a pipeline directly:

{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "detail": { "event": ["referenceCreated", "referenceUpdated"], "referenceName": ["main"] }
}

Migrating out, with history intact

A Git repository is self-contained, so moving the code itself is genuinely easy. --mirror carries every branch, tag and ref:

git clone --mirror codecommit::eu-west-1://orders-api orders-api.git
cd orders-api.git

git remote set-url --push origin git@github.com:acme/orders-api.git
git push --mirror

Verify nothing was left behind:

git ls-remote codecommit::eu-west-1://orders-api | wc -l
git ls-remote git@github.com:acme/orders-api.git | wc -l

For a large repository, or one with LFS objects, fetch LFS content explicitly first:

git lfs fetch --all
git lfs push --all git@github.com:acme/orders-api.git

What does not migrate is the part that takes the time: pull requests and their comments, approval rule templates, repository triggers, and any IAM policies granting access. Plan for rewriting the access model rather than translating it. CodeCommit's IAM-based permissions have no direct equivalent in a system with its own user and team model.

Sequence that works well: mirror the repository, set up CI on the new host and confirm it passes, switch developers over, leave CodeCommit read-only for a few weeks as a fallback, then archive it.

# Make the old repository read-only via IAM rather than deleting it
# (a Deny on codecommit:GitPush for all principals)

Where to go

If keeping code inside your AWS account is a hard requirement, GitLab or GitHub Enterprise Server can be self-hosted on EC2, which trades a managed service for an operational burden, and is worth costing properly before choosing it.

All of the alternatives integrate with CodePipeline and CodeBuild through CodeStar Connections, so an AWS-based pipeline does not need rebuilding:

aws codestar-connections create-connection \
  --provider-type GitHub --connection-name github-acme

The connection requires a one-time authorisation in the console, which is the only manual step.

Common errors

fatal: unable to access 'https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/orders-api/':
The requested URL returned error: 403

Expired credentials, a missing IAM permission, or HTTPS Git credentials being used with an assumed role, which does not work. Use git-remote-codecommit.

fatal: 'codecommit::eu-west-1://orders-api' does not appear to be a git repository

git-remote-codecommit is not installed, so Git does not recognise the helper.

An error occurred (AccessDeniedException) when calling the CreateRepository
operation

If your account has no CodeCommit history, this is the service being closed to new customers rather than a policy problem.

Quick reference

---

Key takeaways

• CodeCommit is closed to new AWS customers since mid-2024, with no announced end-of-life.
• Choosing a Git host today means GitHub, GitLab or Bitbucket.
• Use git-remote-codecommit: HTTPS Git credentials and SSH keys are per-IAM-user and do not work with SSO or roles.
• Approval rules gate pull requests but do not block direct pushes. An IAM deny does that.
• git clone --mirror plus git push --mirror moves all history, branches and tags.
• Pull requests, comments, triggers and IAM policies do not migrate. Budget for that, not the code.
• Keep the old repository read-only for a few weeks rather than deleting it.
• CodeStar Connections lets CodePipeline keep working against an external host.

---

Check your understanding

---

Frequently Asked Questions

Can I still use AWS CodeCommit?

Only if your AWS account already used it. AWS stopped onboarding new customers in mid-2024, so an account with no prior CodeCommit repositories cannot create one, CreateRepository is refused. Accounts with existing usage keep full access to create and operate repositories, and AWS continues to run and support the service with no announced end-of-life. The practical implication is that a service closed to new customers is unlikely to gain significant new features.

Should I migrate away from CodeCommit?

Not urgently, but plan for it. Existing repositories keep working and there is no announced shutdown, so this is not a fire. What you are giving up by staying is feature development, third-party integrations and the pull request experience that GitHub and GitLab have continued improving. If your repositories are active and your team spends time in code review, migrating is worth scheduling. If they hold stable code that rarely changes, leaving them alone is defensible.

How do I authenticate to CodeCommit properly?

Install git-remote-codecommit and clone with the codecommit::region://repo URL form. It uses your normal AWS credential chain, so SSO, assumed roles and named profiles all work. The older options, HTTPS Git credentials and SSH keys, are generated per IAM user, which means they do not work with SSO or role assumption at all, and they exist mainly because the credential helper arrived later. The codecommit:: form is the one to standardise on.

How do I protect the main branch in CodeCommit?

Two separate pieces, which is one of the clearer ergonomic gaps. An approval rule template associated with the repository requires a number of approvals on pull requests targeting refs/heads/main. That alone does not stop a direct push, so you also need an IAM policy denying codecommit:GitPush and codecommit:DeleteBranch on that reference, using the codecommit:References condition key. Elsewhere this is a single checkbox.

How do I migrate a CodeCommit repository to GitHub without losing history?

git clone --mirror codecommit::eu-west-1://repo, then set the push URL to the new host and git push --mirror. That transfers every commit, branch and tag with unchanged hashes, and usually takes minutes. Verify by comparing git ls-remote output from both hosts. If the repository uses Git LFS, run git lfs fetch --all and git lfs push --all separately, since mirror does not carry LFS objects.

What does not transfer when migrating from CodeCommit?

Everything except the Git data. Pull requests and their review comments stay behind, as do approval rule templates, repository triggers and any notification rules. The access model needs rebuilding too, because CodeCommit permissions are IAM policies while GitHub and GitLab have their own users, teams and roles. There is no translation. Budget time for that rather than for the code, keep the old repository read-only for a few weeks as a fallback, and use CodeStar Connections so existing CodePipeline setups keep working.