AWS CodeCommitとは？使い方と再開後の扱い・GitHub移行の実例

CodeCommit は、GitHub と同じく Git のリポジトリを置く場所です。違いは、AWS のアカウントの中にあり、IAM（AWS の権限の仕組み）で誰が読めるか・書けるかを決める点です。手元の Git から3通りの方法でつなぎ、CodePipeline・CodeBuild などの AWS のサービスへ流します。

flowchart TD
    L[手元の Git] -->|HTTPS 認証情報| C[(CodeCommit<br>リポジトリ)]
    L -->|git-remote-codecommit| C
    L -->|SSH 鍵| C
    C --> P[CodePipeline]
    P --> B[CodeBuild]
    B --> D[CodeDeploy など]
    C -.->|mirror で移す| G[GitHub など]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、AWS には接続せず、AWS のサービスをまねる moto 5.2.5（サーバーモード）を 127.0.0.1 のポートに起動し、aws-cli 1.46.2（pip で入れた v1。Python 3.13.18・botocore 1.43.122）から --endpoint-url でつないで create-repository・get-repository・delete-repository を実行しました。鍵は testing というダミーの値だけを使い、この環境の本物の認証情報は env -i で外しています。moto 5.2.5 の CodeCommit が対応しているのはこの3つだけで、put-file・create-branch・list-repositories は moto のログに NotImplementedError が出ました（その出力も載せます）。put-file などの引数は、aws-cli 同梱の API 定義と AWS CLI リファレンスで確かめています。Git 2.43.0 で、ローカルのベアリポジトリを CodeCommit に見立てて git clone --mirror と git push --mirror を実行し、認証情報ヘルパー（aws codecommit credential-helper）は通信せずに手元で署名だけを作らせました。新規受付の停止と再開、料金、クォータ、接続方法、トラブルシューティングは AWS の公式ブログとユーザーガイドで、GitHub のファイルの上限は GitHub Docs で確かめました。図は mermaid で描画を確かめています（確認日 2026年10月29日）。

AWS CodeCommitとは（何ができるサービスか）

この節では、CodeCommit がどんなサービスで、ほかの Git のサービスと何が同じで何が違うのかが分かります。

AWS CodeCommit は、AWS が運用する、プライベートな Git リポジトリのサービスです。 サーバーを立てたり、容量を増やしたりする手間は AWS が受け持ちます。中身はふつうの Git なので、git clone・git push・git pull といういつものコマンドがそのまま使えます。

ほかのサービスと比べたときの特徴は、次の3つです。

保存されたデータは、送るときも置いておくときも暗号化されます。暗号化の鍵には AWS KMS（鍵を管理するサービス）を使い、自分で管理する鍵（カスタマー管理キー）も指定できます。CLI でリポジトリを作るとき、create-repository の引数に --kms-key-id があるのはこのためです。

CodeCommitは使える？新規受付の停止と再開（2026年10月29日時点）

この節では、「CodeCommit は廃止されたのでは」という疑問への答えと、2024年から2025年にかけての扱いの変化が分かります。

2026年10月29日時点で、CodeCommit は一般提供（GA）の状態で、新しく使い始めることもできます。 一度は新規の受け付けを止めていたため、その時期に書かれた記事やエラーの情報が今も多く残っています。

1. 12024年7月25日：新規のお客様への提供を停止ユーザーガイドの履歴に「CodeCommit is no longer available to new customers. Existing customers of AWS CodeCommit can continue to use the service as normal.」と記載。同じ日に、別の Git サービスへ移す方法の公式ブログが出た
2. 2停止中：リポジトリを持つアカウントだけが新しく作れたAWS re:Post では、すでに CodeCommit のリポジトリがあるアカウントだけが追加で作れ、既存の使い方には影響が無いと説明された
3. 32025年11月24日：一般提供へ戻り、新規受付を再開公式ブログ「AWS CodeCommit Returns to General Availability」。29のリージョンで提供、料金と 99.9% の SLA は変わらない
4. 42025年11月25日：ユーザーガイドの履歴にも反映「AWS CodeCommit is now available to new customers.」と記載
5. 5今後の予定：Git LFS（2026年第1四半期）と、リージョンの追加（2026年第3四半期から）同じ公式ブログが示した予定。リージョンは eu-south-2 と ca-west-1

