AWS Configとは？設定変更の記録・ルール評価・料金の実額と導入判断をCLI設定例つきで解説【2026年時点】

AWS Config（エーダブリューエス コンフィグ）は、AWSアカウント内のリソースが「今どういう設定か」と「いつ誰の変更でどう変わったか」を継続的に記録し、あるべき状態からの逸脱を自動で検出する構成管理・コンプライアンス監査のサービスです。この記事では、変更が「設定項目（Configuration Item）」として残る仕組みと、操作ログを追うCloudTrailとの役割の違いを整理します。そのうえでルール・適合パック・アグリゲータ・自動修復を実装の粒度で分解し、記録頻度の選択で請求額がどう動くかを公式料金ページの実額で示すのが後半の主題です。AWS CLIでの設定例も載せ、導入判断まで扱います。

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

AWS Configは、EC2やセキュリティグループ、S3バケットの構成を時系列で記録し、社内基準やコンプライアンス要件に沿っているかをルールで評価するサービスです。記録の単位は設定項目で、変更が起きるたびにスナップショットが残り、S3への保存とSNSでの通知が走ります。CloudTrailが操作ログを担うのに対し、Configは構成の現在値と履歴を担います。

導入判断で効くのは3点です。第1に、記録対象を絞らないと設定項目の件数で費用が伸びること。第2に、記録頻度を継続（CONTINUOUS）と日次（DAILY）のどちらにするかで請求額が動くこと。第3に、真価が出るのは複数アカウント・複数リージョンを横断して統制したい場面だということです。AWS Configの公式料金ページの計算例では、EC2 100台から1日1,000件の設定項目が出る想定で、継続記録なら3.00ドル、日次記録なら1.20ドルになります（バージニア北部・2026年9月時点）。単一アカウントでリソースが少ないなら、必要なルールだけ有効化し記録範囲を限定して始めるのが無駄のない入り方でしょう。

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

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

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

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

レコーダーは2種類あります。自分で作成・停止する顧客管理レコーダーと、Security Hubなど他サービスが自動で作るサービスリンクレコーダーです。後者は記録スコープが内部（INTERNAL）の場合、配信チャネルに設定項目が届きません。S3に履歴が来ないと相談されたら、開発者ガイドの概要でどちらのレコーダーかを先に確認してください。

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

両者は監査で併用されますが、見ている対象は別物です。CloudTrailはAPI呼び出しを記録し、「誰が・いつ・どのAPIを・どのIPから呼んだか」という操作の事実を残します。Configが残すのは、その結果としてリソースが「今どういう設定値か」「過去からどう変化したか」という状態そのものです。S3バケットが公開設定に変わった事故なら、CloudTrailは「誰がPutBucketAclを実行したか」を、Configは「いつ無効化され今どうなっているか」を答えます。証跡（Trail）の設計やイベントセレクタの絞り込みは、AWS CloudTrailの監査ログの仕組みを解説した記事で確認してください。

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

Configの価値は、記録より「構成を基準に照らして自動評価し、直すところまで回す」部分にあります。評価結果を標準単位で束ねる集約層がAWS Security Hubで、Security Hub CSPMのコントロールは大半がConfigのサービスリンクルールで動きます。製品カテゴリで言えばConfigは、CSPM（クラウドセキュリティ態勢管理）の仕組みを整理した記事で言う検出エンジンをAWS単一クラウドで担う位置です。押さえたい5機能を分解します。

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

ルールは、記録済みリソースが条件を満たすかを評価し、外れたものへ非準拠（NON_COMPLIANT）のフラグを付ける仕組みです。マネージドルールなら「EBSが暗号化されているか」「S3バケットがパブリック公開でないか」を有効化するだけで検査できます。使えるルールはマネージドルールの公式一覧にリソース種別ごとに載っており、s3-bucket-public-read-prohibitedのような識別子で指定する形です。一覧に無い要件は、評価ロジックをLambda関数かGuard言語のポリシーで書くカスタムルールで補います。評価のきっかけは、構成変更を起点に走らせる方式と一定間隔で走らせる方式の2種類です。まずマネージドルールで足場を作り、独自基準だけをカスタムで足す順序が扱いやすいでしょう。

検出的評価とプロアクティブ評価の使い分けとデプロイ前検証の限界

