AWS Config入門 リソース設定の変更追跡とコンプライアンス自動チェックの実践ガイド

「EC2のセキュリティグループを誰かが変更したらしいけど、いつ、誰が、何を変えたのかわからない」「コンプライアンス監査で設定状態を聞かれたが、手作業で確認するしかない」——クラウド環境でこうした悩みを抱えるインフラエンジニアは少なくありません。

オンプレミス環境では、構成管理台帳をExcelで手動更新したり、変更管理票をワークフローで回したりするのが一般的でした。しかしクラウドでは、マネジメントコンソールやCLI、IaCツールから誰でもすぐにリソースを変更できるため、管理台帳方式では追いつかなくなります。

この記事では、AWSリソースの設定変更を自動追跡し、コンプライアンスチェックも自動化できるAWS Configについて、オンプレの構成管理との比較を交えながら実践的に解説します。初期設定の手順からConfigルールの作り方、コスト管理、Security Hubとの連携まで一通りカバーしますので、運用改善にぜひ活用してください。

AWS Configとは？オンプレの構成管理との違い

AWS Configは、AWSアカウント内のリソース設定を継続的に記録・評価するマネージドサービスです。「いま何がどう設定されているか」「過去にどう変わったか」「ルールに準拠しているか」を自動的に追跡してくれます。

オンプレ環境の構成管理と比較すると、位置づけが理解しやすくなります。

オンプレで「誰がサーバーの設定を変えた？」と調べるには、変更管理票をひっくり返すか、サーバーにログインしてログを漁るしかありませんでした。AWS Configなら、いつ・誰が・何を変えたかが自動的に記録されているので、調査にかかる時間が桁違いに短くなります。

AWS Configで追跡できるリソース

AWS Configが記録対象とする主なリソースは以下の通りです。

・Amazon EC2: インスタンス設定、セキュリティグループ、EBSボリューム
・Amazon S3: バケットポリシー、暗号化設定、パブリックアクセスブロック
・Amazon RDS: DBインスタンスの設定、バックアップ設定、暗号化
・Amazon VPC: サブネット、ルートテーブル、ネットワークACL
・AWS IAM: ユーザー、ロール、ポリシーの設定変更
・AWS Lambda: 関数設定、実行ロール、環境変数
・Amazon ELB: ロードバランサー設定、リスナー、ターゲットグループ

2026年4月時点で200種類以上のリソースタイプに対応しています。新しいAWSサービスにも順次対応が追加されるため、主要なリソースはほぼ自動追跡できると考えて問題ありません。

AWS Configの初期設定手順

1. Configレコーダーの有効化（CLI）

まずはConfigレコーダーを作成して、リソースの記録を開始します。記録データはS3バケットに保存されるため、保存先バケットも指定します。

# 記録用S3バケットを作成（東京リージョン）
aws s3 mb s3://my-config-bucket-20260410 \
  --region ap-northeast-1

# Configレコーダーの作成（全リソースタイプを記録）
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam::012345678901:role/ConfigRole \
  --recording-group allSupported=true,includeGlobalResourceTypes=true

# 配信チャネルの設定（記録先S3バケット）
aws configservice put-delivery-channel \
  --delivery-channel name=default,s3BucketName=my-config-bucket-20260410

# レコーダーを開始
aws configservice start-configuration-recorder \
  --configuration-recorder-name default

includeGlobalResourceTypes=trueを指定すると、IAMユーザーやIAMロールなどグローバルリソースも記録対象に含まれます。これを忘れると、IAMの変更履歴が残らないので注意してください。

2. マネジメントコンソールからの有効化

CLIに慣れていない場合は、コンソールから数ステップで有効化できます。

・AWSマネジメントコンソールで「Config」を検索して開く
・「今すぐ始める」をクリック
・記録するリソースタイプを選択（「すべてのリソース」推奨）
・記録先のS3バケットを指定（新規作成または既存バケット）
・SNS通知の設定（任意）
・IAMロールの作成を確認して「確認」をクリック

有効化すると、数分以内にリソースの初期スナップショットが取得されます。

3. 設定状態の確認

# レコーダーの状態確認
aws configservice describe-configuration-recorder-status \
  --region ap-northeast-1