再開を知らせた公式ブログは、移行を進めていた利用者に向けて「すでに他のサービスへ移した場合はその判断を支持する」「移行の途中なら止めたり戻したりできるので、AWS サポートかアカウントの担当に相談を」と書いています。再開の理由は「AWS が管理するコードリポジトリが必要だという声が多かった」と説明されています。

2026年10月29日時点で気をつけること

• 日本語の料金ページには、停止の告知が残っていました。 2026年10月29日に確かめたとき、日本語の料金ページの冒頭には「新規のお客様は利用できない」という趣旨の記載があり、英語のページ・ユーザーガイドの履歴・公式ブログは再開を示していました。扱いを確かめるときは、英語のユーザーガイドの「Document history」を見るのが確実です。
• Git LFS は「予定」として公表されたものです。 2026年10月29日時点のユーザーガイドの履歴には、Git LFS に対応したという記載は見当たりませんでした。大きなバイナリを置く予定があるなら、使う前に履歴と「What's New」で提供の状況を確かめます。

CodeCommitの料金とクォータ（上限）

この節では、CodeCommit の料金の数え方と、ファイルの大きさやリポジトリの数の上限が分かります。

料金は「その月にアクセスしたユーザーの数」と、無料の量を超えたストレージ・Git リクエストで決まります。 公式の料金ページ（英語版、2026年10月29日時点）は次のように説明しています。

アクセスしなかったユーザーには料金がかかりません。また、使わなかった無料の量は翌月に繰り越されません。CodeBuild や CodePipeline のロールも1人と数える点は見落としやすく、人の数だけで見積もると合わなくなります。

CodeCommitのクォータ（主な上限）

ユーザーガイドの「Quotas」から、つまずきやすいものを抜き出しました。

画面や API から入れるファイルは 6 MB まで、git push なら blob 1つ 2 GB まで、と経路で上限が違います。

CodeCommitの使い方の全体像（作成からpushまで）

この節では、CodeCommit を使い始めて最初の push をするまでの順番が分かります。

流れは「リポジトリを作る → 使う人に IAM の権限を付ける → 接続方法を1つ選んで準備する → clone して push する」です。 公式のユーザーガイドの手順を、つまずきやすい点と一緒にまとめます。

Git は 1.7.9 以降が対象です。空のリポジトリを clone したときの表示は、手元のベアリポジトリで同じものが出ました。

$ git clone src/MyDemoRepo.git work
Cloning into 'work'...
warning: You appear to have cloned an empty repository.
done.

Git のコマンドそのものの使い方は、関連記事「git remoteの変更・追加・削除とpush rejectedの対処法」で扱っています。

aws cliでCodeCommitを操作する（aws codecommitコマンドの実行結果）

この節では、aws codecommit のよく使うコマンドと、実際に返ってくる JSON・エラーの形が分かります。

AWS には接続せず、AWS の API をまねる moto を 127.0.0.1 で動かし、aws cli を --endpoint-url でそこへ向けて実行しました。 鍵はダミーの testing、リージョンは ap-northeast-1 です。

env -i PATH=/dev/shm/t143/venv/bin:/usr/bin:/bin HOME=/dev/shm/t143/home \
  AWS_ACCESS_KEY_ID=testing AWS_SECRET_ACCESS_KEY=testing \
  AWS_DEFAULT_REGION=ap-northeast-1 \
  aws --endpoint-url http://127.0.0.1:5143 codecommit create-repository \
  --repository-name MyDemoRepo --repository-description "t143 demo"