評価タイミングとは別に、評価モードという軸があります。ルールの構成要素の公式解説では、デプロイ済みリソースを見る検出的評価（DETECTIVE）と、デプロイ前のプロパティ集合を評価するプロアクティブ評価（PROACTIVE）が定義され、作成時に片方または両方を指定する形です。後者を入れれば、IaCのパイプライン内で「このプロパティで作ったら非準拠になるか」を先に問い合わせられます。ただし限界が明記されています。プロアクティブルールは非準拠と判定したリソースを修復せず、デプロイを止めることもしません。ガードレールではなく事前診断です。実際に止めたいならSCPやCloudFormationフック側で拒否する仕組みを別に用意してください。なお両モードを有効にした場合、課金対象は検出的評価の分だけです。

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

ルールを1本ずつ足すと、設定がアカウントごとにばらつき、棚卸しも面倒になります。適合パックは、複数のルールと修復アクションを1つのYAMLテンプレートにまとめ、アカウントやOrganizations全体へ単一エンティティとしてデプロイできる仕組みです。適合パックの公式ドキュメントには定番のルール群がサンプルテンプレートとして載っており、配ればアカウント間で同じ統制がそろいます。組織全体へ配るのは管理アカウントか委任管理者アカウントからなので、OUの切り方を先に決めるのが順序です。その前提はAWS Organizationsのマルチアカウント設計を解説した記事で確認できます。準拠状況はパック単位で集計でき、基準ごとの準拠率を追えます。

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

複数アカウントでは、準拠状況を1つずつ見て回るのは現実的ではありません。アグリゲータ（Aggregator）は、複数アカウント・複数リージョンのConfigデータを1か所へ集約し、横断で構成とコンプライアンスを可視化する機能です。アグリゲータの公式ドキュメントでは個別アカウントを列挙する方式とOrganizations全体を対象にする方式が示され、後者なら新規アカウントの追加を自動で拾えます。どこに非準拠リソースが残るかを一覧できるため、監査アカウントへ集約する設計が定石になります。土台をまとめて整えるなら、アグリゲータを裏側で組み込んで統制を自動化するAWS Control Tower Landing Zoneの仕組みを解説した記事もあわせて確認してください。

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

検出して終わりでは運用は回りません。自動修復は、非準拠と判定したリソースへSystems Manager（SSM）のAutomationドキュメントを実行し、設定を直すところまで自動化します。修復アクションの公式ドキュメントには、AWS提供のマネージドAutomationドキュメントを使う方法と、独自のドキュメントを関連付ける方法の両方が載っています。「公開に変わったS3バケットのブロックパブリックアクセスを再度有効化する」といった対応を人手なしで走らせられる点が強みです。自動実行と手動承認のどちらも選べるため、影響の大きい変更は承認を挟み、機械的に直してよいものは全自動にできます。実行側であるSSMの権限設計は、AWS Systems Managerの機能と使いどころを整理した記事を土台にしてください。

AWS Configを有効化する手順｜CLIで記録範囲と記録頻度を設定する

Configはリージョン単位で有効化し、最初に「何をどこまで記録するか」と「どの頻度で記録するか」を決めます。この2つが料金と監査品質に直結します。コンソールのウィザードでも進められますが、複数アカウント・複数リージョンへ同じ設定を配るなら、AWS CLIでConfigを開始する公式手順のようにコマンドで定義を持つほうが再現できるはずです。

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

有効化時は、Configuration Recorderで「全サポートリソースを記録するか」「特定の型に絞るか」を選びます。記録対象リソースの公式ドキュメントでは、この選択がAPI・CLIでは3つの記録戦略になります。全種類を対象にするALL_SUPPORTED_RESOURCE_TYPES、指定した型だけのINCLUSION_BY_RESOURCE_TYPES、全種類から特定の型を除くEXCLUSION_BY_RESOURCE_TYPESの3つです。全記録は抜け漏れを防げる一方で費用が伸び、絞りすぎれば調査時に履歴が無い取りこぼしが起きます。

ただし記録対象外のリソースも完全な空白にはなりません。同ドキュメントには、記録していないリソースでも作成と削除のイベントだけは無償で捕捉すると明記されています。属性・関係・変更履歴は残らないため「中身は追えない」水準です。実務では、影響の大きいリソース（IAM・セキュリティグループ・S3・EBS）を確実に記録範囲へ入れ、監査要件に応じて広げる進め方が扱いやすいでしょう。記録先のS3バケットと通知先のSNSトピックは、有効化の時点で用意します。

