AWS CodeBuild

解決する課題

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

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

主要概念と用語

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

仕様・制限・クォータ

• ビルドごとに隔離した管理対象環境を用意し、終了後に破棄する。ソースは AWS リポジトリ、S3、CodeConnections で接続した外部 Git などから取得できる
• EC2 オンデマンド、起動の速い Lambda コンピュート、構成を予約する EC2 フリートがあり、OS・CPU・GPU・ネットワーク要件で選ぶ
• EC2 コンピュートのビルドタイムアウトは 5〜2,160 分（36時間）。プロジェクトの既定クォータは 1 リージョン 5,000 件で、同時実行数はコンピュート種別ごとに異なる
• Lambda コンピュートは x86/Arm の 1・2・4・8・10 GB と 10 GB の一時ディスクを提供する。実行は最大 15 分で、独自タイムアウト、キャッシュ、VPC 接続、Docker 実行などには対応しない

内部の仕組み

横にスクロール

ビルドが開始されると、CodeBuild は選択したコンピュートと環境イメージから隔離した実行環境を用意し、ソースを取得して buildspec のフェーズを順に実行します。ビルドが終わると一時環境は破棄されます。

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

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

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

運用・監視

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

コスト

EC2 オンデマンドは投入から終了までを分単位で切り上げ、Lambda コンピュートは秒単位で切り上げます。予約 EC2 フリートはインスタンス確保中に分単位で課金され、最低 60 分、Mac は最低 24 時間の料金がかかります。選んだ方式により「ビルドしていない間は無料」とは限りません。

• 大きいコンピュートタイプは速いが単価が高い。ビルドが 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}"