{
    "repositoryMetadata": {
        "accountId": "123456789012",
        "repositoryId": "3dac5902-58d4-438d-938e-2646f3a57f82",
        "repositoryName": "MyDemoRepo",
        "repositoryDescription": "t143 demo",
        "lastModifiedDate": "2026-10-30T14:29:34.112Z",
        "creationDate": "2026-10-30T14:29:34.112Z",
        "cloneUrlHttp": "https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MyDemoRepo",
        "cloneUrlSsh": "ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MyDemoRepo",
        "Arn": "arn:aws:codecommit:ap-northeast-1:123456789012:MyDemoRepo"
    }
}

返ってくる cloneUrlHttp と cloneUrlSsh が、git clone に使う URL です。 形は https://git-codecommit.<リージョン>.amazonaws.com/v1/repos/<リポジトリ名> で、リージョンが URL に入ります。ARN（AWS のリソースの名前）は IAM のポリシーで対象を絞るときに使います。

get-repositoryと--queryで必要な値だけ取る

$ aws --endpoint-url http://127.0.0.1:5143 codecommit get-repository \
    --repository-name MyDemoRepo \
    --query 'repositoryMetadata.[repositoryName,cloneUrlHttp]' --output text
MyDemoRepo	https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MyDemoRepo

手元で出たエラーの原文

$ aws ... codecommit get-repository --repository-name NoSuchRepo
An error occurred (RepositoryDoesNotExistException) when calling the GetRepository operation: NoSuchRepo does not exist

$ aws ... codecommit get-repository --repository-name mydemorepo
An error occurred (RepositoryDoesNotExistException) when calling the GetRepository operation: mydemorepo does not exist

$ aws ... codecommit create-repository --repository-name MyDemoRepo
An error occurred (RepositoryNameExistsException) when calling the CreateRepository operation: Repository named MyDemoRepo already exists

$ aws ... codecommit create-repository --repository-name 'bad name!'
An error occurred (InvalidRepositoryNameException) when calling the CreateRepository operation: The repository name is not valid. Repository names can be any valid combination of letters, numbers, periods, underscores, and dashes between 1 and 100 characters in length. Names are case sensitive. For more information, see Limits in the AWS CodeCommit User Guide.

$ aws ... codecommit put-file --repository-name MyDemoRepo
aws: error: the following arguments are required: --branch-name, --file-content, --file-path

motoでは動かなかった操作と、本物のAWSとの違い

moto 5.2.5 の CodeCommit は create-repository・get-repository・delete-repository の3つだけに対応していました。put-file・create-branch・list-repositories は、サーバー側で次のエラーになり、aws cli は 500 を受けて4回再試行してから止まりました（moto のログに同じ要求が5回ずつ届いています）。

An error occurred (500) when calling the PutFile operation (reached max retries: 4): <!doctype html>
<title>500 Internal Server Error</title>

（moto のログ）
NotImplementedError: The put_file action has not been implemented
NotImplementedError: The create_branch action has not been implemented
NotImplementedError: The list_repositories action has not been implemented

また、moto は demo.git という名前や101文字の名前でもリポジトリを作れました。公式のクォータでは「.git で終われない」「100文字まで」なので、本物の AWS では断られる名前です。moto は名前の検査や未対応の操作が本物と違うので、テストに使う範囲を決めて使います。

aws cli の設定とプロファイルの切り替えは、関連記事「AWS CLI設定｜aws configureとprofile切り替え・優先順位」で扱っています。

aws codecommitのよく使うコマンド一覧（ブランチ・ファイル・プルリクエスト）

この節では、Git を使わずに CLI だけでファイルを入れたり、ブランチやプルリクエストを作ったりする書き方が分かります。

CodeCommit の API には80の操作があります（aws-cli 同梱の API 定義で数えた値）。 よく使うものを、必須の引数とあわせてまとめます。必須の引数は API 定義の required で確かめました。

承認とマージは名前が長いコマンドです。承認は update-pull-request-approval-state（必須は --pull-request-id・--revision-id・--approval-state）、早送りのマージは merge-pull-request-by-fast-forward（必須は --pull-request-id・--repository-name）です。

書き方の例です（本物の AWS で動かすときの形。この環境では moto が未対応のため、引数の検査までを確かめています）。

