AWS AppConfig

AWS AppConfig は Systems Manager の一機能で、機能フラグ（フィーチャーフラグ）やアプリケーションの設定値を、アプリのコードを再デプロイすることなく安全に配信・更新するための構成管理サービスです。設定を段階的に展開し、検証とモニタリングを挟みながら、異常を検知したら自動でロールバックできる点が特徴です。

解決する課題

• 設定値を1か所変えるだけでもアプリ全体を再デプロイしなければならず時間がかかる → コードと設定を分離して配信したい
• 新機能を全ユーザーに一斉公開するのが怖い → 一部から段階的に有効化して様子を見たい
• 誤った設定を本番に流して全台で障害が起きるのを防ぎたい → 配信前に検証し、異常時は即座に戻したい
• 設定の変更履歴や「いつ・どのバージョンを配ったか」が追えない → バージョン管理と監査を効かせたい
• 構文ミスや型違反の設定がそのまま配られてしまう → スキーマやロジックで事前バリデーションしたい

主要概念と用語

• アプリケーション（Application）: AppConfig 上で設定を管理する論理的な単位。1つのサービスやプロダクトに対応させることが多い
• 環境（Environment）: 配信先のターゲット群を表す区分。本番・ステージング・開発のように分け、環境ごとに監視やロールバックの設定を持つ
• 構成プロファイル（Configuration Profile）: 配信する設定の取得元と種別を定義したもの。フリーフォーム構成と機能フラグの2種類がある
• フリーフォーム構成（Freeform Configuration）: JSON・YAML・テキストなど任意形式の設定データ。Parameter Store・S3・AppConfig 内部のホスト構成などを取得元にできる
• 機能フラグ（Feature Flag）: 機能のオン・オフや付随する属性値を管理する専用の構成タイプ。フラグごとに有効・無効と属性を保持する
• デプロイ戦略（Deployment Strategy）: 設定をどのくらいの速度・刻みで展開するかを定義したもの。一括・線形・指数などの増加パターンとベイク時間を指定する
• デプロイ（Deployment）: ある構成バージョンを特定の環境へ展開する操作。戦略に従って徐々にロールアウトされる
• バリデータ（Validator）: 配信前に設定をチェックする仕組み。JSON Schema による構文検証と、Lambda による任意ロジック検証がある
• モニター（Monitor）: 環境に紐づける CloudWatch アラーム。デプロイ中にアラーム状態になると自動ロールバックが発動する
• ベイク時間（Bake Time）: 全体への展開が完了した後、問題が出ないか監視のために待機する時間

仕様・制限・クォータ

• 設定の取得は、アプリ側が GetLatestConfiguration をポーリングする方式が基本。多くの場合は AppConfig Agent（Lambda 拡張やコンテナのサイドカー、EC2 上のエージェント）を介して取得する
• AppConfig Agent はローカルでキャッシュとポーリングを担い、アプリは ローカルのHTTPエンドポイントから最新設定を読むだけでよい
• 構成データには1回の取得で扱えるサイズに上限があり、大きすぎる設定は分割や S3 取得元の利用を検討する
• デプロイは1つの環境につき同時に1つしか進行できない。展開中は次のデプロイを開始できない
• アプリケーション・環境・構成プロファイル・デプロイ戦略などの数にはアカウント単位のクォータがあり、必要に応じて上限緩和を申請できる
• 機能フラグはバージョン管理され、過去バージョンへ戻すことができる

内部の仕組み

AppConfig ではまず アプリケーション の下に 環境 と 構成プロファイル を作成します。構成プロファイルは設定の取得元（AppConfig ホスト・Parameter Store・S3 など）と種別（フリーフォームか機能フラグか）を表し、設定を更新するたびに新しいバージョンが作られます。

デプロイを開始すると、選んだ デプロイ戦略 に従って設定が環境内のターゲットへ徐々に反映されます。線形なら一定割合ずつ、指数なら加速度的に展開され、最後に ベイク時間 の監視期間を経て完了します。展開の前段では バリデータ（JSON Schema と Lambda）が設定をチェックし、検証に失敗したデプロイは開始されません。

