AWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】

AWS Config（エーダブリューエス コンフィグ）は、AWSアカウント内のリソースが「今どういう設定になっているか」と「いつ誰の変更でどう変わったか」を継続的に記録し、あるべき状態からの逸脱を自動で検出する構成管理・コンプライアンス監査のサービスです。この記事では、変更の記録が「設定項目（Configuration Item）」として残る仕組みと、操作ログを追うCloudTrailとの役割の違いを整理します。マネージドルールとカスタムルール、適合パック、アグリゲータ、自動修復という5つの機能を実装の粒度で解説し、従量課金の内訳とコストが膨らむ勘所、そしてマルチアカウントで効く場面と単一アカウントでは過剰になる場面まで、導入判断を一次情報に基づいて示します。

まとめ：AWS Configの仕組み・機能・導入判断の要点

AWS Configは、EC2やセキュリティグループ、S3バケットといったリソースの構成を時系列で記録し、その状態が社内基準やコンプライアンス要件に沿っているかをルールで評価するサービスです。記録の単位は「設定項目」で、変更が起きるたびにスナップショットが残り、S3への保存とSNSでの通知が走ります。似た名前のCloudTrailが「誰がいつどのAPIを呼んだか」という操作ログを担うのに対し、Configは「リソースが今どう設定され、どう変わってきたか」という構成の現在値と履歴を担う、という分担を最初に押さえてください。

導入判断で効いてくるのは、記録対象を絞らないと設定項目の件数でコストが伸びること、そして真価が出るのは複数アカウント・複数リージョンを横断して統制したい場面だということです。単一アカウントで対象リソースも少ないなら、まず必要なマネージドルールだけを有効化し、記録範囲を限定して始めるのが無駄のない入り方になります。自社のアカウント構成が「効く条件」に当てはまるかは、本記事の導入判断の節で確認してください。

AWS Configとは何か（設定項目として記録する構成管理サービス）

Configを設計に落とすには、まず「何を記録し、どこに残すのか」と「操作ログを追うCloudTrailと何が違うのか」を切り分けます。ここが曖昧なまま有効化すると、CloudTrailと重複した監査を二重に組んでしまったり、逆にどちらも中途半端で「変更は追えるが構成は追えない」状態を招きます。

設定項目（Configuration Item）と設定履歴・リソース間の関係

Configの記録の最小単位は設定項目で、あるリソースのある時点における属性・タグ・他リソースとの関係・関連イベントをひとまとめにしたスナップショットです。リソースが作成・変更・削除されるたびに新しい設定項目が生成され、これを時系列に並べたものが設定履歴になります。記録を担うのがConfiguration Recorderで、生成された設定項目やスナップショットはS3バケットに保存され、変更検知時にはSNSトピックへ通知を送れます。単なる変更検知にとどまらず、たとえば「このセキュリティグループはどのEC2に紐づいているか」というリソース間の関係まで保持するため、影響範囲を構成のつながりからたどれるのが特徴です。

CloudTrailとの役割の違い（操作ログか、構成の現在値と履歴か）

ConfigとCloudTrailは監査でよく併用されますが、見ている対象は別物です。CloudTrailはAWS APIの呼び出しを記録するサービスで、「誰が・いつ・どのAPIを・どのIPから呼んだか」という操作の事実を残します。対してConfigが残すのは、その操作の結果としてリソースが「今どういう設定値になっているか」「過去からどう変化したか」という構成の状態そのものです。たとえばS3バケットが公開設定に変わった事故を調べるとき、CloudTrailは「誰がPutBucketAclを実行したか」を、Configは「バケットのブロックパブリックアクセスがいつ無効化され、今どうなっているか」を答えます。両者は競合ではなく、操作の追跡と構成の追跡という別レイヤーを補い合う関係です。

AWS Configの主要機能（ルール・適合パック・アグリゲータ・修復）

Configの価値は、記録そのものより「記録した構成を基準に照らして自動評価し、直すところまで回す」部分にあります。ここでは検討段階で理解しておきたい4つの機能を、使いどころとあわせて分解します。

マネージドルールとカスタムルールの使い分けと評価タイミングの選び方

ルールは、記録済みリソースが定めた条件を満たすかを評価し、外れたものに非準拠（NON_COMPLIANT）のフラグを付ける仕組みです。AWSがあらかじめ用意したマネージドルールは、「EBSボリュームが暗号化されているか」「S3バケットがパブリック公開になっていないか」といった定番のチェックをそのまま有効化できます。要件がマネージドルールに無い場合は、評価ロジックをLambda関数で書くか、Guard言語のポリシーで記述するカスタムルールを作ります。評価のきっかけは、リソースの構成変更を起点に走らせる方式と、一定間隔で定期的に走らせる方式の2種類です。まずはマネージドルールで足場を作り、独自の社内基準だけをカスタムルールで補うのが扱いやすい順序です。

適合パック（Conformance Packs）による統制のテンプレート化

