AWS CodeBuild

解決する課題

従来は CI のためにビルド用サーバー（Jenkins など）を常時起動し、OS やビルドツールのパッチ・スケール・キャパシティ管理を自分で抱える必要がありました。CodeBuild なら：

• ビルドのたびに環境を起動し、終わると破棄するためサーバーの常時管理が不要
• 複数のビルドを並列実行でき、待ち行列が発生しにくい
• ビルドツールの入ったマネージド環境が提供され、自前のパッチ適用が要らない

主要概念と用語

• ビルドプロジェクト: ソースの場所・ビルド環境・buildspec などの設定をまとめた単位
• buildspec: ビルド手順を記述する YAML ファイル（既定では buildspec.yml）。install/pre_build/build/post_build などのフェーズを定義する
• ビルド環境: ビルドを実行するコンテナ。AWS 提供のマネージドイメージか、独自のコンテナイメージを指定できる
• アーティファクト: ビルドの成果物。S3 などに保存する
• コンピュートタイプ: ビルドに割り当てる CPU・メモリのサイズ区分
• 環境変数: ビルド中に参照する値。機密値は Secrets Manager や SSM パラメータストアから参照する

仕様・制限・クォータ

• ビルドはコンテナ単位で隔離して実行され、ビルドごとにクリーンな環境が用意される
• ソースは CodeCommit・GitHub・GitHub Enterprise・Bitbucket・S3 などから取得できる
• 1 つのビルドには**最大実行時間（タイムアウト）**があり、超過すると打ち切られる
• 同時に実行できるビルド数（並列数）にはアカウント単位の上限があり、引き上げ申請が可能
• Linux・Windows 環境に対応し、ARM ベースの環境も選択できる

具体的な並列数・タイムアウト上限・対応ランタイムの値はリージョンや時期で変わるため、最新値は公式ドキュメントで確認してください。

内部の仕組み

ビルドが開始されると、CodeBuild は指定したビルド環境イメージから一時的なコンテナを起動し、ソースを取得して buildspec のフェーズを順に実行します。ビルドが終わるとコンテナは破棄されます。

• フェーズは install → pre_build → build → post_build の順に進む
• ビルドの標準出力やエラーは CloudWatch Logs にストリーミングされる
• 成果物は artifacts セクションの指定に従って S3 などへアップロードされる
• 依存パッケージはローカルキャッシュや S3 キャッシュで再利用でき、2 回目以降を高速化できる

設計パターン / ベストプラクティス

• buildspec をリポジトリに置く: ビルド定義をコードと一緒にバージョン管理し、再現性を確保する
• CodePipeline のステージとして組み込む: ソース取得・ビルド・テスト・デプロイを一連のパイプラインにする
• マルチステージ: テスト用とリリース用でプロジェクトや環境変数を分け、用途ごとに最適化する
• 最小権限のサービスロール: ビルドが触れる S3 バケットや ECR リポジトリだけに権限を絞る

運用・監視

• CloudWatch Logs でビルドログを確認し、失敗フェーズを切り分ける
• CloudWatch メトリクスでビルドの成功・失敗数や所要時間を監視する
• EventBridge でビルド状態の変化（成功・失敗）を捕捉し、通知や後続処理を自動化する
• 失敗の再現には、同じ環境イメージをローカルで実行できる仕組みを活用すると切り分けが速い

コスト

課金は主に**ビルドにかかった時間（分）**に対して発生し、選んだコンピュートタイプ（CPU・メモリの大きさ）が大きいほど単価が上がります。常時起動するサーバーと違い、ビルドしていない間は費用がかかりません。

• 大きいコンピュートタイプは速いが単価が高い。ビルドが CPU・メモリで律速していないなら小さい方が割安
• キャッシュ活用でビルド時間そのものを減らすのが最も効くコスト最適化
• 不要に長いタイムアウト待ちや、失敗ビルドの放置を避ける

正確な単価は時期・リージョンで変動するため、断定的な金額は公式の料金ページで確認してください。

セキュリティ

• **サービスロール（IAM ロール）**でビルドに権限を与え、アクセスキーのハードコードを避ける
• 機密値は Secrets Manager や SSM パラメータストアから参照し、平文の環境変数に置かない
• 成果物の保存先である S3 やログは KMS で暗号化できる
• プライベートリソースにアクセスするビルドは VPC 内で実行する設定が可能

Well-Architected の観点

• 運用上の優秀性: ビルドをコード（buildspec）として管理し、CI を自動化・標準化することで手作業とばらつきを減らせる
• ビルド状態を EventBridge と CloudWatch で観測し、失敗を素早く検知・通知できる

試験で問われるポイント

関連サービス・比較

デプロイを担う CodeDeploy とよく一緒に登場します。役割の違いを押さえておきましょう。

ハンズオン / CLI例

# ビルドプロジェクトの一覧を取得
aws codebuild list-projects

# 指定プロジェクトのビルドを開始
aws codebuild start-build --project-name my-app-build

# 直近ビルドの ID を取得し、状態を確認
aws codebuild list-builds-for-project --project-name my-app-build --query "ids[0]"
aws codebuild batch-get-builds --ids my-app-build:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --query "builds[].{Status:buildStatus,Phase:currentPhase}"