AWS CodeBuild 完全活用 Vol2 buildspec VPC マルチアーキ コスト最適化

# ツールバージョン一括確認aws --version # aws-cli/2.x.x Python/3.x.x ...terraform -version  # Terraform v1.9.xdocker buildx version  # github.com/docker/buildx v0.12.x ...jq --version  # jq-1.6

resource "aws_vpc" "codebuild" {  cidr_block  = "10.0.0.0/16"  enable_dns_support= true  enable_dns_hostnames = true  tags = { Name = "codebuild-vpc" }}resource "aws_subnet" "private_a" {  vpc_id= aws_vpc.codebuild.id  cidr_block  = "10.0.1.0/24"  availability_zone = "ap-northeast-1a"  tags = { Name = "codebuild-private-a" }}resource "aws_subnet" "private_c" {  vpc_id= aws_vpc.codebuild.id  cidr_block  = "10.0.2.0/24"  availability_zone = "ap-northeast-1c"  tags = { Name = "codebuild-private-c" }}resource "aws_internet_gateway" "this" { vpc_id = aws_vpc.codebuild.id }resource "aws_eip" "nat" { domain = "vpc" }resource "aws_nat_gateway" "this" {  allocation_id = aws_eip.nat.id  subnet_id  = aws_subnet.public.id  depends_on = [aws_internet_gateway.this]}resource "aws_route_table" "private" {  vpc_id = aws_vpc.codebuild.id  route { cidr_block = "0.0.0.0/0"; nat_gateway_id = aws_nat_gateway.this.id }}resource "aws_security_group" "codebuild" {  name= "codebuild-sg"  vpc_id = aws_vpc.codebuild.id  egress { from_port = 443; to_port = 443; protocol = "tcp"; cidr_blocks = ["0.0.0.0/0"] }  egress { from_port = 80;  to_port = 80;  protocol = "tcp"; cidr_blocks = ["0.0.0.0/0"] }}

data "aws_caller_identity" "current" {}resource "aws_ecr_repository" "app" {  name  = "my-app"  image_tag_mutability = "MUTABLE"  image_scanning_configuration { scan_on_push = true }}resource "aws_s3_bucket" "artifacts" {  bucket = "codebuild-artifacts-${data.aws_caller_identity.current.account_id}"}resource "aws_secretsmanager_secret" "db_password" { name = "/codebuild/db-password" }resource "aws_secretsmanager_secret_version" "db_password" {  secret_id  = aws_secretsmanager_secret.db_password.id  secret_string = jsonencode({ password = "changeme-in-production" })}