CLIで記録頻度を日次と継続に混在させる設定ファイルの書き方と確認

記録頻度は継続（CONTINUOUS）と日次（DAILY）から選びます。継続は変更ごとに設定項目を配信し、日次は直近24時間の最終状態を、前回と差分がある場合だけ1件配信します。全体を日次に落としつつ、セキュリティグループとS3バケットだけ継続へ上書きする混在も可能です。put-configuration-recorderのCLIリファレンス（AWS CLI 2.36系・2026年9月時点）では、既定頻度をrecordingFrequency、型ごとの上書きをrecordingModeOverridesで指定します。上書きオブジェクトは1個までの制約があるため、継続に残す型は1つの配列にまとめます。

# 既定は日次記録、セキュリティ影響の大きい2型だけ継続記録に上書きする
$ cat recorder.json
{
  "name": "default",
  "roleARN": "arn:aws:iam::123456789012:role/config-role",
  "recordingMode": {
    "recordingFrequency": "DAILY",
    "recordingModeOverrides": [
      {
        "description": "keep security critical types continuous",
        "resourceTypes": ["AWS::EC2::SecurityGroup", "AWS::S3::Bucket"],
        "recordingFrequency": "CONTINUOUS"
      }
    ]
  }
}

$ cat recording-group.json
{
  "allSupported": false,
  "includeGlobalResourceTypes": false,
  "resourceTypes": [
    "AWS::EC2::SecurityGroup",
    "AWS::S3::Bucket",
    "AWS::EC2::Volume",
    "AWS::IAM::Role"
  ]
}

$ aws configservice put-configuration-recorder \
    --configuration-recorder file://recorder.json \
    --recording-group file://recording-group.json \
    --region ap-northeast-1

$ aws configservice start-configuration-recorder \
    --configuration-recorder-name default --region ap-northeast-1

$ aws configservice describe-configuration-recorder-status \
    --region ap-northeast-1 \
    --query "ConfigurationRecordersStatus[].[name,recording,lastStatus]"

最後のコマンドでrecordingがtrue、lastStatusがSUCCESSになれば記録が回っています。日次に落とせない型がある点には注意してください。CLIリファレンスの警告ではAWS::Config::ResourceCompliance、AWS::Config::ConformancePackCompliance、AWS::Config::ConfigurationRecorderは日次を指定できず、全種類記録の戦略では継続に固定されます。Firewall Managerを使う環境も継続記録が前提です。記録を止めるならレコーダーを削除せずレコーダーの停止と再開の公式手順に従うと、履歴を保ったまま課金を止められます。

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

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

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

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

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

2026年時点のConfigは、3つの数量に対して従量で課金される料金体系です。第1に記録された設定項目の件数、第2にConfigルールの評価回数、第3に適合パックの評価回数です。公式料金ページの例示では、ルール評価も適合パック評価も最初の10万件が1件0.001ドルで、10万1件から50万件、50万1件以上と単価が下がる3階梯になります（適合パックの価格は2022年9月14日発効）。配信先のS3、通知のSNS、カスタムルールのLambdaはConfigの料金に含まれず、標準料金が別に乗る点も見落としがちです。正確な単価はリージョンで異なるため、公式料金ページで確認してください。

継続記録と日次記録で請求額が変わる仕組みと公式の計算例の読み方

単価だけを見ると、継続記録が1件0.003ドル、日次記録が1件0.012ドルで、日次のほうが4倍高く見えます。ここで判断を間違えないでください。効くのは単価ではなく件数です。公式料金ページの計算例1は、バージニア北部でEC2 100台からそれぞれ1日10件、合計1,000件の設定項目が出る想定です。継続記録なら1,000件×0.003ドルで3.00ドル。日次記録ならリソースあたり1日1件へ丸められるため、100件×0.012ドルで1.20ドルになり、6割ほど下がります。