# ファイルを1つ入れる（最初のコミットなら --parent-commit-id は不要）
aws codecommit put-file --repository-name MyDemoRepo --branch-name main \
  --file-path README.md --file-content fileb://README.md \
  --commit-message "add README" --name "t143 demo" --email demo@example.com

# main の先頭のコミットIDを取り、そこからブランチを作る
COMMIT=$(aws codecommit get-branch --repository-name MyDemoRepo \
  --branch-name main --query 'branch.commitId' --output text)
aws codecommit create-branch --repository-name MyDemoRepo \
  --branch-name feature/login --commit-id "$COMMIT"

# feature/login から main へのプルリクエスト
aws codecommit create-pull-request --title "ログイン画面" \
  --description "ログイン画面を追加" \
  --targets repositoryName=MyDemoRepo,sourceReference=feature/login,destinationReference=main

put-file の --file-content は、ファイルの中身を fileb://（バイナリとして読む）で渡すのが確実です。2回目以降のコミットでは --parent-commit-id に今のブランチの先頭のコミットを渡し、違うと競合として断られます。1回で複数のファイルを入れたいときは create-commit を使います（1コミット100ファイルまで）。

プルリクエストと承認ルール

CodeCommit のプルリクエストには「承認ルール」を付けられます。たとえば「main への変更は2人の承認が要る」を、リポジトリごと、またはテンプレート（承認ルールテンプレート）として複数のリポジトリに当てはめられます。上限は、1つのプルリクエストに承認ルール30個（うちテンプレートからは25個）、1リージョンにテンプレート1,000個です。マージの方法は、早送り（fast-forward）・スカッシュ・3-way の3種類が API にあります。

CodeCommitへの接続方法3つ（HTTPSのGit認証情報・git-remote-codecommit・SSH）

この節では、CodeCommit に git でつなぐ3つの方法の違いと、どれを選べばよいかが分かります。

IAM ユーザーで使うなら HTTPS の Git 認証情報、SSO（IAM Identity Center）・フェデレーション・一時的な認証情報なら git-remote-codecommit を選びます。 公式のユーザーガイドが示す URL の形は次のとおりです。

HTTPSのGit認証情報（いちばん手軽）

使う本人が IAM コンソールにサインインし、ユーザーの「セキュリティ認証情報」から CodeCommit 用の HTTPS Git 認証情報（ユーザー名とパスワード）を作ります。パスワードを保存できるのは作ったときの1回だけです。 写し忘れたらパスワードをリセットして作り直します。clone のときに聞かれたユーザー名とパスワードを入れれば、OS の資格情報ストアや IDE が覚えます。以前に認証情報ヘルパーを設定した PC では、.gitconfig からヘルパーの行を消してから使う、と公式は書いています。

git-remote-codecommit（SSO・一時的な認証情報向け）

Git のリモートヘルパーで、AWS CLI のプロファイルの認証情報を使って HTTPS で接続します。Git 用の別のパスワードを作らなくてよいのが利点で、公式は HTTPS で接続するときの推奨の方法としています。ルート・フェデレーション・一時的な認証情報で使うには AWS CLI v2 が要ります。

pip install git-remote-codecommit

git clone codecommit://MyDemoRepo my-demo-repo                        # 既定のプロファイル
git clone codecommit://CodeCommitProfile@MyDemoRepo my-demo-repo      # プロファイルを指定
git clone codecommit::ap-northeast-1://MyDemoRepo my-demo-repo        # リージョンを指定

SSH鍵で接続する

Linux・macOS では ssh-keygen で鍵を作り、公開鍵を IAM の「SSH パブリックキーのアップロード」で登録します。登録後に表示される SSH キー ID（APKA で始まる値）が SSH のユーザー名になる点が GitHub と違うところで、~/.ssh/config に次のように書きます。

Host git-codecommit.*.amazonaws.com
  User APKAEIBAERJR2EXAMPLE
  IdentityFile ~/.ssh/codecommit_rsa