resource "aws_iam_role" "codebuild" {  name = "codebuild-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole", Effect = "Allow",Principal = { Service = "codebuild.amazonaws.com" } }]  })}resource "aws_iam_role_policy_attachment" "codebuild_ecr" {  role = aws_iam_role.codebuild.name  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser"}resource "aws_iam_role_policy" "codebuild_custom" {  role = aws_iam_role.codebuild.name  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Action = [  "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents",  "s3:GetObject", "s3:PutObject", "s3:GetBucketAcl", "s3:GetBucketLocation",  "secretsmanager:GetSecretValue",  "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces",  "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets",  "ec2:DescribeSecurityGroups", "ec2:DescribeVpcs",  "ec2:CreateNetworkInterfacePermission"]Resource = "*" }]  })}

# VPC と private subnet の利用可能 IP を確認aws ec2 describe-subnets--filters "Name=tag:Name,Values=codebuild-private-*"--query 'Subnets[*].{Name:Tags[?Key==`Name`]|[0].Value,AvailableIPs:AvailableIpAddressCount}'# ECR リポジトリ確認aws ecr describe-repositories--repository-names my-app--query 'repositories[0].{uri:repositoryUri,mutable:imageTagMutability}'# Secrets Manager シークレット確認aws secretsmanager describe-secret--secret-id /codebuild/db-password--query '{name:Name,arn:ARN}'

version: 0.2phases:  install: runtime-versions:nodejs: 20 commands:- npm install -g aws-cdk on-failure: ABORT  pre_build: commands:- aws ecr get-login-password --region $AWS_DEFAULT_REGION \ | docker login --username AWS \--password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com on-failure: ABORT  build: commands:- npm ci- npm run test- npm run build on-failure: ABORT  post_build: commands:- aws s3 sync dist/ s3://$ARTIFACT_BUCKET/

aws codebuild batch-get-builds \  --ids "my-project:abc123" \  --query 'builds[0].{status:buildStatus,phase:currentPhase}'

cache:  type: S3  location: my-codebuild-cache-bucket/my-project-cache  paths: - node_modules* - ~/.gradle/caches* - /root/.m2/repository* - /root/.cache/pip*

cache:  type: LOCAL  modes: - LOCAL_CUSTOM_CACHE - LOCAL_DOCKER_LAYER_CACHE - LOCAL_SOURCE_CACHE

resource "aws_codebuild_project" "app" {  cache { type  = "S3" location = "${aws_s3_bucket.cache.bucket}/my-project"  }}

artifacts:  type: S3  location: my-artifact-bucket  path: builds/$CODEBUILD_BUILD_NUMBER/  name: app-dist.zip  base-directory: dist  files: - "***"- "test-results*"

# NG: スカラー文字列 → CodeBuild がシーケンスとして解釈できずアーティファクトが空になるartifacts:  files: "***']# OK: YAML シーケンス形式artifacts:  files: - "*** 必須
✅ on-failure: ABORT を全フェーズに設定
✅ artifacts.discard-paths: no を原則採用
✅ batch build 使用時は fast-fail の挙動を確認

3-8. 3点セット: Terraform buildspec 指定 + CLI + コンソール

Terraform: inline buildspec vs S3 参照

# Option A: inline buildspec (Terraform 管理・小〜中規模向け)resource "aws_codebuild_project" "app_inline" {  source { type  = "GITHUB" location = "https://github.com/my-org/my-repo.git" buildspec = <<-BUILDSPECversion: 0.2phases:  build: commands:- npm run build- aws s3 sync dist/ s3://$ARTIFACT_BUCKET/ BUILDSPEC  }}# Option B: リポジトリ内パス参照 (複数プロジェクト共通化・大規模向け)resource "aws_codebuild_project" "app_file" {  source { type= "GITHUB" location  = "https://github.com/my-org/my-repo.git" buildspec = "buildspec/prod.yml"  # リポジトリルートからの相対パス  }}

inline vs S3 参照の選択基準: buildspec をコードと同期管理するなら Option B (リポジトリ内パス) 推奨。Terraform で buildspec バージョン管理するなら Option A (inline)。複数プロジェクトが同一 buildspec を共有する場合は S3 バケット参照 (s3://bucket/buildspec.yml) も有効。

AWS CLI: ビルド操作の基本セット

# ビルド開始aws codebuild start-build --project-name my-project# ビルド一覧 (直近 5 件)aws codebuild list-builds \  --sort-order DESCENDING \  --query 'ids[:5]' --output text# ビルド詳細 (ステータス + 成果物 S3 パス)aws codebuild batch-get-builds \  --ids "my-project:abc123" \  --query 'builds[0].{status:buildStatus,artifact:artifacts.location}'# buildspec を上書きして開始 (デバッグ用)aws codebuild start-build \  --project-name my-project \  --buildspec-override file://buildspec-debug.yml

コンソール確認: CodeBuild コンソール → ビルドプロジェクト → 「ビルド設定」タブ → Buildspec セクション でリポジトリパス / inline の設定を確認。ビルド詳細 → 「フェーズの詳細」タブ で各フェーズの所要時間・エラーログを参照可能。

4. マルチアーキテクチャ Docker build (arm64+x86_64 ECR push)

4-1. なぜマルチアーキテクチャ対応が必要か

AWS Graviton インスタンス (C7g/M7g/R7g) が EC2・ECS・Lambda で普及し、x86_64 と arm64 の両プラットフォームに対応したコンテナイメージを 1 つの ECR リポジトリで管理するニーズが高まっている。OCI 仕様の manifest list を使えば docker pull 実行時に実行ホストのアーキテクチャに応じて正しい image layer が自動的に選択される。

• コスト削減: Graviton3 は同性能・同料金帯の x86_64 比で最大 40% 安価。ECS タスクや Lambda を arm64 イメージに切り替えるだけで削減効果を得られる。
• 開発速度向上: Apple Silicon (M2/M3) 搭載 Mac でのローカル docker run が arm64 native 動作となり、QEMU エミュレーションによる速度低下を回避できる。
• 単一リポジトリ管理: arm64 用と x86_64 用でリポジトリを分ける必要がなく、CI/CD パイプラインのタグ管理がシンプルになる。

4-2. docker buildx のセットアップ (driver 選択が鍵)

CodeBuild でマルチアーキ manifest list を生成するには docker buildx と --driver docker-container の組み合わせが必須。デフォルトの docker ドライバーも --platform フラグを受け付けるが、cross-platform export に必要な BuildKit のフル機能が使えず manifest list を生成できない。

# driver=docker-container を明示 (省略すると multi-platform export 不可)docker buildx create \  --driver docker-container \  --name multiarch-builder \  --use# 作成した builder を確認docker buildx ls# NAME/NODE  DRIVER/ENDPOINT STATUSPLATFORMS# multiarch-builder * docker-containerrunning  linux/amd64, linux/arm64

buildspec.yml の pre_build フェーズ冒頭でこのコマンドを実行する。--use フラグで作成した builder がデフォルトになる。CodeBuild プロジェクトの privileged_mode = true も必須。

4-3. buildspec.yml 実装 (Batch build 並列方式)

arm64 と x86_64 を CodeBuild Batch build の並列ジョブで別々にビルドし、各 digest を ECR に push してから manifest list を合成する。各アーキに最適な compute type を使えるため QEMU エミュレーション不要で native ビルドが可能。

buildspec-arm64.yml

version: 0.2env:  variables: DOCKER_BUILDKIT: "1" BUILDX_VERSION: "0.12.1" IMAGE_REPO_NAME: "my-app" AWS_DEFAULT_REGION: "ap-northeast-1" AWS_ACCOUNT_ID: "123456789012"phases:  install: commands:- |  curl -fsSL \ "https://github.com/docker/buildx/releases/download/v${BUILDX_VERSION}/buildx-v${BUILDX_VERSION}.linux-arm64" \ -o /usr/local/lib/docker/cli-plugins/docker-buildx  chmod +x /usr/local/lib/docker/cli-plugins/docker-buildx  pre_build: commands:- |  aws ecr get-login-password --region $AWS_DEFAULT_REGION \ | docker login --username AWS \  --password-stdin \  ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com- docker buildx create --driver docker-container --name builder --use  build: commands:- |  docker buildx build \ --platform linux/arm64 \ --tag ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${IMAGE_REPO_NAME}:arm64-${CODEBUILD_RESOLVED_SOURCE_VERSION} \ --push .

buildspec-amd64.yml は上記の linux/arm64 を linux/amd64 に、arm64- タグを amd64- に変更し、install フェーズの buildx バイナリ URL を linux-amd64 に差し替えるだけで対応できる。

親プロジェクトの buildspec に Batch build 定義を配置し、2 ジョブを並列起動する。

version: 0.2batch:  build-list: - identifier: arm64_buildbuildspec: buildspec-arm64.ymlenv:  type: ARM_CONTAINER  compute-type: BUILD_GENERAL1_SMALL - identifier: amd64_buildbuildspec: buildspec-amd64.ymlenv:  type: LINUX_CONTAINER  compute-type: BUILD_GENERAL1_SMALL

4-4. ECR manifest list の作成と push

2 プロジェクトのビルドが完了し各 tagged image が ECR に存在する状態で manifest list を作成する。

# ECR へ再ログイン (長時間ビルド後の token 期限切れ対策)aws ecr get-login-password --region ap-northeast-1 \  | docker login --username AWS \--password-stdin \123456789012.dkr.ecr.ap-northeast-1.amazonaws.comREPO="123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app"COMMIT="${CODEBUILD_RESOLVED_SOURCE_VERSION}"# manifest list を作成docker manifest create ${REPO}:latest \  --amend ${REPO}:arm64-${COMMIT} \  --amend ${REPO}:amd64-${COMMIT}# ECR へ pushdocker manifest push ${REPO}:latest# push 確認aws ecr describe-images \  --repository-name my-app \  --image-ids imageTag=latest \  --query 'imageDetails[0].imageManifestMediaType'# 期待値: "application/vnd.docker.distribution.manifest.list.v2+json"

ECR リポジトリは image_tag_mutability = "MUTABLE" に設定しておく。IMMUTABLE のままだと既存タグへの manifest list 上書きが ImageAlreadyExistsException で拒否される。

4-5. Terraform 実装 (arm64/x86_64 CodeBuild プロジェクト)

resource "aws_ecr_repository" "app" {  name  = "my-app"  image_tag_mutability = "MUTABLE"  image_scanning_configuration { scan_on_push = true  }}resource "aws_codebuild_project" "app_arm64" {  name = "my-app-build-arm64"  build_timeout = 20  service_role  = aws_iam_role.codebuild.arn  source { type= "GITHUB" location  = "https://github.com/example/my-app.git" buildspec = "buildspec-arm64.yml"  }  environment { compute_type = "BUILD_GENERAL1_SMALL" image  = "aws/codebuild/standard:7.0" type= "ARM_CONTAINER" privileged_mode = true environment_variable {name  = "DOCKER_BUILDKIT"value = "1" }  }  artifacts { type = "NO_ARTIFACTS" }  cache { type  = "LOCAL" modes = ["LOCAL_DOCKER_LAYER_CACHE", "LOCAL_SOURCE_CACHE"]  }}resource "aws_codebuild_project" "app_amd64" {  name = "my-app-build-amd64"  build_timeout = 20  service_role  = aws_iam_role.codebuild.arn  source { type= "GITHUB" location  = "https://github.com/example/my-app.git" buildspec = "buildspec-amd64.yml"  }  environment { compute_type = "BUILD_GENERAL1_SMALL" image  = "aws/codebuild/standard:7.0" type= "LINUX_CONTAINER" privileged_mode = true environment_variable {name  = "DOCKER_BUILDKIT"value = "1" }  }  artifacts { type = "NO_ARTIFACTS" }  cache { type  = "LOCAL" modes = ["LOCAL_DOCKER_LAYER_CACHE", "LOCAL_SOURCE_CACHE"]  }}

4-6. AWS CLI で動作確認

# arm64 ビルドを手動トリガーaws codebuild start-build \  --project-name my-app-build-arm64 \  --source-version refs/heads/main# amd64 ビルドを手動トリガーaws codebuild start-build \  --project-name my-app-build-amd64 \  --source-version refs/heads/main# manifest list のアーキテクチャ構成を確認docker buildx imagetools inspect \  123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest# MediaType: application/vnd.docker.distribution.manifest.list.v2+json# Platforms: linux/amd64, linux/arm64

4-7. コンソール確認

1. CodeBuild コンソール → my-app-build-arm64 / my-app-build-amd64 → Start build → Build logs タブで --platform linux/arm64 (linux/amd64) ... --push が成功することを確認。
2. ECR コンソール → my-app リポジトリ → Images タブ → latest タグを選択 → Manifest type が OCI Image Index になっていることを確認。
3. イメージスキャン: latest イメージ行の Scan results タブで脆弱性スキャン結果を確認する。

4-8. GHA 比較コラム

GitHub Actions でマルチアーキ対応するには docker/setup-buildx-action + docker/build-push-action の matrix 構成が一般的。CodeBuild Batch build との主な違いを整理する。

4-9. 落とし穴と対策

5. VPC内ビルド + NAT Gateway/Secrets Manager統合

5-1. VPC内ビルドが必要なケース

CodeBuild のデフォルトビルド環境は VPC 外のマネージド環境で動作する。以下のケースでは VPC 内ビルドへの切り替えが必要になる。

• プライベートリソースへの接続: RDS/Aurora/ElastiCache/MSK 等、VPC 内部にのみ存在するエンドポイントへテストや DB マイグレーションのため接続する
• セキュリティ要件: 全トラフィックを VPC 内に閉じ、インターネット直接通信を禁止する場合
• VPC エンドポイント利用: ECR/S3/Secrets Manager 等を VPC エンドポイント経由でのみ利用する場合
• マルチアカウント VPC 共有: Resource Access Manager (RAM) で共有された VPC 経由でリソース接続する場合

VPC 内ビルドを有効にすると CodeBuild はビルド開始時に指定した subnet に ENI を 1 枚作成する。1 ビルド = 1 ENI が基本であり、並列ビルドが増えるほど IP アドレスを消費する。

5-2. IPプール容量設計 (ENI数計算式)

VPC 内ビルドで最も多い障害原因が subnet の IP アドレス枯渇による ENI 作成失敗だ。事前に以下の計算式で必要 IP 数を算出する。

必要 IP 数 = 最大同時ビルド数 × 1 ENI/ビルド + 予備 20%例: 並列 50 ビルド → 50 IP 必要  /26 (利用可能 64 IP - AWS予約 5 = 59 IP) → ギリギリ。障害リスクあり  /24 (利用可能 256 IP - AWS予約 5 = 251 IP) → 推奨。余裕あり複数 subnet 分散: 2 AZ で /26 ずつ → 合計 118 IP → 並列 98 ビルドまで対応可能

AWS が subnet ごとに予約する 5 IP (ネットワークアドレス/ルーター/DNS/将来用×2/ブロードキャスト) を差し引いた実使用可能数で計算すること。本番環境では /24 以上を推奨、または複数 subnet を指定して AZ 間で分散する。

# 現在の subnet 空き IP 数を確認aws ec2 describe-subnets \  --subnet-ids subnet-0abc1234 \  --query "Subnets[].{id:SubnetId,available:AvailableIpAddressCount,cidr:CidrBlock}"

5-3. CodeBuild VPC設定 (vpc_config ブロック)

CodeBuild プロジェクトの VPC 設定に必要な 3 要素は vpc_id / subnets / security_group_ids の指定だ。buildspec.yml 側は変更不要。VPC 設定はプロジェクトレベルで適用される。

VPC 内ビルドで外部インターネット通信が必要な場合 (npm install / pip / docker pull 等) は private subnet + NAT Gateway 構成が必要だ。Public subnet では CodeBuild ENI にパブリック IP が付与されないためインターネットに到達できない。

Security Group の設定方針は ingress ルールなし・egress を最小限に絞る。CodeBuild は外部から接続を受け付けないため ingress は不要だ。

egress 443/tcp → 0.0.0.0/0# HTTPS (npm/pip/ECR/AWS API)egress 80/tcp  → 0.0.0.0/0# HTTP (一部 OS パッケージ)ingress: なし (CodeBuild は接続を受け付けない)

5-4. Secrets Manager統合 (type=SECRETS_MANAGER / env-vars-files)

Secrets Manager の secret を CodeBuild に渡す方法は 2 種類ある。

方法A: 環境変数 (type=SECRETS_MANAGER)

environment_variable の type を SECRETS_MANAGER にし、value に secret-id:json-key 形式で指定する。buildspec.yml 内では通常の環境変数として ${DB_PASSWORD} で参照できる。

# buildspec.yml での参照 (通常の環境変数として透過的に使用)env:  secrets-manager: DB_PASSWORD: "prod/app/db:password" API_KEY: "prod/app/api:key"

secret-id:json-key の形式: Secrets Manager の secret 値が JSON オブジェクトの場合、コロン区切りで取得する key を指定する。JSON でないプレーン文字列の場合は secret-id のみ指定。

方法B: env-vars-files (ファイル展開形式)

複数の secret を一括取得して .env ファイル形式でビルドコンテナに展開する方法。secret の個数が増えた場合でも buildspec.yml が肥大化しない。

# buildspec.yml での env-vars-files 指定env:  secrets-manager: ENV_FILE_CONTENT: "prod/app/env-file"env-vars-files:  - "/tmp/app.env"

# Secrets Manager に登録する secret の値 (JSON 文字列として保存){"DB_HOST":"db.internal","DB_PASSWORD":"s3cr3t","API_KEY":"abc123"}# CodeBuild が /tmp/app.env として書き出す内容 → 環境変数に自動展開DB_HOST=db.internalDB_PASSWORD=s3cr3tAPI_KEY=abc123

5-5. 3点セット: VPC + Secrets Manager 統合

Terraform (要点)

Terraform での完全な HCL は §6 に記載する。ここでは vpc_config と Secrets Manager 統合の要点を示す。

# aws_codebuild_project の vpc_config blockvpc_config {  vpc_id = aws_vpc.main.id  subnets= [aws_subnet.private_a.id, aws_subnet.private_b.id]  security_group_ids = [aws_security_group.codebuild.id]}# Secrets Manager 参照の環境変数environment {  compute_type = "BUILD_GENERAL1_SMALL"  image  = "aws/codebuild/standard:7.0"  type= "LINUX_CONTAINER"  privileged_mode = true  environment_variable { name  = "DB_PASSWORD" value = "prod/app/db:password" type  = "SECRETS_MANAGER"  }}

AWS CLI

# 既存プロジェクトに VPC 設定を追加 (update-project)aws codebuild update-project \  --name my-codebuild-project \  --vpc-config vpcId=vpc-0abc1234,subnets=subnet-0def5678,securityGroupIds=sg-0ghi9012# Secrets Manager の secret 現在値を確認 (ビルド前の動作確認に)aws secretsmanager get-secret-value \  --secret-id prod/app/db \  --query "SecretString" \  --output text | python3 -m json.tool# VPC 設定の確認aws codebuild batch-get-projects \  --names my-codebuild-project \  --query "projects[].vpcConfig"# CodeBuild プロジェクトに resource-based policy を設定 (クロスアカウント共有時)aws codebuild put-resource-policy \  --resource-arn arn:aws:codebuild:ap-northeast-1:123456789012:project/my-project \  --policy file://policy.json

コンソール操作

1. CodeBuild コンソール → 対象プロジェクト → 「編集」→「環境」タブを開く
2. 「VPC」セクション: VPC を選択 → private subnet を選択 → Security Group を選択して保存
3. 「環境変数」セクション: 「タイプ」を「Secrets Manager」→「値」に secret-id:key 形式で入力
4. テストビルドを実行 → 「ビルドログ」→「PROVISIONING」フェーズで ENI 作成ログを確認

5-6. 落とし穴4選

落とし穴1: VPC subnet IP不足で ENI 作成失敗

CLIENT_ERROR: PROVISIONING: Failed to prepare build environment.The subnet does not have enough free addresses to allocate a network interface. subnet-0abc1234

解決策: subnet の CIDR を /24 以上に拡大するか、vpc_config.subnets に複数 subnet を指定して IP プールを AZ 間で分散させる。

落とし穴2: NAT Gateway不在でインターネット通信失敗

private subnet に NAT Gateway (or VPC エンドポイント) がない状態でビルドすると npm install や pip install が全て失敗する。

npm ERR! code ENOTFOUNDnpm ERR! errno ENOTFOUNDnpm ERR! network request to https://registry.npmjs.org/ failed,reason: getaddrinfo ENOTFOUND registry.npmjs.org

解決策: route table に NAT Gateway へのルート (0.0.0.0/0 → nat-XXXXXXXX) を追加する。外部通信が不要な場合は VPC エンドポイント (ECR/S3/Secrets Manager) のみ有効にする構成でコストを削減できる。

落とし穴3: Secrets Manager IAMポリシー権限不足

IAM Role に secretsmanager:GetSecretValue が欠けているとビルドが以下のエラーで失敗する。

CLIENT_ERROR: AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/codebuild-role is not authorized to perform: secretsmanager:GetSecretValueon resource: prod/app/db because no identity-based policy allows the action

解決策: IAM Policy に secretsmanager:GetSecretValue を追加する。CMK で暗号化している場合は kms:Decrypt も必要だ。リソース ARN は arn:aws:secretsmanager:*:*:secret:prod*' - '/root/.gradle/caches*' - '/root/.cache/pip*'phases: install: commands:- npm ci # S3/LOCAL cache hit で 50-70% 短縮

# キャッシュヒット確認 (CloudWatch Logs でフィルタ)aws logs filter-log-events \  --log-group-name "/aws/codebuild/my-project" \  --filter-pattern "Cache" \  --query 'events[*].message'

7-4-3. Lambda compute (BUILD_LAMBDA)

コンテナ起動時間なし・最小課金単位 100ms でコスト効率が高い。ただし Docker daemon は使用不可 (§7-6 落とし穴 参照)。

resource "aws_codebuild_project" "lambda_compute" {  name = "my-lambda-compute-project"  environment { compute_type = "BUILD_LAMBDA_1GB" image  = "aws/codebuild/amazonlinux-x86_64-lambda-standard:corretto21" type= "LINUX_LAMBDA_CONTAINER" # privileged_mode = true は Lambda compute で無効 (設定しても効果なし)  }  # ...}

# Lambda compute 設定確認aws codebuild batch-get-projects \  --names my-lambda-compute-project \  --query 'projects[0].environment.{type:type,compute:computeType,image:image}'

コンソール: プロジェクト → 「環境」→ コンピューティング: 「Lambda」を選択 → メモリ 1GB / 2GB / 4GB から選択。

7-4-4. コスト比較表

※ 1 ビルドあたり平均 5 分と仮定。リージョン・コンピュートタイプにより変動あり。

7-5. Terraform 使い分けまとめ

# 変数でコンピュートタイプを切替variable "use_spot" {  description = "Spot fleet を使用するか"  type  = bool  default  = true}variable "use_lambda_compute" {  description = "Lambda compute を使用するか (Docker 不要のジョブのみ)"  type  = bool  default  = false}locals {  environment_type = var.use_lambda_compute ? "LINUX_LAMBDA_CONTAINER" : "LINUX_CONTAINER"  compute_type  = var.use_lambda_compute ? "BUILD_LAMBDA_1GB" : "BUILD_GENERAL1_LARGE"  image= var.use_lambda_compute ? "aws/codebuild/amazonlinux-x86_64-lambda-standard:corretto21" : "aws/codebuild/standard:7.0"}

コンソール: CodeBuild → 「ビルド履歴」→ 「期間」列で実際のビルド時間を確認 → プロジェクト設定の「タイムアウト」を実績の 2 倍程度に設定すると無駄なコスト上限を設けられる。

7-6. ローカルデバッグ・コスト関連の落とし穴

1. BUILD_LAMBDA は Docker daemon 非対応: privileged_mode = true を設定しても docker build は実行できない。Docker イメージビルドが必要な場合は EC2 ベースコンピューティングを使用する。
2. Spot fleet 中断によるビルド失敗: EC2 Spot が中断されるとビルドが途中で終了する。CodePipeline 連携時は retryOnFailure、スタンドアロン時は CloudWatch Events + Lambda で自動再試行を設定する。
3. cache invalidation 手動実行が必要: buildspec.yml の cache.paths を変更しても S3 キャッシュは自動無効化されない。変更後は aws codebuild invalidate-project-cache --project-name <name> を実行する。
4. LOCAL DOCKER_LAYER_CACHE は VPC 内ビルド非対応: VPC 設定と LOCAL キャッシュを併用する場合は S3 タイプのキャッシュを使用する。

8. まとめ + Vol3予告 + よくある落とし穴10選

8-1. 本記事の振り返り

本記事では CodeBuild を本番運用品質で活用するための 6 テーマを解説した。

• Prev

  

  2026-04-26

  AWS Code* ファミリー徹底解説 Vol1 全体像 GHA ecspresso比較

• Next

  

  2026-04-27

  AWS CodePipeline V2 CodeDeploy 本番運用 ECS Blue/Green Lambda Canary