IAM Role 最小権限例 (アプリ用 = taskRoleArn)

S3アクセスのみ必要なケース:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": [
        "arn:aws:s3:::app-prod-uploads/*",
        "arn:aws:s3:::app-prod-backups/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::app-prod-uploads",
        "arn:aws:s3:::app-prod-backups"
      ]
    }
  ]
}

Resource: "*" 禁止。バケット単位で絞る。

環境ごとの構成

環境	用途	ストレージ	デプロイ条件
local	開発者ローカル	MinIO (Docker)	手動 (make up)
dev	共通開発環境 (AWS)	S3 (dev用バケット)	develop push 時 自動
staging	本番相当の検証	S3 (staging用)	リリースタグ作成時
production	本番	S3 (prod用)	手動承認後の deploy ワークフロー

デプロイと認証

デプロイ戦略

• Rolling Update (デフォルト): ECS の Deployment 機能を使う
• Blue/Green: CodeDeploy統合 (大規模変更時)
• Canary: 機能フラグ (Feature Flag) と組み合わせる
• Rollback: aws ecs update-service で前バージョンのtask definitionに戻す
• 緊急停止: Desired Count を 0 にする / 機能フラグでOFF

ローカル ⇔ CI ⇔ 本番の認証差分まとめ

環境	認証方式	設定場所
ローカル (MinIO)	固定アクセスキー	.env (gitignore)
CI (GitHub Actions)	OIDC → IAM Role Assume	ワークフローYAML
本番 (ECS Fargate)	Task Role (IRSA相当)	Task Definition

コストと運用

コスト・運用の注意点

• ECR: lifecycle policy で古いイメージを自動削除 (デフォルトのままだと無限に溜まる)
• CloudWatch Logs: 保持期間を明示 (デフォルトは無期限でコスト高)
• S3: ライフサイクルで Glacier 移行 / 古いオブジェクト自動削除
• Secrets Manager: $0.40/secret/月 (記憶ベース、要最新確認)。機密度低いものは Parameter Store (無料枠あり) で代替
• NAT Gateway: 意外と高い。VPC設計で privatelink / VPC endpoint も検討

.cursor/rules/ への追補

70-local-env.mdc に AWS 周りを追補:

## ストレージ
- ローカル: MinIO コンテナ経由 (環境変数 AWS_ENDPOINT_URL で切替)
- 本番: S3 + IAM Task Role
- アプリコードで AWS_ACCESS_KEY_ID を本番にハードコードしない
- S3 アクセスは boto3 / aws-sdk のデフォルト credential chain に任せる

## CI/CD
- GitHub Actions の認証は OIDC のみ。長期アクセスキー禁止
- IAM Role 信頼ポリシーは リポジトリ・ブランチで絞る
- 新規 AWS リソースは Terraform / CDK でコード化、手動作成禁止

NOTE: AWS のサービス名・料金・API仕様は時々変わる。実プロジェクトで採用する際は AWS公式ドキュメント・料金ページで最新を確認すること。本セクションは2026年初頭時点の一般的なパターンに基づいた仮想定。