このファイルは chmod 600 にし、ssh git-codecommit.ap-northeast-1.amazonaws.com で接続を試します。初回はホストの確認を求められるので、ユーザーガイドの「Server fingerprints」の値と照らします。この環境には ssh クライアントが無く、SSH での接続は公式ドキュメントの範囲で書いています。GitHub の SSH 鍵の作り方と比べたいときは、関連記事「SSH鍵の作成とGitHub接続｜Permission deniedの対処法」が参考になります。

認証情報ヘルパー（credential-helper）の仕組みとUseHttpPath

この節では、aws cli の認証情報ヘルパーが何を作っているのかと、UseHttpPath を忘れたときに何が起きるかが分かります。

認証情報ヘルパーは、Git がパスワードを求めたときに、AWS の鍵から「その時刻だけ使える署名」を作って渡す仕組みです。 作るのは手元の計算だけで、AWS へは通信しません。そこで、作業場所の設定ファイルに公式の設定を書き、ダミーの鍵で git credential fill を実行しました。

git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true

printf 'url=https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MyDemoRepo\n\n' \
  | git credential fill

protocol=https
host=git-codecommit.ap-northeast-1.amazonaws.com
path=v1/repos/MyDemoRepo
username=testing
password=20261030T143152Zac0bd3e098537b74bf36f6552d1970f80b507652ab8a982906e8c17fb5d2ba8f

ユーザー名はアクセスキーID（ここではダミーの testing）、パスワードは「時刻＋署名」です。時刻をずらして実行すると、パスワードの値はまったく別のものになりました。時刻が入った使い捨ての値なので、OS のキーチェーンに覚えさせると、しばらくして期限が切れ、403 になります。 macOS の 403 の原因として公式が挙げる「osxkeychain が一時的な値を覚え、約15分で期限が切れる」はこの仕組みによるものです。

UseHttpPathを忘れたとき

次に credential.UseHttpPath の行だけ消して、同じことを実行しました。

'path'
fatal: could not read Username for 'https://git-codecommit.ap-northeast-1.amazonaws.com': terminal prompts disabled

ヘルパーが署名に使うリポジトリのパスを受け取れず、'path' という短いエラーを出して何も返しませんでした。Git はユーザー名を聞きに行き、ここでは入力を止めていたので終わっています。ふだんの端末なら「Username for ...」と聞かれるので、「ヘルパーを設定したのにユーザー名を聞かれる」ときは、まず UseHttpPath を確かめます。

ホストごとに分けた設定の例は、公式のトラブルシューティングにある形です。

[credential "https://git-codecommit.ap-northeast-1.amazonaws.com"]
    helper = !aws --profile CodeCommitProfile codecommit credential-helper $@
    UseHttpPath = true
[credential "https://github.com"]
    helper = osxkeychain

手元の設定を git config -l --show-origin で見ると、どのファイルのどの行が効いているかが分かります。

file:/srv/s4/r17/t143/home/gitconfig	credential.helper=!aws codecommit credential-helper $@
file:/srv/s4/r17/t143/home/gitconfig	credential.usehttppath=true

CodeCommitとGitHub・GitLab・Bitbucketの比較

この節では、CodeCommit と主な Git のサービスの違いと、どんなときに CodeCommit が向くかが分かります。

CodeCommit は「AWS の中でコードを持ち、IAM で権限を決めたい」ときに向き、課題管理や CI まで1か所にまとめたいときは GitHub・GitLab・Bitbucket が向きます。 料金や機能の細部は変わるので、ここでは仕組みの違いだけを比べます（各社の料金は公式ページで確かめます）。

CodeCommitが向く場面・向かない場面

GitHub Actions で CI/CD を組む流れは、関連記事「CI/CDとは｜GitHub Actionsで最初のパイプラインを作るまで」で扱っています。

CodeCommitからGitHubへ移行する手順（git clone --mirrorの実物）

この節では、CodeCommit のリポジトリを GitHub などへ、ブランチ・タグ・履歴を欠かさず移す手順と、実際の出力が分かります。