展開中は環境に紐づけた モニター（CloudWatch アラーム）が監視されます。アラームがしきい値を超えると AppConfig は展開を止め、直前の正常なバージョンへ 自動ロールバック します。アプリ側は AppConfig Agent 経由で最新の有効バージョンを取得するため、ロールバックは次のポーリングで自然に反映されます。

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

• 機能フラグでリリースを切り離す: 機能のデプロイ（コードを出す）とリリース（機能を有効化する）を分け、コードを先に出しておいてフラグで段階公開する
• 段階的ロールアウトを既定にする: 一括展開ではなく線形・指数の戦略を使い、影響範囲を絞りながら様子を見る
• アラームを必ず紐づける: エラー率やレイテンシの CloudWatch アラームをモニターに設定し、自動ロールバックを効かせる
• バリデータで事前検証: JSON Schema で構文を、Lambda で業務ロジック上の妥当性を検証し、不正な設定の配信を未然に防ぐ
• 環境を分けて段階昇格: 開発・ステージング・本番を環境として分離し、下位から順に昇格させる
• エージェントを使う: アプリに直接 API を実装するより、AppConfig Agent を使ってキャッシュ・ポーリング・取得を任せると実装がシンプルになる

運用・監視

• デプロイの進行状況（展開割合・現在のステップ・ベイク時間の残り）をコンソールや CLI で確認する
• モニターに設定した CloudWatch アラームの状態を監視し、自動ロールバックが発動した場合は原因の設定変更を特定する
• 設定の取得やバリデーションの失敗は CloudTrail や CloudWatch のメトリクス・ログで追跡できる
• 機能フラグのバージョン履歴を確認し、どのバージョンが現在配信されているかを把握する
• ロールバックが起きやすい設定は、戦略の刻みを細かくしベイク時間を延ばして影響を抑える

コスト

従量課金で、主に 設定の取得回数（GetLatestConfiguration の呼び出し）と受信した構成データの量に対して課金されます。アプリが頻繁にポーリングするほど取得回数が増えますが、AppConfig Agent のローカルキャッシュとポーリング間隔の調整で呼び出しを抑えられます。バリデーションに使う Lambda の実行や、設定の取得元として使う S3・Parameter Store の利用は、それぞれのサービス側で別途課金されます。最新の料金は公式の料金ページで確認してください。

セキュリティ

• 設定の作成・更新・デプロイの権限は IAM で制御し、本番環境へのデプロイ権限は限られた主体に絞る
• 取得元に Parameter Store の SecureString や S3 を使う場合は、KMS による暗号化とアクセス制御を施す
• アプリが設定を取得するロールには、必要な構成プロファイルへの読み取りだけを許可する最小権限を割り当てる
• 機密情報そのものは Secrets Manager や Parameter Store の SecureString で管理し、AppConfig は配信と切り替えの制御に用いるのが基本
• すべての操作は CloudTrail に記録されるため、誰がいつどの設定を配信したかを監査できる

Well-Architected の観点

• 運用上の優秀性: 設定変更をコードのデプロイから切り離し、段階的なロールアウト・検証・自動ロールバックによって変更を安全に行える。これにより小さく頻繁な変更を低リスクで回せる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# アプリケーションを作成
aws appconfig create-application --name my-app

# 環境を作成（APP_ID は前のコマンドの出力 Id）
aws appconfig create-environment \
  --application-id APP_ID \
  --name production

# 機能フラグ用の構成プロファイルを作成
aws appconfig create-configuration-profile \
  --application-id APP_ID \
  --name feature-flags \
  --location-uri hosted \
  --type AWS.AppConfig.FeatureFlags

# 構成バージョンを登録（content は機能フラグ定義の JSON）
aws appconfig create-hosted-configuration-version \
  --application-id APP_ID \
  --configuration-profile-id PROFILE_ID \
  --content-type application/json \
  --content fileb://flags.json \
  output.json

# 段階配信のデプロイを開始（事前定義のデプロイ戦略を利用）
aws appconfig start-deployment \
  --application-id APP_ID \
  --environment-id ENV_ID \
  --configuration-profile-id PROFILE_ID \
  --configuration-version 1 \
  --deployment-strategy-id AppConfig.Linear50PercentEvery30Seconds