逆に、1日1回しか変わらないリソースを日次にすると、件数が減らないまま単価だけ4倍になって損をします。判断基準は変更頻度です。1日に何度も構成が動くリソース（オートスケーリング配下、頻繁なタグ更新が走るもの）は日次に寄せると効き、ほとんど動かないリソースは継続のままが安く済みます。なお料金ページの「periodic recording」、開発者ガイドの「Daily recording」、APIのDAILYは同じものです。

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

費用が跳ねる典型は、変更頻度の高いリソースを全記録の対象に含めたままにするケースです。オートスケーリングで頻繁に入れ替わるインスタンスや、大量のタグ変更が走るリソースは、そのたびに設定項目を生み続けます。抑えるには、監査価値が低く変更の激しい型を記録対象から外す、定期評価で足りるルールを変更起因にしない、といった見直しが効きます。

見落とされやすい無駄がもう1つあります。2022年2月以前にオンボードされたグローバルIAM型（AWS::IAM::User、AWS::IAM::Role、AWS::IAM::Group、AWS::IAM::Policy）は、2022年2月より前から提供されていたリージョンでしか記録できません。公式ドキュメントは、これらを記録していない環境ではiam-password-policyやaccess-keys-rotatedといった定期ルールを有効にしないよう推奨しています。記録が無くても定期ルールは評価を走らせ、その回数が課金対象になるからです。準拠状況は出ないのに請求だけ立ちます。「影響の大きいものは残し、揺れの大きい低価値リソースと空振りする定期ルールを削る」優先順位で調整してください。

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

ここでは玉虫色にせず判断を言い切ります。有効化は簡単ですが、記録範囲・記録頻度・ルールを設計せず「とりあえず全記録」で回すと、費用ばかり増えて誰も見ない置物になりがちです。

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

効果が明確に出るのは3条件のいずれかを満たす環境です。複数アカウントを運用し、アグリゲータで横断的に準拠状況をそろえたい場合。「ある時点で監査に合格した」ではなく「常に基準を満たし続けている」ことを機械的に示す証跡が求められる場合。非準拠を検出したら自動修復まで組み込みたい場合です。マルチアカウントの統制設計やクラウド移行後の運用体制をAWS上で組むなら、AWSを含むクラウドインフラ構築の相談窓口で妥当性を検討できます。

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

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

よくある質問

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

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

CloudTrailはAPI操作のログで、「誰が・いつ・どのAPIを呼んだか」という操作の事実を記録します。証跡の作成手順と料金の積み上がり方はCloudTrailの証跡設計と料金実額をまとめた記事にまとめています。AWS Configはリソース構成の記録で、「今どういう設定で、過去からどう変わったか」という状態と履歴を残します。別レイヤーのため、監査では両方を併用するのが実務の形です。

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

設定項目の件数、Configルールの評価回数、適合パックの評価回数という3つの数量に対する従量課金です。設定項目の単価は記録頻度で変わり、公式料金ページの例では継続記録が1件0.003ドル、日次記録が1件0.012ドルになっています。日次は単価が高い代わりに1リソース1日1件へ丸められるため、変更が多い環境では総額が下がります。単価はリージョンで異なる点に注意してください。

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

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

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

暗号化・公開設定・ログ有効化といった定番のチェックは、AWSが用意したマネージドルールをそのまま有効化するのが早道です。一覧に無い独自基準だけを、Lambda関数かGuard言語で書くカスタムルールで補います。デプロイ前に判定したい要件があれば、プロアクティブ評価に対応したルールかも確認してください。

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

アグリゲータを使い、複数アカウント・複数リージョンのConfigデータを監査用の1アカウントへ集約します。これでどのアカウントに非準拠リソースが残っているかを横断で一覧できる状態です。Organizations単位で集約する方式にすれば、新しく作られたアカウントも自動で対象に入ります。

関連記事

• AWS Control Tower Landing Zoneとは？構成要素とv4.0の変更点を解説：アグリゲータを裏側で使う上位の統制基盤
• AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：組織適合パックを配る前提のアカウント設計
• CSPMとは？設定ミス検出の仕組みとCNAPPとの違い・導入判断を実装視点で解説：設定ミス検出をマルチクラウド前提で見た全体像
• Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説：構成監査に対し脅威検知を担う相手
• AWS認定ソリューションアーキテクト アソシエイト（SAA-C03）とは？出題範囲・合格ラインと勉強の進め方：Configが問われる試験の全体像