移し方の基本は「git clone --mirror で全部の参照を取り、空の移行先へ git push --mirror する」です。 2024年7月25日の公式ブログもこの方法を示しています。ここでは CodeCommit の代わりにローカルのベアリポジトリを置き、ブランチ3本（main・feature/login・hotfix）、注釈付きタグ v1.0、Git のノート（refs/notes/commits）を入れて試しました。

ふつうのcloneとmirrorの違い（実行結果）

== ふつうの clone ==
92f1f8beca4e7455b05a5872e0b3e84f19626878 refs/heads/main
92f1f8beca4e7455b05a5872e0b3e84f19626878 refs/remotes/origin/HEAD
db2351f2a915c5b412f4edf88cc6ad4c6e8ca41a refs/remotes/origin/feature/login
db2723803c58e9aa8b1c37c68c026e5c59b54e71 refs/remotes/origin/hotfix
92f1f8beca4e7455b05a5872e0b3e84f19626878 refs/remotes/origin/main
4588702c30819fe6c2de6d4ef1e7a1ad362686de refs/tags/v1.0

== git clone --mirror ==
Cloning into bare repository 'my-demo-repo.git'...
done.
db2351f2a915c5b412f4edf88cc6ad4c6e8ca41a refs/heads/feature/login
db2723803c58e9aa8b1c37c68c026e5c59b54e71 refs/heads/hotfix
92f1f8beca4e7455b05a5872e0b3e84f19626878 refs/heads/main
ee7e261d8ae4a12760308334d48628b90e48add7 refs/notes/commits
4588702c30819fe6c2de6d4ef1e7a1ad362686de refs/tags/v1.0

ふつうの clone では、手元のブランチは main だけで、ほかは refs/remotes/origin/ の下の「追跡用」になり、ノート（refs/notes/commits）は取れていませんでした。 mirror ではリモートと同じ5つの参照がそのまま並び、設定には remote.origin.mirror=true が入りました。

push --mirrorの出力と突き合わせ

$ cd my-demo-repo.git
$ git remote add github ../dst/new-repo.git
$ git push github --mirror
To ../dst/new-repo.git
 * [new branch]      feature/login -> feature/login
 * [new branch]      hotfix -> hotfix
 * [new branch]      main -> main
 * [new reference]   refs/notes/commits -> refs/notes/commits
 * [new tag]         v1.0 -> v1.0

$ diff <(git -C src/MyDemoRepo.git show-ref) <(git -C dst/new-repo.git show-ref) && echo "refs identical"
refs identical

移行元と移行先の参照は、コミットの ID まで一致しました。git fsck も問題なく終わっています。比べるために、ふつうの clone から git push --all と --tags で送った場合は、移行先にあったのは main と v1.0 の2つだけでした。

Gitの履歴以外は移らない

公式ブログは、この方法で移るのは Git のリポジトリのデータで、プルリクエストなど CodeCommit の他のデータの書き出しは扱わない、と明記しています。議論を残したいなら、get-comments-for-pull-request などで JSON として保存しておきます。GitHub・GitLab・Bitbucket Cloud には各社のインポート機能もあり、公式ブログは、そのときは CodeCommit の HTTPS の Git 認証情報（固定のユーザー名とパスワード）を使うと案内しています。

GitHub へ移すときは、GitHub Docs にある「100 MiB を超えるファイルは拒否する」に当たらないかを先に確かめます。CodeCommit は blob 1つ 2 GB まで受け付けるため、CodeCommit では置けていたファイルが GitHub への push で止まることがあります。リモートの付け替えの細かな操作は、先に挙げた git remote の記事で扱っています。

移行・運用でやってはいけないこと

この節では、移行や日々の運用で取り返しのつかない結果になりやすい操作と、その代わりにする方法が分かります。

git push --mirror は「移行先を移行元と同じにする」操作で、移行先にしか無い参照は消し、食い違うブランチは強制的に上書きします。 移行先に README を付けて作ったうえ、別のブランチ（gh-pages）も置いた状態で mirror push すると、次のようになりました。

