AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

AWS AppConfigは、アプリケーションのフィーチャーフラグや動的設定を、安全に検証し、段階的に本番環境へ配信するためのAWS Systems Managerの機能です。 コードを再デプロイせずに、機能の有効化、許可/拒否リスト、スロットリング値、ログレベル、運用パラメータを変更できます。

試験では「設定値をParameter StoreやS3に保存する」だけでなく、「検証、段階的ロールアウト、CloudWatchアラームによる自動ロールバックまで行いたい」場合にAppConfigを選びます。 アプリコードのデプロイはCodeDeploy/CodePipeline、機密値の保管はSecrets Manager、単純なパラメータ保管はParameter Storeと比較します。

2. 主な特徴と機能

2.1 フィーチャーフラグ

新機能をコードに含めたまま無効化し、一部ユーザー、環境、割合に対して段階的に有効化できます。 問題があればコードをロールバックせず、フラグを戻して即座に機能を停止できます。

2.2 動的設定

ログレベル、タイムアウト、スロットリング、許可/拒否リスト、外部連携先、運用閾値などをコードから分離します。 頻繁に変わる設定や、誤設定が障害につながる値を安全に管理します。

2.3 設定プロファイルと保存先

設定プロファイルは設定データの場所と種類を定義します。 AppConfig hosted configuration store、Systems Manager Parameter Store、AWS Secrets Manager、Amazon S3などを設定ソースとして利用できます。

2.4 バリデータ

JSON SchemaやLambdaバリデータで、構文と意味的な正しさをデプロイ前に検証します。 不正な設定を本番に配信しないことが、AppConfigの重要な安全機能です。

2.5 デプロイ戦略と自動ロールバック

All-at-once、Canary、Linear、独自戦略などで設定を段階的に配信できます。 CloudWatchアラームと連携し、エラー率やレイテンシー悪化を検知した場合に自動ロールバックできます。

2.6 AppConfig Agent

AppConfig Agentは設定データをローカルにキャッシュし、アプリケーションがlocalhost経由で取得できるようにします。 直接APIを頻繁に呼ぶより、レイテンシーと取得コストを抑えやすい点が重要です。

3. アーキテクチャおよび技術要素

1. AppConfigでアプリケーションを作成し、dev/staging/prodなどの環境を定義する。
2. フィーチャーフラグまたは自由形式設定の設定プロファイルを作成し、保存先を指定する。
3. JSON SchemaやLambdaバリデータを設定し、構文と業務ルールを検証する。
4. デプロイ戦略、ベイク時間、CloudWatchアラームを指定して設定をデプロイする。
5. AppConfigが設定を検証し、段階的に環境へ配信する。
6. アプリケーションはAppConfig AgentまたはAppConfig Data APIから最新設定を取得する。
7. 異常がCloudWatchアラームで検出されると、AppConfigが設定を前の安定版へロールバックする。

AppConfigは「設定を保存する場所」だけではなく、「設定を安全に配信する制御面」です。 保存先、検証、配信戦略、監視、取得方法を分けて理解すると、試験のサービス選択問題で判断しやすくなります。

4. セキュリティと認証・認可

• IAM最小権限: 設定の作成、承認、デプロイ、取得の権限を分離し、本番設定の誤変更を防ぐ。
• KMS暗号化: 保存先や機密設定に応じてKMSによる暗号化を利用する。
• Secrets Manager連携: パスワードやAPIキーなどの機密情報はSecrets Managerに置き、AppConfigで安全に配信を管理する。
• バリデーション: JSON SchemaやLambdaで値の範囲、必須項目、依存関係を検証する。
• 監査: CloudTrailで設定変更、デプロイ開始、ロールバック操作を追跡する。
• 環境分離: dev/staging/prodで環境を分け、同じ設定を本番へ直接反映しない。

5. 料金形態

AWS AppConfigは、設定データやフィーチャーフラグの取得を中心とした従量課金で考えます。 AppConfig Agentを使うと、設定取得をローカルキャッシュでき、直接APIを頻繁に呼ぶ構成よりコストとレイテンシーを抑えやすくなります。

• 設定取得: アプリケーションによる設定データ/フィーチャーフラグ取得が課金対象になる。
• 保存先サービス: Parameter Store、Secrets Manager、S3、KMSなどを使う場合は各サービスの料金も考慮する。
• 監視: CloudWatchアラーム、ログ、メトリクスにはCloudWatch側の料金が発生する。
• Lambdaバリデータ: Lambdaで検証する場合、Lambda実行料金が発生する。
• 最適化: Agentキャッシュ、適切なポーリング間隔、不要な環境/フラグ削除でコストを抑える。

6. よくあるアーキテクチャ・設計パターン

• 段階的機能リリース: 新機能を一部ユーザーから有効化し、問題がなければ全体へ拡大する。
• 緊急停止スイッチ: 障害を起こした機能をコードロールバックなしで即座に無効化する。
• 運用パラメータ調整: スロットリング値、ログレベル、タイムアウト、接続先を本番稼働中に変更する。
• 安全な設定配信: JSON Schema/LambdaバリデータとCloudWatchアラームで誤設定を防ぐ。
• マルチ環境管理: dev、staging、prodで同じ設定プロファイルを使い、環境ごとに段階配信する。
• コンテナ/Lambda連携: ECS、EKS、EC2、LambdaでAppConfig Agentや拡張機能を使い、設定をローカル取得する。

7. 設定・デプロイ手順（ハンズオン例）

1. AppConfigでアプリケーションと環境を作成する。
2. フィーチャーフラグまたは自由形式設定の設定プロファイルを作成する。
3. AppConfig hosted configuration store、Parameter Store、Secrets Manager、S3などの保存先を選ぶ。
4. JSON SchemaまたはLambdaバリデータを設定し、設定値を検証できるようにする。
5. CanaryやLinearなどのデプロイ戦略とベイク時間を選択する。
6. CloudWatchアラームを関連付け、異常時に自動ロールバックするよう設定する。
7. アプリケーション側でAppConfig AgentまたはAppConfig Data APIから設定を取得し、動作を確認する。

8. 試験で問われやすいポイント