AWS Config

解決する課題

• 「いつ・誰が・どのリソースの設定を変えたのか」が追えない → 構成変更を時系列で記録したい
• セキュリティグループの全開放や暗号化なしのバケットなど、あるべき設定からの逸脱を見逃す → ルールで自動評価したい
• アカウントもリージョンも多数あり、コンプライアンス状態の全体像が見えない → 組織横断で一元把握したい
• 監査のたびに「この時点の構成はどうだったか」を手作業で再現するのが大変 → 過去の構成を即座に参照したい

主要概念と用語

• 構成項目（Configuration Item, CI）: ある時点のリソースの設定・属性・関連リソースをまとめたスナップショット。設定変更のたびに新しいCIが生成される
• 構成レコーダー（Configuration Recorder）: 記録対象のリソース種別を定義し、変更を検知してCIを記録する仕組み。これを有効化することでConfigが動き始める
• 配信チャネル（Delivery Channel）: CIや設定スナップショットの出力先。主にS3バケットへ保存し、SNSで通知する
• Configルール（Config Rules）: リソースが望ましい状態かを判定する評価ロジック。AWS提供のマネージドルールと、Lambdaで実装するカスタムルールがある
• 準拠・非準拠（Compliant / Non-compliant）: ルール評価の結果。あるべき状態を満たすかどうかを示す
• 修復アクション（Remediation Action）: 非準拠を検知したときに自動で実行する是正処理。多くはSystems Manager Automationドキュメントで実装する
• コンフォーマンスパック（Conformance Pack）: 複数のConfigルールと修復アクションをまとめたパッケージ。一括で適用・管理できる
• アグリゲータ（Aggregator）: 複数アカウント・複数リージョンの構成データと準拠状態を1か所に集約するビュー
• アドバンストクエリ: 集約された構成データに対して、SQLライクな構文でリソースを横断検索する機能

仕様・制限・クォータ

• リージョン単位のサービス。各リージョンで個別に構成レコーダーを有効化する。複数リージョンの状態はアグリゲータで集約する
• 記録対象は グローバルリソース（IAMなど）と リージョナルリソース に分かれる。グローバルリソースの記録は特定リージョンに寄せるのが一般的
• すべてのリソースを記録するか、特定の種別だけを記録するかを選べる。除外指定も可能
• Configルールの評価は 構成変更をトリガーとする方式 と 定期実行する方式 がある
• 1アカウント・1リージョンあたりのルール数などにクォータがあり、上限緩和を申請できる場合がある
• CIには保持期間の概念があり、長期保管したい場合はS3に出力したデータを別途管理する

内部の仕組み

構成レコーダーを有効化すると、Configは対象リソースの作成・更新・削除を検知し、そのたびに 構成項目（CI） を生成します。CIにはリソースの設定値だけでなく、関連リソースとの 関係性 や、対応するCloudTrailイベントへの参照も含まれます。これにより「この変更を引き起こしたAPI呼び出しは何か」まで辿れます。

生成されたCIは 配信チャネル を通じてS3に蓄積され、変更通知はSNSへ送られます。同時に、有効化された Configルール が評価を実行します。変更トリガー型のルールは対象リソースが変わるたびに、定期実行型のルールは設定した間隔で評価され、結果が 準拠・非準拠 として記録されます。

非準拠を検知したときは 修復アクション を紐づけておくと、Systems Manager Automation経由で自動是正できます。さらに評価結果やCIは EventBridge へ流せるため、通知や別ワークフローの起動につなげられます。

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

• 全リージョン・全リソースで有効化: 監査の網羅性を確保するため、原則すべてのリージョンで構成レコーダーを有効化する
• 組織レベルのルール展開: AWS Organizationsと連携し、組織全体へConfigルールやコンフォーマンスパックを一括配信する
• コンフォーマンスパックでまとめる: CISや各種ベンチマークに対応したルール群をパックとして適用し、個別管理の手間を減らす
• 自動修復の活用: 全開放のセキュリティグループや暗号化なしのリソースなど、機械的に直せる逸脱は修復アクションで自動是正する
• アグリゲータで一元化: マルチアカウント・マルチリージョンの準拠状態を集約ビューで把握し、ダッシュボードを一本化する
• Security Hubとの連携前提: Security Hubの多くのコントロールはConfigルールに依存するため、セキュリティ基準を使うならConfigを先に有効化する

運用・監視

• 非準拠リソースの一覧と推移を定点観測し、悪化したら原因ルールを特定する
• EventBridge 経由でSNS通知やLambda・Step Functionsによる対応をつなぎ、逸脱検知をイベント駆動で処理する
• 構成タイムライン で特定リソースの変更履歴を遡り、いつ望ましくない状態になったかを追跡する
• アドバンストクエリ で「暗号化が無効なボリューム」などの条件に合うリソースを横断的に洗い出す
• 修復アクションの実行結果を監視し、自動是正が失敗していないかを確認する

コスト

従量課金で、主に 記録された構成項目（CI）の件数 と Configルールの評価回数 に対して課金されます。コンフォーマンスパックの評価も課金対象です。変更が頻繁なリソースを多数記録するほど、また評価頻度が高いほど費用が増えます。記録対象を必要なリソース種別に絞る、評価が過剰な定期実行ルールの間隔を見直すといった工夫で費用を抑えられます。最新の料金は公式の料金ページで確認してください。

セキュリティ

• CIを出力するS3バケットは 暗号化 とアクセス制限を施し、構成情報の漏洩を防ぐ
• Configや修復に使うサービスロールの権限は 最小権限 に絞る。特に自動修復は強い権限を持ちうるため範囲を限定する
• 構成データ自体が監査の根拠となるため、バケットへの書き込み・削除権限を厳格に管理し、改ざんを防ぐ
• Config自体は検知と評価が役割であり、防御はセキュリティグループやIAMなど各サービス側で実装する。Configは「逸脱を見つける目」として位置づける

Well-Architected の観点

• 運用上の優秀性: 構成変更の継続的な記録と評価により、環境の状態をコードとルールで管理し、変更追跡と監査を仕組み化できる
• セキュリティ: あるべき設定からの逸脱を自動検知・自動修復し、コンプライアンス状態を継続的に維持する中核となる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# マネージドルールを適用（S3バケットのサーバー側暗号化が有効かを評価）
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-bucket-sse-enabled",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
  }
}'

# 指定ルールの非準拠リソースを一覧
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-bucket-sse-enabled \
  --compliance-types NON_COMPLIANT

# 構成レコーダーの状態を確認
aws configservice describe-configuration-recorder-status