To ../dst/nonempty.git
 - [deleted]         gh-pages
 + 77f680e...92f1f8b main -> main (forced update)
 * [new branch]      feature/login -> feature/login
 * [new branch]      hotfix -> hotfix
 * [new reference]   refs/notes/commits -> refs/notes/commits
 * [new reference]   github/feature/login -> github/feature/login
 * [new reference]   github/hotfix -> github/hotfix
 * [new reference]   github/main -> github/main
 * [new tag]         v1.0 -> v1.0

移行先の gh-pages は消え、main の README のコミットは上書きされました。さらに、1回目の push のために git remote add github した mirror のリポジトリから2回目の mirror push をしたため、追跡用の参照（github/main など）までブランチとして送られ、移行先に remotes/github/... という余分な参照ができました。

• 1移行先は空で作るREADME・ライセンス・.gitignore を付けない。付けたら mirror push で上書きされる
• 2mirror push は1回で終えるやり直すときは mirror の clone から作り直すか、URL を直接指定して push する
• 3CodeCommit のリポジトリは最後に消す削除は元に戻せない。CI/CD の切り替えと、参照の突き合わせが済んでから
• 4プルリクエストの記録を先に書き出すGit の push では移らない。監査で要るなら JSON で残す
• 5アクセスキーを URL やスクリプトに書かないGit 認証情報もアクセスキーも、リポジトリにコミットしない

IAM で push を止めるには、codecommit:GitPush を拒否するポリシーを使います。ポリシーの書き方は、関連記事「AWS AccessDeniedの原因と対処｜エラー文別の切り分け表」でも拒否のされ方とあわせて扱っています。

CodeCommitのよくあるエラーと直し方

この節では、CodeCommit を使っていて出やすいエラーの原文と、原因・直し方が分かります。

CodeCommit のエラーの多くは「リージョン違い」「権限不足」「認証情報の取り違え」の3つです。 手元で出したものと、公式のトラブルシューティングに載っているものを分けて示します。

SSH でつながらないときは、ssh -v の詳しい出力で、どの鍵・どのユーザー名を使ったかを見るのが近道です。

判断表：CodeCommitを続ける・移る・新しく使う

この節では、2026年10月29日時点の扱いを踏まえて、CodeCommit をどうするかを決める目安が分かります。

再開したので「急いで移る」理由は無くなりました。決め手は、AWS の中で閉じる利点と、課題管理・CI・LFS などの機能のどちらが大きいかです。

よくある質問

Q. AWS CodeCommitとは何ですか？ A. AWS が運用する、プライベートな Git リポジトリのサービスです。ふつうの Git のコマンドで使え、誰が読めるか・書けるかを IAM で決めます。CodePipeline・CodeBuild と組み合わせてビルドやデプロイを自動にできます。

Q. CodeCommitは廃止されたのですか？ A. 廃止されていません。2024年7月25日に新規のお客様への提供を止めましたが、2025年11月24日に一般提供へ戻り、新規の受け付けも再開しました（2026年10月29日時点）。既存の利用者は停止中も使い続けられました。

Q. 今から新しくCodeCommitを使えますか？ A. 使えます。ユーザーガイドの履歴に、2025年11月25日付けで「AWS CodeCommit is now available to new customers.」と記載されています。日本語の料金ページには停止の告知が残っていたため、英語のユーザーガイドで確かめるのが確実です。

Q. CodeCommitの料金はいくらですか？ A. 無料枠は期限なしで使えます。公式の例では、ある月のアクティブユーザーが6人なら、ほかに料金が無ければ 1 USD です。超過分はストレージが 0.06 USD／GB・月、Git リクエストが 0.001 USD／回です（2026年10月29日時点）。CodeBuild などのロールもユーザーとして数えます。

Q. CodeCommitからGitHubへ移すには？ A. GitHub に空のリポジトリを作り、git clone --mirror で CodeCommit から取り、git push --mirror で送ります。手元の実験ではブランチ・タグ・ノートの5つの参照が ID まで一致しました。プルリクエストやコメントは移らないので、必要なら CLI で JSON に書き出します。

