AWS CodeCommit
AWS が提供していたフルマネージド Git リポジトリサービスで、IAM による認証・認可と保存時の自動暗号化を備えていたが、2024 年 7 月に新規利用が停止された
概要
AWS CodeCommit は、Git リポジトリをフルマネージドで提供するソースコード管理サービスでした。IAM ユーザーやロールによるアクセス制御、AWS KMS による保存データの自動暗号化、CodePipeline との緊密な連携が特徴で、AWS エコシステム内で完結する CI/CD パイプラインを構築できました。2024 年 7 月 25 日に新規顧客の受け入れが停止され、既存ユーザーも他のサービスへの移行が推奨されています。
IAM 統合認証がもたらした AWS ネイティブなソースコード管理
CodeCommit の最大の差別化要因は、Git リポジトリの認証・認可を IAM で一元管理できる点にありました。GitHub や GitLab では SSH 鍵や個人アクセストークンをユーザーごとに管理する必要がありますが、CodeCommit では IAM ポリシーでリポジトリ単位・ブランチ単位のアクセス制御を宣言的に定義できました。たとえば「main ブランチへのプッシュはリリースマネージャーロールのみ許可」といった制御を、IAM ポリシーの Condition 句で実現できます。認証方式は HTTPS (Git 認証情報ヘルパー経由) と SSH の両方をサポートし、AWS CLI の credential helper を使えば IAM の一時認証情報で透過的に Git 操作が可能でした。保存データは AWS KMS のカスタマーマネージドキーまたは AWS マネージドキーで自動暗号化され、通信は TLS で保護されます。金融機関や政府機関など、ソースコードの保管場所に厳格な要件がある組織にとって、AWS リージョン内にリポジトリが閉じている点は大きな利点でした。
CodePipeline 連携と CI/CD パイプラインの構築パターン
CodeCommit は CodePipeline のソースステージとしてネイティブに統合されており、リポジトリへのプッシュをトリガーに CodeBuild でのビルド・テスト、CodeDeploy でのデプロイを自動実行する CI/CD パイプラインを構築できました。EventBridge ルールを介してプッシュイベントを検知するため、ポーリングによる遅延がなくリアルタイムにパイプラインが起動します。プルリクエスト機能も備えており、承認ルールテンプレートで「最低 2 名のレビュー承認が必要」といったマージ条件を強制できました。ただし、GitHub や GitLab と比較するとプルリクエストの UI や機能は限定的で、コードレビューのワークフローとしては物足りない面がありました。Azure DevOps の Azure Repos も同様にクラウドネイティブな Git リポジトリを提供していますが、Azure Repos は 2026 年時点でも新規利用が可能であり、Azure Pipelines との統合も継続しています。Git の関連書籍 (Amazon) で基礎を固めておくと、どのホスティングサービスでも応用が利きます。
サービス終了と移行先の選定 - 既存ユーザーが取るべきアクション
2024 年 7 月 25 日、AWS は CodeCommit の新規アカウントへの提供を停止しました。既存ユーザーは引き続き利用可能ですが、新機能の追加は行われず、段階的な縮小が見込まれます。AWS 自身が公式ブログで推奨する移行先は、GitHub、GitLab、Bitbucket などのサードパーティ Git ホスティングサービスです。移行にあたっては、まず IAM ベースのアクセス制御を移行先の認証モデル (GitHub の Organization 権限、GitLab のグループ権限など) に再設計する必要があります。CodePipeline は GitHub や Bitbucket をソースプロバイダーとしてサポートしているため、パイプラインの再構築は比較的容易です。ただし、CodeCommit のトリガーで EventBridge ルールを使っていた場合は、GitHub Webhooks や GitLab Webhooks への置き換えが必要になります。移行手順としては、git clone --mirror でリポジトリの完全なコピーを取得し、移行先に git push --mirror で反映するのが最もシンプルです。ブランチ保護ルールや承認テンプレートは手動で再設定する必要があるため、移行前に現行の設定を棚卸ししておくことが重要です。