ルールを1本ずつ手で足していくと、アカウントごとに設定がばらつき、棚卸しも面倒になります。適合パックは、複数のルールと自動修復のアクションを1つのYAMLテンプレートにまとめ、アカウントやOrganizations全体へ単一エンティティとしてデプロイできる仕組みです。たとえば特定のセキュリティ基準に対応した定番のルール群がパックとして提供されており、これを配ればアカウント間で同じ統制をそろえられます。準拠状況もパック単位で集計できるため、「この基準に対して全体で何%が準拠しているか」をダッシュボードで追えるのが利点です。

アグリゲータによる複数アカウント・複数リージョンの横断集約と可視化

組織で複数のAWSアカウントを運用していると、準拠状況を1アカウントずつ見て回るのは現実的ではありません。アグリゲータ（Aggregator）は、複数アカウント・複数リージョンのConfigデータを1か所のアカウントへ集約し、横断で構成とコンプライアンスを可視化する機能です。どのアカウントのどのリージョンに非準拠リソースが残っているかを一覧で把握できるため、統制の中心となる監査アカウントに集約する設計が定石になります。マルチアカウントの土台をまとめて整えたい場合は、Configアグリゲータを裏側で組み込んで統制を自動化するAWS Control Tower Landing Zoneの仕組みを解説した記事もあわせて確認してください。

自動修復（Remediation）とSSM Automationの連携

検出して終わりでは運用は回りません。Configの自動修復は、非準拠と判定したリソースに対して、Systems Manager（SSM）のAutomationドキュメントを実行して設定を直すところまでを自動化します。たとえば「公開に変わったS3バケットのブロックパブリックアクセスを再度有効化する」「暗号化されていないボリュームにフラグを立てて是正フローへ回す」といった対応を、人手を介さずに走らせられる点が強みです。修復は自動実行と手動承認のどちらも選べるため、影響の大きい変更は承認を挟み、機械的に直してよいものは全自動にする、といった濃淡を付けられます。

AWS Configの始め方｜有効化の手順と記録範囲の設計方針

Configはリージョン単位で有効化し、最初に「何をどこまで記録するか」を決めます。この記録範囲の設計が、後述する料金にも監査品質にも直結するため、勢いで全記録を有効にする前に一度立ち止まる価値があります。

記録対象リソースと記録方式の設計（全リソース記録か対象を絞るか）

有効化の際は、Configuration Recorderで「アカウント内の全サポートリソースを記録するか」「特定のリソースタイプだけに絞るか」を選びます。全記録は監査の抜け漏れを防げる一方、記録される設定項目が増えるほど費用も伸びる関係です。逆に対象を絞りすぎると、いざ調査というときに履歴が無い、という取りこぼしが起きます。実務では、まずセキュリティ影響の大きいリソース（IAM・セキュリティグループ・S3・EBSなど）を確実に記録範囲へ入れ、そこから監査要件に応じて広げる進め方が扱いやすいです。記録先のS3バケットと、通知を受けるSNSトピックは有効化の時点で用意しておきます。

マネージドルールを適用して非準拠リソースを可視化する最初の一手

記録を始めたら、次はルールで「あるべき状態」を定義します。最初から独自ルールを書く必要はなく、暗号化・公開設定・ログ有効化といった定番のマネージドルールを数本適用するだけで、非準拠リソースの可視化が始まります。ここで検出される構成上の穴は、脅威の兆候そのものではなく「攻撃を受けやすい状態になっているか」を示すものです。実際の脅威検知は役割が分かれており、通信やAPIの異常から脅威を見つけるAmazon GuardDutyの仕組みを解説した記事と、構成の逸脱を追うConfigを組み合わせると、「危ない設定になっていないか」と「実際に攻撃されていないか」の両面を押さえられます。

AWS Configの料金の考え方（従量課金の内訳とコスト増の勘所）

Configで判断を分けるのは、機能の理解よりも費用の見立てです。従量課金のため、記録範囲の設計を誤ると想定外の請求につながります。課金がどの数量に連動するかを先に理解しておきましょう。

料金が連動する3要素（設定項目・ルール評価・適合パック評価）

2026年時点のConfigは、大きく3つの数量に対して従量で課金される料金体系です。第1に、記録された設定項目の件数で、リソースの変更が多いほど生成される設定項目が増えて費用も伸びます。第2に、Configルールの評価回数で、ルール数と評価頻度（変更起因か定期か）に比例します。第3に、適合パックの評価回数です。料金の桁は、リソースの多さそのものより「どれだけ頻繁に構成が変わるか」で動く、という感覚を持っておくと見積もりがぶれません。正確な単価はリージョンで異なるため、最新の公式料金ページで確認してください。

コストが膨らむ典型パターンと記録範囲の見直しによる費用の抑制