# 結果例：
# "recording": true  → 正常に記録中
# "lastStatus": "SUCCESS"  → 最後の配信が成功

Configルールでコンプライアンスを自動チェックする

AWS Configの最大の価値はConfigルールにあります。リソースの設定が社内ポリシーやセキュリティ基準に準拠しているかを、自動的かつ継続的にチェックしてくれる機能です。

オンプレで言えば、「すべてのサーバーにウイルス対策ソフトが入っているか」「ファイアウォールのポート管理は適切か」を、監査のたびに人手で確認していた作業を自動化するイメージです。

1. マネージドルール（AWS提供）

AWSが用意している300以上のマネージドルールから選ぶだけで、すぐにチェックを開始できます。よく使うルールをいくつか紹介します。

2. マネージドルールの追加（CLI）

# S3パブリックアクセス禁止ルールを追加
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "s3-bucket-public-read-prohibited",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
    },
    "Scope": {
      "ComplianceResourceTypes": ["AWS::S3::Bucket"]
    }
  }'

# EBSボリューム暗号化チェックルールを追加
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "encrypted-volumes",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "ENCRYPTED_VOLUMES"
    }
  }'

3. カスタムルール（Lambda連携）

マネージドルールでカバーできない社内独自のポリシーがある場合は、AWS Lambda関数を使ってカスタムルールを作成できます。たとえば「すべてのEC2インスタンスに特定のタグが付いているか」「特定のAMIからのみ起動されているか」といった独自チェックが可能です。

# カスタムルールの作成例
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "ec2-required-tags-check",
    "Source": {
      "Owner": "CUSTOM_LAMBDA",
      "SourceIdentifier": "arn:aws:lambda:ap-northeast-1:012345678901:function:CheckEC2Tags",
      "SourceDetails": [{
        "EventSource": "aws.config",
        "MessageType": "ConfigurationItemChangeNotification"
      }]
    },
    "Scope": {
      "ComplianceResourceTypes": ["AWS::EC2::Instance"]
    },
    "InputParameters": "{\"requiredTagKey\": \"Environment\"}"
  }'

カスタムルールを一から書くのが大変な場合は、AWS Config RDK（Rule Development Kit）を使うとテンプレートから開発できます。

リソースの変更履歴を確認する

AWS Configのもう一つの重要な機能が、リソースの設定タイムラインです。「いつ、誰が、何を変えたか」を時系列で確認できます。

CLIでの履歴確認

# 特定のセキュリティグループの設定変更履歴を取得
aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup \
  --resource-id sg-0123456789abcdef0 \
  --limit 5

# 特定のS3バケットの現在の設定を確認
aws configservice get-resource-config-history \
  --resource-type AWS::S3::Bucket \
  --resource-id my-important-bucket \
  --limit 1

出力には、変更前後の設定内容がJSON形式で含まれます。「セキュリティグループに意図しないインバウンドルールが追加された」といったインシデント調査では、CloudTrailの「誰がAPIを叩いたか」と組み合わせることで、原因を素早く特定できます。

コンソールでの確認

マネジメントコンソールでは、リソースごとの設定タイムラインがビジュアルに表示されます。各時点の設定スナップショットを比較できるため、「いつから設定がおかしくなったか」を直感的に把握できます。

・Configコンソールの「リソース」から対象リソースを検索
・リソースIDをクリックして詳細画面を開く
・「設定タイムライン」タブで変更履歴を確認

Security Hubとの連携

AWS ConfigはAWS Security Hubと連携することで、コンプライアンス違反の検出結果をSecurity Hubのダッシュボードに集約できます。Security Hubのセキュリティ基準（CIS Benchmark、AWS基礎セキュリティのベストプラクティスなど）は、内部でConfigルールを使って評価を実行しています。

つまり、Security Hubを有効化するには、まずAWS Configが有効になっている必要があります。両者の関係は以下の通りです。

・AWS Config: リソースの設定記録とルール評価を実行する「エンジン」
・Security Hub: Configの評価結果を他のセキュリティサービスと統合して「ダッシュボード」に表示

すでにSecurity Hubを使っている場合、Configのルール評価結果は自動的にSecurity Hubの検出結果として表示されます。まだSecurity Hubを導入していない場合は、AWS Security Hub入門 セキュリティ運用を一元管理する実践ガイドを参照してください。