Q. 認証情報ヘルパーを設定したのにユーザー名を聞かれます。 A. credential.UseHttpPath true が無いか、別のヘルパー（osxkeychain・Git Credential Manager）が先に答えている可能性があります。git config -l --show-origin | grep credential でどの設定が効いているかを見て、ホストごとにヘルパーを分けます。

Q. 手元でCodeCommitの操作を試す方法はありますか？ A. moto のサーバーモードを 127.0.0.1 で起動し、aws cli の --endpoint-url をそこへ向ける方法があります。ただし moto 5.2.5 の CodeCommit はリポジトリの作成・取得・削除だけで、ブランチやファイルの操作は未対応でした。名前の検査も本物より緩いので、最後は本物の AWS で確かめます。

Q. CodeCommitでGit LFSは使えますか？ A. 2025年11月24日の公式ブログで、Git LFS は2026年第1四半期の予定と公表されました。2026年10月29日時点のユーザーガイドの履歴には対応の記載が見当たらなかったため、使う前に最新の履歴と What's New で確かめます。

まとめ

• AWS CodeCommit は AWS が運用するプライベートな Git リポジトリで、権限は IAM で決める。課題管理と組み込みの CI は無く、CodeBuild・CodePipeline と組み合わせる。
• 2024年7月25日に新規受付を止めたが、2025年11月24日に一般提供へ戻り、新規受付を再開した（2026年10月29日時点）。日本語の料金ページには停止の告知が残っていた。
• 接続は、IAM ユーザーなら HTTPS の Git 認証情報、SSO・一時的な認証情報なら git-remote-codecommit。認証情報ヘルパーは時刻入りの署名を作るので、UseHttpPath を忘れると「'path'」で失敗し、キーチェーンに覚えさせると期限切れで 403 になる。
• GitHub などへは git clone --mirror と git push --mirror で移す。手元の実験では参照5つが一致し、push --all では2つしか移らなかった。プルリクエストは移らない。
• mirror push は移行先を上書き・削除する。移行先は空で作り、1回で終え、CodeCommit の削除は最後に行う。

参考・出典

確認日はいずれも 2026年10月29日です。

• AWS DevOps & Developer Productivity Blog「AWS CodeCommit Returns to General Availability」（2025年11月24日）：https://aws.amazon.com/blogs/devops/aws-codecommit-returns-to-general-availability/
• AWS DevOps & Developer Productivity Blog「How to migrate your AWS CodeCommit repository to another Git provider」（2024年7月25日、2025年11月24日に更新の注記）：https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/
• AWS CodeCommit User Guide「Document history」：https://docs.aws.amazon.com/codecommit/latest/userguide/history.html
• AWS CodeCommit「Pricing」：https://aws.amazon.com/codecommit/pricing/
• AWS CodeCommit 料金（日本語）：https://aws.amazon.com/jp/codecommit/pricing/
• AWS CodeCommit User Guide「Quotas in AWS CodeCommit」：https://docs.aws.amazon.com/codecommit/latest/userguide/limits.html
• AWS CodeCommit User Guide「Connect to an AWS CodeCommit repository」：https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html
• AWS CodeCommit User Guide「Setup for HTTPS users using Git credentials」：https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html
• AWS CodeCommit User Guide「Setup steps for HTTPS connections to AWS CodeCommit with git-remote-codecommit」：https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html
• AWS CodeCommit User Guide「Setup steps for SSH connections to AWS CodeCommit repositories on Linux, macOS, or Unix」：https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-unixes.html
• AWS CodeCommit User Guide「Troubleshooting the credential helper and HTTPS connections to AWS CodeCommit」：https://docs.aws.amazon.com/codecommit/latest/userguide/troubleshooting-ch.html
• AWS re:Post「Why am I unable to create a repository in CodeCommit?」：https://repost.aws/selections/KPRqbk9RhNRi29VlzbJNnH5g/why-am-i-unable-to-create-a-repository-in-codecommit
• AWS CLI Command Reference「codecommit」：https://docs.aws.amazon.com/cli/latest/reference/codecommit/
• GitHub Docs「About large files on GitHub」：https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github
• moto（AWS のサービスをまねるライブラリ）：https://docs.getmoto.org/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。