費用が跳ねる典型は、変更頻度の高いリソースを全記録の対象に含めたままにするケースです。オートスケーリングで頻繁に入れ替わるインスタンスや、大量のタグ変更が走るリソースは、そのたびに設定項目を生み続けます。抑えるには、監査上の価値が低く変更の激しいリソースタイプを記録対象から外す、定期評価で足りるルールを変更起因評価にしない、といった見直しが効きます。料金を下げる目的で記録を切りすぎると監査の抜けを招くため、「セキュリティ影響の大きいものは残し、揺れの大きい低価値リソースを削る」という優先順位で調整するのが判断の軸です。

AWS Configを採用すべき場面と見送る場面（導入判断）

ここでは玉虫色にせず判断を言い切ります。Configは有効化自体は簡単ですが、記録範囲とルールを設計せずに「とりあえず全記録」で回すと、費用ばかり増えて誰も準拠状況を見ない置物になりがちです。自社のアカウント構成を条件に当てはめて見極めてください。

導入効果が明確に出る条件（マルチアカウント・継続的な監査要件）

効果が明確に出るのは、次の条件を満たす環境です。まず、複数のAWSアカウントを運用し、アグリゲータで横断的に準拠状況をそろえたいケースが挙げられます。次に、社内規程や外部基準に対する継続的なコンプライアンス証跡が求められ、「ある時点で監査に合格した」ではなく「常に基準を満たし続けている」ことを機械的に示す必要がある場合です。さらに、非準拠を検出したら自動修復で直すところまで運用に組み込みたいなら、ConfigとSSMの連携が土台になります。こうしたマルチアカウントの統制設計やクラウド移行後の運用体制をAWS上で組むなら、AWSを含むクラウドインフラ構築の相談窓口で構成の妥当性を検討できます。

単一アカウント・小規模環境で過剰投資になり見送るべき典型場面

逆に見送り、あるいは最小構成に留めるべきなのは、単一アカウントでリソースも少なく、監査要件も社内の軽い確認にとどまる場合です。ここで全リソース記録を有効にすると、得られる価値に対して設定項目とルール評価の費用が見合いません。この段階なら、まず本当に見張りたいリソース（S3の公開設定、IAMの過剰権限、暗号化の有無など）に絞ってマネージドルールを数本だけ有効化し、記録範囲も限定するのが妥当です。将来アカウントが増え、統制を横断でそろえる必要が出た時点で、アグリゲータと適合パックへ段階的に広げれば十分です。「最初から全部」ではなく「効く範囲から始めて必要に応じて広げる」順序が、費用と監査品質のバランスを取ります。

よくある質問

AWS Configの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

AWS ConfigとCloudTrailは何が違いますか？

CloudTrailはAPI操作のログで、「誰が・いつ・どのAPIを呼んだか」という操作の事実を記録します。AWS Configはリソース構成の記録で、「今どういう設定になっていて、過去からどう変わったか」という状態と履歴を残します。操作の追跡と構成の追跡という別レイヤーのため、監査では両方を併用し、変更の実行者と、その結果の構成状態の両面を押さえるのが実務の形です。

AWS Configの料金はどのように決まりますか？

2026年時点では、記録された設定項目の件数、Configルールの評価回数、適合パックの評価回数という3つの数量に対する従量課金です。リソースの多さより構成変更の頻度で費用が動くため、変更の激しい低価値リソースを記録対象から外すとコストを抑えられます。単価はリージョンで異なるので、最新の公式料金ページで確認してください。

AWS Configはセキュリティ対策になりますか？

Configは「危ない設定になっていないか」を継続的に検出する構成監査の役割で、攻撃そのものを検知するわけではありません。実際の脅威検知はGuardDutyなど別サービスが担うため、両者を組み合わせて「攻撃を受けやすい構成の是正」と「実際の攻撃の検知」を分担させる設計が有効です。Configは非準拠リソースの自動修復まで回せる点が、セキュリティ運用での強みになります。

マネージドルールとカスタムルールはどう選びますか？

暗号化・公開設定・ログ有効化といった定番のチェックは、AWSが用意したマネージドルールをそのまま有効化するのが早道です。マネージドルールに無い独自の社内基準だけを、Lambda関数かGuard言語で書くカスタムルールで補います。まずマネージドルールで足場を作り、必要な差分だけをカスタムで足す順序にすると、運用の手間を抑えられます。

複数のAWSアカウントの準拠状況をまとめて見るには？

アグリゲータを使い、複数アカウント・複数リージョンのConfigデータを監査用の1アカウントへ集約します。これでどのアカウントに非準拠リソースが残っているかを横断で一覧できます。統制をアカウント間でそろえるには、複数のルールと修復を1つのYAMLにまとめた適合パックを全体へデプロイする方式が扱いやすいです。

関連記事

• AWS Control Tower Landing Zone v4.0とは何か？最新バージョンの概要とメリットを解説：Configのアグリゲータを裏側で使い、マルチアカウントの統制を自動化する上位の仕組み
• Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説：構成監査を担うConfigに対し、実際の脅威検知を担う役割分担の相手
• AWS認定ソリューションアーキテクト（SAA）とは？クラウドエンジニア必須のAWS資格を解説：Configが運用管理サービスとして問われる資格試験の全体像