コンプライアンス違反の自動通知

Configルールで検出された違反を、SNSやEventBridgeで自動通知する仕組みを作っておくと、問題の早期発見につながります。

SNS通知の設定

# SNSトピックの作成
aws sns create-topic \
  --name config-compliance-alerts \
  --region ap-northeast-1

# メール通知のサブスクリプション追加
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:012345678901:config-compliance-alerts \
  --protocol email \
  --notification-endpoint admin@example.com

EventBridgeルールでの自動通知

# コンプライアンス変更イベントをキャッチするEventBridgeルール
aws events put-rule \
  --name "Config-NonCompliant-Alert" \
  --event-pattern '{
    "source": ["aws.config"],
    "detail-type": ["Config Rules Compliance Change"],
    "detail": {
      "messageType": ["ComplianceChangeNotification"],
      "newEvaluationResult": {
        "complianceType": ["NON_COMPLIANT"]
      }
    }
  }' \
  --state ENABLED

この設定により、いずれかのConfigルールで「NON_COMPLIANT（非準拠）」が検出されたタイミングで、自動的に通知が飛びます。オンプレで監査チームが定期巡回していた作業を、リアルタイムの自動監視に置き換えられるわけです。

料金の仕組み

AWS Configの料金は、記録する設定項目数とルール評価の回数で決まります（2026年4月時点、東京リージョン）。

小規模環境（EC2数台、S3数バケット、RDS数台程度）で基本的なマネージドルールを10個ほど有効にした場合、月額$5〜$15程度に収まることがほとんどです。ただし、リソース数が多い大規模環境では、記録対象のリソースタイプを絞ることでコストを抑えられます。

# 特定のリソースタイプのみ記録する設定
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam::012345678901:role/ConfigRole \
  --recording-group '{
    "allSupported": false,
    "resourceTypes": [
      "AWS::EC2::Instance",
      "AWS::EC2::SecurityGroup",
      "AWS::S3::Bucket",
      "AWS::IAM::User",
      "AWS::IAM::Role"
    ]
  }'

よくあるトラブルと対処法

Configルールが「評価中」のまま進まない

・Configレコーダーが正常に動作しているかdescribe-configuration-recorder-statusで確認する
・IAMロールの権限不足が原因のケースが多い。ConfigのサービスロールにAWS管理ポリシーAWS_ConfigRoleがアタッチされているか確認する
・カスタムルールの場合、Lambda関数の実行権限やタイムアウト設定を確認する

S3への配信が失敗する

・配信先S3バケットのバケットポリシーで、Configサービスからの書き込みが許可されているか確認する
・バケットが別リージョンにある場合は、クロスリージョン配信の設定が必要
・S3バケットの暗号化設定（KMS）を使っている場合、ConfigのIAMロールにKMSキーの使用権限があるか確認する

コストが想定以上に膨らんだ

・allSupported=trueにすると全リソースタイプが記録対象になるため、不要なリソースタイプを除外する
・頻繁に変更されるリソース（Lambda関数の環境変数など）が大量にあると記録数が増える
・使っていないConfigルールは無効化して、不要な評価回数を減らす

本記事のまとめ

AWS Configは、クラウド環境における「構成管理の基盤」です。リソースの設定変更を自動追跡し、ルール違反をリアルタイムに検出することで、オンプレ時代に手作業で行っていた構成管理と監査の負荷を大幅に削減できます。Security HubやCloudTrailと組み合わせれば、「誰が・いつ・何を変えて・それがルールに準拠しているか」を一気通貫で把握できる体制が整います。まずはConfigレコーダーを有効化して、基本的なマネージドルールからチェックを始めてみてください。

AWSのセキュリティ全体を俯瞰したい方は、AWS Security Hub入門 セキュリティ運用を一元管理する実践ガイドもあわせてご覧ください。また、暗号化やキー管理についてはAWS KMS入門 S3データ暗号化とキー管理の実践ガイドで詳しく解説しています。

Linuxサーバーの構成管理や運用ノウハウについては、姉妹サイトLinuxMaster.JPで詳しく解説しています。また、セキュリティ全般の基礎知識はセキュリティマスターズ.TOKYOも参考にしてください。