AWS Config は、AWS のリソースの設定を記録し続け、「いつ、どの設定が、どう変わったか」を後から調べられるようにするサービスです。使い始めるには、記録するリソースの範囲と保存先の S3 バケットを決めて記録を有効にし、必要に応じてルールを追加して、望ましくない設定を自動で見つけられるようにします。この記事では、記録の設定、変更履歴の調べ方、ルールによる準拠チェック、通知と自動修復までを順に説明します。
AWS Config のコンソールの画面や記録できるリソースの種類、マネージドルールの一覧は随時更新されます。ここでの説明は2026年10月現在の情報をもとにしているので、細かな項目名は目安として読み、公式ドキュメントで最新の内容を確認してください（2026年10月現在）。
AWS Config と CloudTrail の違い
よく混同されるのが CloudTrail です。2つは役割が違い、組み合わせて使います。
- CloudTrail：誰が、いつ、どの API を呼んだかという「操作」の記録です。
- AWS Config：その結果、リソースの設定がどういう状態になったかという「状態」の記録です。
例えば、セキュリティグループで SSH が全世界に開いていることに気付いたとき、Config の履歴を見れば「いつからその状態だったか」「変更前はどうだったか」が分かり、関連する CloudTrail のイベントから「誰の操作だったか」をたどれます。障害や事故の調査では、この2つを行き来することになります。
ステップ1：記録を有効にする
コンソールで AWS Config を開き、初回の設定を行います。決める項目は主に次の3つです。
- 記録するリソースの範囲：サポートされているすべてのリソースを記録するか、特定の種類だけを記録するかを選びます。IAM のようなグローバルなリソースは、複数のリージョンで重複して記録しないよう、1つのリージョンだけで記録するのが一般的です。
- 記録の頻度：変更のたびに記録する「継続的な記録」と、1日1回の記録を選べます。変更の多いリソースを日次にすると、記録の件数を抑えられます。
- 配信先：設定の履歴とスナップショットを保存する S3 バケットを指定します。変更の通知を受け取りたい場合は SNS トピックも指定できます。
AWS Config は、記録した設定項目の数やルールの評価回数に応じて料金がかかります。Auto Scaling で頻繁に台数が増減する環境や、ネットワークインターフェイスが頻繁に作られては消える環境では、記録件数が想定より増えることがあります。まず全体を記録して1〜2週間の件数を確認し、調査に不要なリソースの種類を除外するか日次の記録に切り替える、という調整の仕方が現実的です。金額は変わるため、料金ページで確認してください。
設定後は、CLI で記録が動いているかを確かめられます。
# 記録の設定を表示する
aws configservice describe-configuration-recorders
# 記録が動いているか、最後に成功した時刻を確認する
aws configservice describe-configuration-recorder-status状態の表示で記録中になっていて、直近の記録の成功時刻が更新されていれば問題ありません。失敗している場合は、AWS Config に割り当てた IAM ロールに S3 バケットへの書き込み権限があるか、バケットポリシーで拒否されていないかを確認します。
ステップ2：変更履歴を調べる
コンソールのリソースタイムライン
調べたいリソースを AWS Config のリソース一覧から開くと、設定の変化を時系列で表示するタイムラインが見られます。各時点の設定の差分と、その変更に関係する CloudTrail のイベントが並ぶため、「何が変わったか」と「誰が変えたか」を1つの画面で確認できます。
CLI で履歴を取り出す
調査の記録を残したい場合や、複数のリソースをまとめて確認したい場合は CLI が便利です。次は、特定のセキュリティグループの直近5件の設定履歴を取り出す例です。リソース ID は自分の環境の値に置き換えてください。
aws configservice get-resource-config-history \
--resource-type AWS::EC2::SecurityGroup \
--resource-id sg-0123456789abcdef0 \
--limit 5高度なクエリで現在の状態を一覧する
SQL に似た構文で、記録済みのリソースの現在の設定を検索することもできます。例えば、セキュリティグループの一覧と受信ルールを取り出すには次のようにします。
aws configservice select-resource-config \
--expression "SELECT resourceId, resourceName, configuration.ipPermissions WHERE resourceType = 'AWS::EC2::SecurityGroup'"高度なクエリが調べるのは現在の設定で、過去の履歴はタイムラインや履歴の取得で確認します。用途を分けて覚えておくと迷いません。
ステップ3：ルールで望ましくない設定を見つける
記録だけでは、問題のある設定に人が気付くまで放置されます。AWS Config ルールを追加すると、リソースの設定が変わるたび、または定期的に評価が行われ、ルールに合わないリソースが「非準拠」として一覧に出ます。
AWS が用意しているマネージドルールには、WordPress を AWS で動かす環境でも役立つものが多くあります。例を挙げます。
- SSH（22番ポート）が全世界に開いているセキュリティグループを見つけるルール
- 公開読み取りが許可された S3 バケットを見つけるルール
- 暗号化されていない EBS ボリュームを見つけるルール
- Multi-AZ が無効な RDS インスタンスを見つけるルール
- ルートユーザーに MFA が無い、CloudTrail が有効でない、といったアカウント設定のルール
コンソールでルール名を検索して追加するのが手軽ですが、CLI やコードで管理する場合は、ルールの識別子を指定して作成します。次は SSH の開放を検出するマネージドルールを追加する例です。
aws configservice put-config-rule --config-rule '{
"ConfigRuleName": "restricted-ssh",
"Source": { "Owner": "AWS", "SourceIdentifier": "INCOMING_SSH_DISABLED" },
"Scope": { "ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"] }
}'ルールの評価結果は、次のコマンドでまとめて確認できます。
aws configservice describe-compliance-by-config-rule業界の基準や AWS のベストプラクティスに沿ったルールをまとめて導入したい場合は、コンフォーマンスパックというテンプレートが使えます。ただし、多数のルールを一度に入れると評価回数が増え、非準拠の一覧も大量になって手が回らなくなりがちです。最初は自分の環境で事故につながりやすい設定に絞ったルールから始めるのが現実的です。
マネージドルールで表現できない独自の基準は、Lambda 関数や Guard というポリシー言語を使ったカスタムルールで定義できます。
ステップ4：通知と自動修復
非準拠になったら通知する
非準拠を検出したときに担当者へ知らせるには、EventBridge のルールで AWS Config のイベントを受け取り、SNS トピックに送る方法が一般的です。次は、ルールの評価結果が非準拠に変わったときだけ反応するイベントパターンの例です。
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"newEvaluationResult": {
"complianceType": ["NON_COMPLIANT"]
}
}
}設定の変更そのものを知りたい場合は、検出の種類を構成項目の変更のイベントにします。ただし、こちらは件数が多くなりやすいので、対象のリソースの種類を絞って使います。
自動修復は慎重に
AWS Config ルールには、Systems Manager の Automation ドキュメントを使って非準拠のリソースを自動で直す仕組み（修復アクション）があります。例えば、開いてはいけないポートの許可を自動で削除する、といった使い方です。
便利な反面、誤った条件で自動修復を有効にすると、本番の通信を遮断したり、正当な変更を勝手に戻したりします。最初は手動で修復アクションを実行して挙動を確かめ、影響範囲を理解してから自動化に進んでください。重要なリソースを変更する修復は、ステージング用のアカウントで試してから本番に適用するのが安全です。
複数アカウントを使う場合
AWS Organizations で複数のアカウントを管理している場合は、アグリゲーターを作ると、各アカウント・各リージョンの記録と準拠状況を1か所で確認できます。記録の有効化やルールの配布も組織単位で行えるため、アカウントが増えても設定のばらつきを抑えられます。
まとめ
- AWS Config はリソースの設定の「状態」を記録し、CloudTrail の「操作」の記録と組み合わせて調査に使います。
- 記録の範囲・頻度・配信先を決めて有効にし、CLI で記録が動いているかを確認します。件数に応じて料金がかかるため、不要な種類は除外します。
- リソースタイムラインや履歴の取得で過去の変化を、高度なクエリで現在の状態を調べます。
- マネージドルールで望ましくない設定を検出し、EventBridge と SNS で非準拠を通知します。
- 自動修復は便利ですが、手動で挙動を確かめてから段階的に有効にします。