AWS Code シリーズと Amazon CodeCatalyst を比較してみた
去る2024年7月末、AWS CodeCommit の新規顧客への提供終了が大きな話題となりました。
私も現在参画している案件で CodeCommit を含む CI/CD パイプラインを運用しているため、大きな衝撃を受けました。
既存ユーザーは今後もサービスを継続利用できるものの、長期的な開発・運用を見据えると CodeCommit、ひいては AWS Code シリーズ全体から他開発サービスへの移行の検討の余地があるかもしれません。
そこで本記事では、移行先サービスの候補の一つとなる Amazon CodeCatalyst と AWS Code シリーズを比較し、それぞれのサービスが持つ強みや弱みを整理します。
また、Code シリーズから CodeCatalyst への移行性を評価する際のポイントとなるサービスの特徴の列挙も行います。
目次
はじめに
こんにちは。クラウドソリューション第一グループの namiki.t です。
この記事は アイソルート Advent Calendar 2024 1日目の記事です。
Amazon CodeCatalyst は、AWS re:Invent 2022 で発表・2023年4月に GA された統合開発サービスです。
AWS Code シリーズがそれぞれの機能に特化したサービスであるのに対し、CodeCatalyst は開発ライフサイクル全体を一貫してサポートし、シンプルに統合されています。
CodeCatalyst はまだ新しいサービスですが、継続的に機能追加・アップデートが行われているため、今後さらに便利なサービスになっていくことが期待できます。
次章で具体的に Code シリーズと CodeCatalyst を比較し、それぞれのサービスにどの程度の機能差異があるのかを明らかにします。
機能比較
一般的な開発に要求される下記の要件を満たす機能を具備しているか、という観点で機能比較を行います。
- 国内リージョンサポート：サービスが日本国内のリージョンで利用できる
- MFA 認証：MFA による認証を設定できる
- リソース保護：非管理者ユーザーによるプロジェクトリソースの変更・削除操作を禁止できる
- ブランチ保護：リリース用ブランチ (例：
master,staging) に対する [更新・削除の禁止] と、[一部ユーザーによるマージの禁止] ができる - Issue 管理：Issue が作成でき、プルリクエストと紐づけることができる
- CI/CD パイプライン：リリース用ブランチの変更を契機にビルド・デプロイを実行できる
- イベント通知：CI/CD パイプラインの開始・成功・失敗を EMAIL または Slack で通知できる
結果は以下の通りです。
| 要件 | Code シリーズ | CodeCatalyst |
|---|---|---|
| 国内リージョンサポート | O すべてのサービスが東京リージョンで利用可能 |
X CodeCatalyst サービスは 2024年12月現在日本国内リージョンでは利用不可 ※ただし、アプリケーションを国内リージョンにデプロイすることは可能 |
| MFA 認証 | O IAM ポリシー設定により実現可能 |
O AWS Builder ID に MFA 認証を設定可能 |
| リソース保護 | O IAM ポリシー設定により実現可能 |
O 既定のロールをユーザーにアタッチすることで実現可能 |
| ブランチ保護 | O IAM ポリシー設定により実現可能 |
O ロールとブランチルールの設定により実現可能 |
| Issue 管理 | X Issue を作成する機能が具備されていない |
O Issue を作成し、プルリクエストと紐づけることが可能 |
| CI/CD パイプライン | O EventBridge イベントパターンを使用して、 特定のブランチの変更イベントを契機に CodePipeline の起動が可能 |
O ワークフローを使用して、特定ブランチの変更を契機に CI/CD の一連のアクションを実行可能 |
| イベント通知 | O Code シリーズのサービスで発生したイベントを契機に Amazon SNS でサポートされているエンドポイントに通知配信可能 |
O ワークフローで発生したイベントを契機に Slack チャンネルに通知配信可能 |
移行性
Code シリーズから CodeCatalyst への移行性を評価する際にポイントとなる CodeCatalyst の特徴を列挙します。
O：開発ライフサイクル全体をカバーしている
記事冒頭でも触れていますが、CodeCatalyst は開発ライフサイクル全体が一つのサービスとしてシンプルに統合・提供されています。
そのため、Code シリーズから移行することで [サービス間の連携の複雑さ] や [マルチツール運用の負荷] 、 [チーム間のコラボレーション不足] など、いくつかの課題が解消できる可能性があります。
O：ブループリントが多数提供されている
CodeCatalyst では、数ステップで開発環境を構築するためのブループリントが多数提供されています。
Code シリーズで構築にコストがかかっていた開発ワークフローでも、ブループリントでカバーされていれば低コストで CodeCatalyst に移行できる可能性があります。
参考：Amazon CodeCatalyst Blueprints
O：Issue 管理機能が提供されている
機能比較の節でも触れていますが、CodeCatalyst にはプルリクエストとの紐づけが可能な Issue 管理機能が提供されています。
Code シリーズにはこれに相当する機能が提供されていないため、外部ツールなどを利用して運用でカバーする必要があります。
参考：Track and organize work with issues in CodeCatalyst
X：ユーザー権限管理に IAM を使用できない
CodeCatalyst のユーザー権限制御は、既定のロールを使用して行います。
Code シリーズで細かなユーザー権限制御を行っている場合、それが CodeCatalyst 既定のロールではカバーできない可能性があります。
参考：Viewing the permissions available for each role
X：ビルド時に使用できるランタイムに差異がある
CodeBuild、CodeCatalyst の両サービスでビルド実行時に使用できるランタイムやマネージド型イメージに差異があります。
※執筆時点の極端な例を挙げると、Node.js v20 は CodeBuild ではサポートされ、CodeCatalyst ではサポートされていません
厳密なランタイムの制約がある場合は、移行性評価時に注意が必要です。
参考 (CodeBuild)：Available runtimes
参考 (CodeCatalyst)：Specifying runtime environment images
X：VPC 接続可能なリージョンが限られている
CodeCatalyst は 2023年11月に VPC のサポートを開始し、パブリックルートを介さずにワークフローから VPC のリソースにアクセスできるようになりましたが、これは CodeCatalyst をサポートしているリージョン (2024年12月現在、オレゴン / アイルランドリージョンのみサポート) に限定されています。
したがって、VPC に関するネットワークの制約があるケースにおいては移行が難しいと考えられます。
参考：Amazon CodeCatalyst、Virtual Private Cloud のサポートを開始
終わりに
今回は、AWS の開発サービスである Code シリーズと Amazon CodeCatalyst の比較と、移行性評価時のポイントとなる Codectalyst サービスの特徴の整理を行いました。
両者の違いが気になっている方や移行を検討している方にとって、少しでも参考になっていれば幸いです。
執筆時点ではまだ叶っていませんが、東京を含むマルチリージョンで利用可能になれば今後ますます導入しやすくなると思いますので、今後のアップデートに期待しましょう！
明日は kugishimak さんの「【AWS】Amazon Bedrock ～概要編～」です、お楽しみに！
