AWS Audit Manager 終了 Config Conformance Packs 移行設計ガイド

1. この記事について

2026年4月30日、AWS Audit Manager はメンテナンスモードへ移行した。「今すぐ使えなくなる」わけではないが、
新規アカウントでのセットアップが停止され、新機能の追加・新フレームワーク対応・新リージョン展開が
すべて凍結された。SOC2・PCI DSS・HIPAA の Assessment を現在 Audit Manager で運用している監査・
コンプライアンス・GRC 担当にとって、「いつ・何を・どう移行するか」を判断しなければならない
転換点が来た。

本記事は、その移行判断を助けるための設計ガイドだ。Terraform 実装の詳細（Config Recorder の HCL
コード・SSM Automation の設定・Lambda Remediation の定義）は扱わない。それらは既存の実装ハンズオン
記事に委ねる。本記事が焦点を当てるのは「Audit Manager で何を運用していたか」を棚卸しし、
「Config Conformance Packs で何が代替でき、何が代替できないか」を正確に見極め、「どの順序で
移行を進めるか」を設計するプロセスだ。特に SOC2・GDPR・ISO 27001 については Conformance Pack
に対応テンプレートが存在しない点を正確に理解したうえで補完戦略を立てることが重要になる。

1-1. 本記事のゴール

この記事を読み終えた時点で、読者は次の判断・操作ができる状態になる。

• 現行 Audit Manager Assessment を棚卸しし、対応する Config Conformance Pack テンプレートを
  選定できる。PCI DSS・HIPAA・NIST 等の対応テンプレートを選び、SOC2・GDPR・ISO 27001 の
  ギャップを仕分けられる
• SOC2・GDPR・ISO 27001 対応の Conformance Pack テンプレートが存在しないことを理解し、
  Vanta・Drata などのサードパーティ製 GRC ツール併用による補完戦略を立てられる
• Audit Manager の4データソース証跡（サービス API・Security Hub・CloudTrail・Config Rules）と
  Config の CI（Configuration Item）ベース証跡の違いを理解し、移行後の監査証跡収集体制を
  設計できる
• 監査レポートの代替手段として Config Advanced Query（CSV/JSON エクスポート）・
  get-resource-config-history API（履歴）・Athena＋QuickSight（複数リソース横断）の
  3経路を使い分けられる
• Evidence Finder を有効化して既存証跡を CloudTrail data lake に退避し、Audit Manager を
  安全に無効化できる。無効化後も既存証跡が収集日から2年間保持されることを把握し、
  監査対応に空白を生じさせない計画を立てられる
• remediation（自動修復）という移行先の新機能を理解し、「検出だけ」から
  「検出＋自動修復」への進化を組み込んだ移行後のコンプライアンス体制を設計できる

1-2. 読者像

本記事が想定する読者は、AWS Audit Manager で SOC2・PCI DSS・HIPAA 等の Assessment を運用
してきた監査対応・コンプライアンス・GRC（Governance, Risk, Compliance）担当だ。移行の意思
決定を迫られている運用責任者、または上位の意思決定者に対して移行提案を行う統制担当者も
対象に含む。

「AWS が何かを変えた」という情報は届いているが、「具体的に何が変わるのか」「自組織の
Assessment への影響は何か」「移行しない場合のリスクは何か」を整理できていない方に向けて
書いた。Terraform 実装の詳細（HCL コード・SSM Automation・Lambda Remediation）よりも、
「移行可否の判断軸・フレームワークごとのギャップの所在・証跡の引き継ぎ方」を優先する
読者像だ。

実装の詳細（Config Recorder の設定・Conformance Pack の Terraform デプロイ・remediation
アクション定義）に進みたい技術担当は、本記事末尾にある実装ハンズオン記事を参照してほしい。
本記事はその「前段の移行設計」を扱う位置づけだ。

AWS の監査・コンプライアンスツール全般の基礎知識が必要な読者は、先に
セキュリティ運用の基礎
で Audit Manager の統合入門を押さえておくことを推奨する。

1-3. なぜ今これを書くか

2026年4月30日のメンテナンスモード移行は「今すぐ使えなくなる」変化ではない。既存顧客は
単一アカウントで Assessment を継続作成でき、コード修正・既存フレームワークのデータソース
マッピング維持も続く。AWS 公式 FAQ が「Is the service being shutdown? No.」と明言しており、
「Audit Manager 終了」という表現は正確でない。

しかし制約は現実だ。新機能追加・新フレームワーク対応・新リージョン対応はすべて停止した。
新しい規制要件（DORA・EU AI Act 等）への追従・組織拡大（新規 AWS アカウントや新リージョン
への展開）・マルチリージョンでの Assessment 展開、これらのいずれかで Audit Manager の制約
に直面する。追われてから移行を始めると、証跡の引き継ぎで時間的余裕がなくなる。

AWS 自身が Config Conformance Packs を移行先として公式推奨し、フレームワーク対応表・
機能比較表・証跡エクスポート手順まで公式ドキュメント（FAQ・User Guide）に整備している。
移行計画を今始めることで、制約に追われず計画的な移行設計が可能になる。

移行の前提として認識しておくべき重要事項がある。Config Conformance Pack は「Audit Manager
フレームワークの直接の代替ではない」と AWS 公式 FAQ が明言している。Conformance Pack
テンプレートは技術的 Core Controls（Config Rule で評価可能なもの）のみを含む。
「組織がセキュリティポリシーを文書化したか」を検証するような Controls は対象外だ。
特に SOC2・GDPR については対応テンプレートが存在せず、サードパーティ GRC ツールとの
併用が前提になる。この「ギャップの正確な理解」こそが、本記事が最も力を入れるテーマだ。

なお本記事は、すでに公開済みの実装ハンズオン記事（Config Recorder・Conformance Pack・
Auto Remediation の Terraform 実装）と対をなす移行設計ガイドだ。Terraform 実装の詳細は
そちらへ委譲し、本記事は移行判断・設計・証跡移行に集中する。

1-4. 移行を先送りするリスク

メンテナンスモード移行直後は「今すぐ使えなくなるわけではない」として先送りになりやすい。
しかし先送りには具体的なリスクが伴う。

第一に、証跡の退避タイミングを逃すリスクだ。Evidence Finder を使って証跡を CloudTrail
data lake にエクスポートする作業は、Audit Manager を無効化する前に完了しなければならない。
無効化後に「やっぱり証跡が必要だった」という事態は取り返しがつかない。2年間の保持期間が
あるとはいえ、退避作業の計画・実施には時間がかかる。

第二に、新規組織への Audit Manager 追加ができない制約だ。M&A や組織拡大で新規 AWS
アカウントを Organizations に追加した場合、その新規アカウントには Audit Manager を
展開できない。移行先の Conformance Pack を先に準備しておかないと、新規アカウントの
コンプライアンスカバレッジに空白が生じる。

第三に、移行作業の工数の読み違いだ。Assessment 棚卸し・Pack 選定・デプロイ・監査
レポート代替手段の確立・ギャップ補完手段の導入まで含めると、規模によっては数カ月の
プロジェクトになる。「制約に直面してから始める」では間に合わない可能性がある。

Config Conformance Pack の Terraform 実装ハンズオンを見る

2. Audit Manager と Config Conformance Packs の機能比較

2-1. 移行判断の前提 — メンテナンスモードの正確な理解

「Audit Manager が終了した」という表現が一人歩きしているが、正確ではない。AWS 公式 FAQ は
「Is the service being shutdown? No.」と明言している。2026年4月30日に起きたのは、
新規利用の停止と機能拡張の凍結であり、既存利用者が即座に影響を受けるわけではない。

メンテナンスモード移行で具体的に何が変わったかを整理する。

継続されること（既存顧客への影響なし）

• 既存 Assessment の継続実行・新規 Assessment の作成（単一アカウント内）
• 既存フレームワークのデータソースマッピングの維持
• コード修正・バグ修正（セキュリティ修正含む）
• 既存証跡の保持（無効化しない限り収集日から2年間）

停止されること（新規拡張が不可）

• 新規アカウントでの Audit Manager セットアップ
• 新規 AWS リージョンへの展開
• AWS Organizations への新規追加（新規 OU・新規メンバーアカウント）
• 新機能の追加
• 新フレームワーク・新コントロールの追加

この制約の影響は組織の成長フェーズによって大きく異なる。単一アカウントで固定リージョンを
使用し、現行フレームワークで十分な組織は、しばらくの間 Audit Manager を継続利用できる。
しかし組織拡大・マルチリージョン化・新規制対応を予定している場合、制約に直面するのは
時間の問題だ。

また、移行の計画期間も考慮に入れる必要がある。既存の Assessment を棚卸しし、対応する
Conformance Pack を選定・デプロイし、Evidence Finder で証跡を退避し、監査レポート代替手段
を確立するまでには、規模によって数週間から数カ月かかる。移行を「いつでもできる」と先送り
すると、制約に追われる時点で移行期間が不足する事態になりかねない。

2-2. 証跡 (evidence) 収集モデルの違い

Audit Manager と Config Conformance Pack の最も重要な違いは、何を「証跡（evidence）」として
収集するかだ。この違いは監査対応の網羅性とワークフローに直接影響するため、移行判断の
前に正確に理解しておく必要がある。

Audit Manager の証跡モデル — 4データソース

Audit Manager は以下の4つのデータソースから証跡を収集する。

• サービス API 呼び出し: AWS サービスへの API コールを記録。誰が・いつ・何を操作したかの
  操作ログが証跡になる
• Security Hub コントロール: Security Hub が評価した各コントロールの findings を
  直接取り込む。NIST・PCI DSS・CIS 等の標準に対する評価結果が証跡になる
• CloudTrail イベント: API 活動ログ全般。操作の証跡として監査人が求めるログを
  そのまま収集できる
• Config Rules: 各 Config Rule の評価結果を証跡として記録する

この4データソースの組み合わせにより、Audit Manager は「技術的設定状態の検出」だけでなく
「操作履歴・セキュリティ評価・API 活動」まで含む広範な証跡を提供できる。

Config Conformance Pack の証跡モデル — CI のみ

Config Conformance Pack が証跡として記録するのは、Configuration Item（CI）のみだ。
CI はリソースの設定状態のスナップショットであり、Config が各リソースの変更を検知した
際に記録される。

CloudTrail のイベントログ、Security Hub の findings、AWS サービスへの API 呼び出し履歴は
Config Conformance Pack の証跡には含まれない。「誰がいつ設定変更を行ったか」の操作履歴は
CloudTrail と別途連携しなければ証跡として提示できない。

この差は「証跡の網羅性」において Audit Manager が優位であることを意味するが、
逆に Config の CI ベース証跡は「探索しやすい（easier to navigate）」という利点がある。
すべての証跡がリソースの設定状態と直接紐付いているため、特定リソースの
コンプライアンス状態を一覧で確認しやすい。

inconclusive 証跡の扱い

Audit Manager はコントロールに対して「準拠（COMPLIANT）」「非準拠（NON_COMPLIANT）」
「判定保留（inconclusive）」の3状態を提示する。証跡が十分に収集できなかった場合や
評価が確定できない場合に inconclusive となる。監査人がこの状態を見て追加調査を行うことが
できる。

Config Conformance Pack は inconclusive を出さない。すべての証跡が Config Rule の評価を
経てコンプライアンス状態（COMPLIANT / NON_COMPLIANT）にマッピングされる。評価が
確定できない曖昧なケースを二値化するため、「判定保留を追加調査するワークフロー」は
Config 側では設計し直しが必要になる。

2-3. 機能比較マトリクス

AWS 公式の「Comparing compliance solutions」表を基に、移行判断に必要な観点で Audit Manager
と Config Conformance Packs を比較する。

表の読み方と移行判断への応用

証跡収集の差（4データソース vs CI のみ）は、監査フレームワークによっては「証跡の範囲」
が移行後に縮小することを意味する。現行の Assessment で CloudTrail イベントや
Security Hub findings を証跡として使っている場合、Config 移行後はその証跡が自動収集
されなくなる点を把握したうえで代替策を設計する必要がある。

remediation（自動修復）は Config 側の明確な追加機能だ。Audit Manager では非準拠リソースを
検出しても手動対応しか選択肢がなかったが、Config Conformance Pack では修復プランを
定義し自動実行できる。これは移行の積極的な動機になりうる。

★ SOC2 / GDPR / ISO 27001 は Config Conformance Pack 非対応（必達条件②）

Config Conformance Pack が「技術的 Core Controls（Config Rule で評価可能なもの）のみを含む」
という制約は、フレームワーク対応の範囲を決定的に限定する。PCI DSS・HIPAA・NIST の技術的
コントロール（例: 「S3 バケットのパブリックアクセスが無効か」）は Config Rule で評価できる。
しかし「組織がセキュリティポリシーを文書化し承認を得たか」のような管理的コントロールは
Config Rule で評価できない。SOC2 や GDPR はこの管理的コントロールの比重が高く、それが
テンプレート非対応の根本的な理由だ。

コスト面での移行メリット

コスト構造の差も移行判断の要素になる。Audit Manager は Assessment 数・対象アカウント数・
コントロール評価回数に応じた課金が発生する。特に組織横断（Organizations 展開）では
アカウント数に比例してコストが増加する傾向にある。

Config Conformance Pack は AWS Config の通常利用料（設定項目の記録・Config Rules の評価）
の範囲内で動作し、Conformance Pack 自体に追加課金はない。大規模組織での横断展開において、
Audit Manager と比較してコスト削減を見込める場合がある。ただし Organization Conformance
Pack を展開すると対象 OU 内の全アカウントで Config Rules が評価されるため、評価回数ベースの
Config 料金が増加する点は計画に含める必要がある。

監査レポート代替手段の現実的な評価

「監査レポートが PDF/CSV で直接出ない」は Config 移行の典型的な懸念点だ。しかし代替手段は
3経路ある。Config Advanced Query は現在の設定状態を SQL で抽出し CSV/JSON エクスポートできる。
get-resource-config-history API は特定リソースの設定変更履歴を時系列で取得できるため、
「特定期間に何が変わったか」の監査証跡として使える。Athena＋QuickSight は複数リソース
横断の分析・ダッシュボード化に向いており、AWS 公式ブログ
「Visualizing AWS Config data using Amazon Athena and Amazon QuickSight」に実装例が
掲載されている。これらを組み合わせることで、監査要件に応じたレポートを構築できる。

2-4. remediation 対応という移行メリット

Audit Manager を離れて Config Conformance Pack に移行する際、証跡モデルの縮小（4データソース
→ CI のみ）はデメリットとして受け取られることが多い。しかし remediation（自動修復）の
追加は、Audit Manager では実現できなかった「検出＋即時対応」の自動化を可能にする
積極的な移行メリットだ。

Audit Manager は非準拠リソースを検出し、Assessment ダッシュボードでその状態を可視化する
ことはできる。しかし検出した非準拠状態を自動修復する機能は持っていない。監査担当者が
ダッシュボードを確認し、手動でチケットを起票し、担当者が修正し、再度 Assessment で
確認するというループになる。

Config Conformance Pack では、各 Config Rule に対して remediation アクションを紐付けられる。
非準拠を検出したタイミングで、あらかじめ定義した修復ドキュメント（SSM Automation ドキュメント
や Lambda 関数）を自動実行できる。例えば「S3 バケットのパブリックアクセスが有効になった」
ことを検出した瞬間に、SSM Automation が自動でパブリックアクセスをブロックする修復を
実行できる。

実装の詳細（SSM Automation ドキュメント・Lambda Remediation の HCL コード・3種類の
Conformance Pack 同時適用方法）は実装ハンズオン記事に詳説している。本記事の役割は
「remediation という移行メリットが存在する」という設計上の位置づけを伝えることだ。

3. フレームワーク対応マッピングとギャップ

3-1. 対応フレームワーク早見表

AWS Audit Manager は 2026 年 4 月のメンテナンスモード移行時点で 35 種のマネージドフレームワークを提供しており、SOC 2・PCI DSS・HIPAA・GDPR・NIST・FedRAMP 等の主要な業界標準・法規制に対応している。これらのフレームワークを Config Conformance Pack へ移行する際、まず確認すべきことは「現在 Audit Manager で使っているフレームワークに対応する Conformance Pack テンプレートが存在するか」だ。

AWS の公式マッピングドキュメントによると、技術的 Core Controls（Config Rule で評価できるリソース設定）を持つフレームワークには対応テンプレートが提供されているが、プロセス要件・人的管理要件・法的義務要件を含むフレームワークには “No equivalent”（相当テンプレートなし） と明記されている。

以下の表は、Audit Manager の主要フレームワークと Config Conformance Pack の対応関係を示す（2026 年 6 月、公式サンプルテンプレート一覧 で確認済み）。

PCI DSS v4.0 の 2 バリアントについて

PCI DSS v4.0 テンプレートは “Excluding global resource types”（グローバルリソースタイプ除外）と “Including global resource types”（グローバルリソースタイプ包含）の 2 種類がある。IAM ユーザー / ポリシー / ロール / グループ等のグローバルリソースを複数リージョンで評価すると重複カウントが発生するため、複数リージョンにデプロイする場合は Excluding バリアントを推奨する。東京リージョン（ap-northeast-1）のみの単一リージョン構成では Including バリアントが通常の選択だ。

FedRAMP の影響度レベル別テンプレートについて

FedRAMP は Low / Moderate / High の 3 段階の影響度レベルに対応したテンプレートを提供する。High は対象 Config Rule 数が多いため Part 1 と Part 2 に分割されている。FedRAMP ATO（Authority to Operate）取得済みの環境では、認可された影響度レベルと一致するテンプレートを選択する。

CJIS / SWIFT CSP / IRS 1075 について

金融・司法・政府系の特殊フレームワークについても Conformance Pack テンプレートが提供されている。CJIS（刑事司法情報サービス）・SWIFT CSP（金融機関間送金）・IRS 1075（米国税務情報）を Audit Manager で運用している場合は、それぞれ対応する Conformance Pack テンプレートへ移行可能だ。ただしこれらのフレームワークも「技術的 Core Controls のみ」のカバーであることに変わりはないため、フレームワーク固有の非技術的要件については別途対応を要する場合がある。

Conformance Pack テンプレートライブラリの規模

現時点での Conformance Pack サンプルテンプレートは 100 種以上（AWS 公式比較表「over 100 pre-defined templates」）にのぼる。上記の主要フレームワーク対応に加え、ACSC ISM（オーストラリア）/ ABS CCIG（シンガポール）/ ENS（スペイン）/ BNM RMiT（マレーシア）/ Germany C5 / NZISM / SWIFT CSP など各国・地域の業界基準テンプレートも含まれる。移行対象フレームワークが上記以外の場合は、最新の Conformance Pack Sample Templates ページで直接確認することを推奨する。テンプレートライブラリは継続的に拡充されており、本記事執筆時点（2026 年 6 月）の一覧が最新とは限らない。

Audit Manager が対応する主要フレームワーク（35 種）の全体像

Audit Manager のマネージドフレームワーク 35 種は大きく以下のカテゴリに分類できる。移行設計では各フレームワークが上記の Config 対応表のどこに該当するかを確認することが第一歩だ。

ポイントは「技術的設定の自動評価が中心のフレームワーク（決済・医療・連邦政府系）は Config で対応できるが、人的統制・法的プロセス・組織的管理が主体のフレームワーク（SOC 2・GDPR・ISO 27001）は Config では対応できない」という構造的な区分だ。

カスタムフレームワーク・カスタムコントロールがある場合

Audit Manager の強みの一つが、カスタムコントロールおよびカスタムフレームワークの作成機能だ。移行設計においては、既存のカスタムコントロールが Config Conformance Pack で再現できるかどうかを個別に評価する必要がある。

• 再現可能: カスタムコントロールのデータソースが Config Rules のみの場合。対応する Config マネージドルールまたはカスタムルールを Conformance Pack テンプレートに組み込める。
• 再現困難: カスタムコントロールのデータソースに CloudTrail イベント・Security Hub コントロール・手動証跡（Manual evidence）が含まれる場合。Config Conformance Pack は CI のみを評価するため、これらのデータソースはカバー外となる。

カスタムフレームワークを多用している組織は、移行前のカスタムコントロール棚卸しに時間を要する可能性がある。「カスタムコントロールの 70〜80% が Config Rules ベース」という構成であれば移行コストは低いが、CloudTrail イベントや手動証跡を多用している構成では補完手段の導入が移行の前提条件となる。

3-2. ★ギャップ: SOC 2 / GDPR / ISO 27001

前節の表でも明示したが、Audit Manager で広く使われている SOC 2・GDPR・ISO 27001 には Config Conformance Pack の対応テンプレートが存在しない。これが移行設計において最も重要なギャップであり、2026 年現在の AWS 公式ドキュメントでも “No equivalent” と明記されている。

以下では各フレームワークのギャップの内容と影響を整理する。

SOC 2（SSAE 18）/ SOC 3 のギャップ

SOC 2 は AICPA が定める信頼サービス基準（Trust Services Criteria: TSC）に基づいたサービス組織の内部統制報告フレームワークである。TSC は以下の 5 カテゴリで構成される。

• Security（共通基準 CC）: 不正アクセス・不正使用からシステムを保護するための統制
• Availability（A）: 合意されたサービスレベルにおけるシステムの可用性
• Processing Integrity（PI）: システム処理の完全性・正確性・タイムリー性
• Confidentiality（C）: 機密情報の保護
• Privacy（P）: 個人情報の収集・使用・開示・保持・廃棄に関する統制

これらの多くは「AWS クラウドリソースの設定状態を Config Rule で自動評価する」モデルでは評価できない。CC1.1〜CC1.5（コントロールの有効性・取締役レベルのコミットメント）、CC2.1〜CC2.3（情報・コミュニケーション）、P シリーズ（プライバシー基準）は人的プロセスや組織的管理が主体であり、Config Rule の評価範囲外となる。また SOC 2 の監査では外部の公認会計士（CPA）による検証が必要であり、Config が出力するコンプライアンスレポートはその代替にならない。SOC 2 タイプ 1 / タイプ 2 の審査を引き続き受ける必要がある組織は、専用の GRC プラットフォーム（Vanta / Drata 等）による継続的コントロールエビデンス収集が不可欠だ。

GDPR（一般データ保護規則）のギャップ

GDPR は EU 市民の個人データを扱うすべての組織に適用される法的フレームワークである。暗号化・アクセスログ等の技術的セキュリティ要件は Config Rule で一部評価できるが、GDPR の多くの要件は技術的設定の範囲を超えている。Config Conformance Pack でカバーできない GDPR 要件の例を以下に示す。

• データ主体の権利対応: アクセス権（Art. 15）・消去権（Art. 17）・データポータビリティ（Art. 20）の実装と運用記録
• データ保護影響評価（DPIA）: 高リスク処理に対する影響評価の実施（Art. 35）
• データ処理記録（ROPA）: 処理活動の記録の維持（Art. 30）
• データ保護責任者（DPO）: 必要な場合の DPO の指定と機能維持（Art. 37〜39）
• 越境移転の適法化: 第三国へのデータ移転に関する適切な保護措置（Art. 44〜49）

これらはいずれも組織的・法的プロセスの要件であり、AWS リソースの設定状態を自動評価する Conformance Pack の仕組みでは対処できない。EU 個人データを処理する組織は、Config 移行後も GDPR 専用のコンプライアンスツールと法務プロセスの維持が必要だ。

ISO/IEC 27001:2013 のギャップ

ISO 27001 は情報セキュリティマネジメントシステム（ISMS）の確立・実装・維持・継続的改善を定めた国際規格である。AWS Config Conformance Pack には ISO 27001 に対応するサンプルテンプレートが存在しない（2026 年 6 月現在、公式テンプレート一覧 確認済み）。

Audit Manager は ISO/IEC 27001:2013 Annex A の 114 のコントロールをカバーするマネージドフレームワークを提供しており、自動証跡収集と手動評価を組み合わせた審査が可能だ。しかし ISO 27001 の要件の多くは Config Rule で評価できないプロセス要件を含む。

• リスクアセスメントプロセス（6.1.2）: 情報セキュリティリスクの特定・分析・評価の記録
• 是正処置の有効性検証（10.1）: 不適合に対する是正処置の有効性確認
• 内部監査（9.2）: ISMS 内部監査の計画・実施・結果記録
• マネジメントレビュー（9.3）: 定期的なマネジメントレビューの実施と議事録
• リスク対応計画（6.1.3）: リスク対応オプションの選択と実施結果の記録

ISO 27001 認証を維持する必要がある組織は、認証機関（ISMS-AC 等）による外部審査を引き続き受ける必要があり、Config Conformance Pack はその補助ツールの一部にはなり得るが、主要な証跡収集基盤にはなれない。

カスタム Conformance Pack でのギャップ回避は現実的でない

「カスタム Config Rule を作成して SOC 2 / GDPR / ISO 27001 に対応するカスタム Conformance Pack を作れば良いのでは」という疑問が生じる。しかし、この方法でもギャップは解消できない。理由は以下の 2 点だ。

第一に、Config Rule はリソースの設定状態（Configuration Item）を評価するものであり、「組織がポリシーを文書化しているか」「従業員がトレーニングを受けたか」「リスクアセスメントを実施したか」といった人的・プロセス要件を評価する Rule を作成することが技術的に不可能だ。Config Rule のスコープは「AWS クラウドリソースの設定」に限定されている。

第二に、SOC 2 / ISO 27001 の監査には外部の独立した審査者（CPA / 認証機関）による評価が必要であり、AWS 内部ツールの出力レポートがその審査を代替できない。いかに精巧な Conformance Pack を構築しても、「外部監査者が要求する証拠形式」との乖離は埋まらない。

したがって、SOC 2・GDPR・ISO 27001 に対しては Vanta・Drata 等の専門 GRC プラットフォームとの組み合わせが唯一の現実解であることを、移行設計の前提として確認しておく必要がある。

3-3. ギャップが意味すること — 「直接の代替ではない」という公式見解

AWS 公式は「Conformance Pack templates are not direct replacements for Audit Manager frameworks」と明記している。これは単なるテンプレート不在の問題ではなく、両システムの設計思想の根本的な違いから来る。

Audit Manager の設計思想: 証拠駆動型の監査フレームワーク

Audit Manager は「外部監査・内部監査のための証拠（evidence）を体系的に収集・整理する」ことを目的に設計されている。フレームワーク内の各コントロールには、証拠を収集するデータソース（サービス API 呼び出し / Security Hub / CloudTrail / Config Rules の 4 種）が定義されており、自動収集と手動収集が明確に区分されている。判定保留（inconclusive）証跡の概念も、「不確実な状態を明示して人間が判断する」という監査思想を反映している。

Config Conformance Pack の設計思想: 自動評価による継続的コンプライアンス監視

Config Conformance Pack は「AWS リソースの設定状態を Config Rules で継続的に自動評価し、コンプライアンススコアをリアルタイムに把握する」ことを目的に設計されている。評価は Config が収集する Configuration Item（CI）のみを対象とし、判定は「Compliant / Non-Compliant」の二値だ。人的プロセスや外部監査をサポートする仕組みは備わっていない。

コントロールタイプ別の評価可能範囲

Conformance Pack が対応できる技術的 Core Controls と、Audit Manager のみが対応できるコントロールを区別することが、移行設計の出発点となる。

Audit Manager から Config Conformance Pack への移行後、「自動評価できる技術的コントロール」は Config がカバーするが、「プロセス・組織・法的要件」は引き続き別の手段で対応が必要になる。この認識なしに「Conformance Pack に移行すれば SOC 2 / GDPR / ISO 27001 の準拠を継続できる」と判断することは、監査対応上の重大な誤りとなる。

SOC 2・GDPR・ISO 27001 を含む監査プログラムを維持する組織の移行計画では、Config Conformance Pack への移行と並行して §6 で述べるギャップ補完戦略（サードパーティ GRC ツール / Security Hub 連携 / Control Tower controls-only 活用）を組み合わせることが不可欠だ。

混在フレームワーク環境での現実的な移行シナリオ

実際の移行プロジェクトでは、「一部のフレームワークは Config Conformance Pack へ完全移行でき、一部はサードパーティ GRC ツールとの並行運用が必要」という混在シナリオが最も多い。たとえば PCI DSS v4.0 と SOC 2 を同時に Audit Manager で運用している場合、移行後の構成は次のように分かれる。

このような混在構成の場合、移行コストは「Config 移行コスト + GRC ツール導入コスト」の両方が発生する。Audit Manager が「一つのコンソールで SOC 2 と PCI DSS を並行管理できていた」という集約的なメリットを失う点も、移行コスト評価に含めるべきだ。

移行に伴う証拠（evidence）の引き継ぎについて

ギャップフレームワーク（SOC 2・GDPR・ISO 27001）の evidence は、Audit Manager を無効化する前に必ず退避する。Audit Manager 無効化後も既存の証跡は収集日から最大 2 年間保持されるが（明示的に削除しない限り）、Evidence Finder を有効化して CloudTrail data lake へエクスポートしておくと、無効化後も自由にアクセスできる。この証跡退避の手順は §7 で詳述する。

まとめ (§3): Conformance Pack への移行は「技術的 Core Controls の自動評価基盤」を Config に移すことを意味する。SOC 2・GDPR・ISO 27001 のように人的プロセス・法的要件を含むフレームワークは移行先に存在しないため、ギャップを補完するサードパーティ GRC ツールの導入計画を移行設計と同時に策定することが不可欠だ。

4. 移行設計手順

移行設計は「現状把握 → 移行先選定 → デプロイ → 検証」の4ステップで進める。各ステップで重要なのは Terraform の実装コードではなく、設計上の判断軸だ。Terraform 実装の詳細（Config Recorder・Delivery Channel・3種 Pack 同時適用・SSM Automation・Lambda Remediation の HCL コード）は AWS Config Conformance Pack Auto Remediation Terraform 本番運用 に詳説されているため、そちらを参照してほしい。本記事では移行設計に集中する。

4-1. ステップ1: Audit Manager Assessment の棚卸し

移行の出発点は、現在稼働中の Audit Manager リソースを可視化することだ。以下の3観点で棚卸しリストを作成する。

1-1. 使用中フレームワークとスコープの確認

AWS マネジメントコンソールまたは CLI で、有効な Assessment の一覧を抽出する。

# 全 Assessment の一覧（フレームワーク・スコープ・ステータスを確認）
aws auditmanager list-assessments \
  --query 'assessmentMetadata[*].{Name:name,Framework:complianceType,Status:status}' \
  --output table

# カスタムフレームワークの有無を確認
aws auditmanager list-assessment-frameworks \
  --framework-type Custom \
  --query 'frameworkMetadataList[*].{Name:name,ControlsCount:controlsCount}' \
  --output table

確認すべき情報と移行設計への影響を以下の表に整理する。

組織 (AWS Organizations) 展開している場合の注意: Management Account または Delegated Administrator Account からの確認が必要だ。メンバーアカウント単独では組織全体のスコープを把握できない。

1-2. カスタムコントロールの棚卸し

Audit Manager で定義したカスタムコントロールが Config Conformance Pack で再現できるかどうかを確認する。再現可能性の判定基準は以下の通りだ。

再現可能 — カスタムコントロールのデータソースが Config Rules の場合。対応する Config マネージドルールまたはカスタムルールを作成して Conformance Pack に組み込める。既存の Audit Manager カスタムコントロールに使用している Config Rule ID を特定し、Conformance Pack テンプレートの Rules: セクションにそのまま転記できることが多い。

再現困難 — カスタムコントロールのデータソースが CloudTrail イベント・Security Hub コントロール・手動証跡 (Manual evidence) の場合。Config Conformance Pack は Configuration Item (CI) のみを評価するため、これらのソースはカバーできない。

この棚卸し結果によって「Config 単独で継続できるコントロール」と「§6 の補完手段が必要なコントロール」を明確に仕分けることができる。移行計画を立てる前に仕分け表を作成し、補完手段の導入コストを含めた移行見積もりを作ることを推奨する。

1-3. evidence 収集ソースの確認

Audit Manager が現在どのデータソースから証跡（evidence）を収集しているかを確認する。コンソールの Assessment 設定画面 → 「Evidence Collection」タブで各コントロールのデータソースタイプを確認できる。

• Config Rules のみ → Config Conformance Pack での証跡継続が可能
• CloudTrail / Security Hub / サービス API 呼び出しを含む → 証跡の網羅性が低下することを前提に移行計画を立てる

§2 で解説した通り、Audit Manager は4データソース（サービス API 呼び出し / Security Hub コントロール / CloudTrail イベント / Config Rules）から証跡を集約するが、Config Conformance Pack は Configuration Item のみを使用する。この差が「移行後にどこまで自動検出できるか」の現実的な見積もりとなる。

4-2. ステップ2: 対応 Conformance Pack の選定

棚卸し結果をもとに、フレームワーク別の移行先 Conformance Pack を選定する。

2-1. フレームワーク別の推奨 Conformance Pack

主要フレームワークの移行先は以下の通りだ。

SOC2・GDPR・ISO27001 の3フレームワークは Config Conformance Pack に対応テンプレートが存在しない（§3 で詳述）。これらを Audit Manager で運用していた場合は、Pack 選定と並行して補完手段の検討を進める必要がある。

2-2. カスタム Conformance Pack が必要なケース

以下の条件に当てはまる場合、カスタム Conformance Pack の作成を検討する。

1. Audit Manager カスタムフレームワーク（独自コントロールセット）を移行する場合 — カスタムフレームワークのコントロールに使用している Config Rule を YAML テンプレートにまとめて Custom Conformance Pack を作成する
2. マネージドテンプレートでカバーされないルールを一括適用したい場合 — 自社固有のセキュリティポリシーに対応するカスタム Config ルールを組み込む
3. 特定のリソースタイプのみ対象としたい場合 — Scope パラメータでリソースタイプを絞り込んだカスタム Pack を作成する

カスタム Conformance Pack は CloudFormation テンプレートと同じ YAML 形式で記述する。Terraform での実装（aws_config_conformance_pack リソース等）は 実装ハンズオン記事 を参照してほしい。

2-3. Organizations 展開のパターン選択

複数アカウント・複数リージョンに展開する場合、Organization Conformance Pack を使用する。設計上の判断ポイントは以下の通りだ。

Audit Manager で組織全体スコープの Assessment を運用していた場合は、Organization Conformance Pack への移行が自然な選択だ。Delegated Admin アカウントを活用する構成の場合は、Management Account での事前設定（register-delegated-administrator コマンド）が必要になる点を確認しておく。

4-3. ステップ3: Conformance Pack のデプロイ概要

選定した Conformance Pack をデプロイする。本ステップでは 手順の概要と設計上の選択肢 を示すにとどめ、Terraform 実装の詳細は以下の実装記事へ委譲する。

3-1. AWS コンソールでのデプロイ（単一アカウント）

コンソールから Conformance Pack をデプロイする手順の概要は次の通りだ。

1. AWS Config コンソールを開き、左メニューから「Conformance packs」を選択する
2. 「Deploy conformance pack」をクリックし、以下を選択する
3. テンプレートソース: 「Sample template」（マネージドテンプレートを使用）または「Upload a template」（カスタム Pack の場合）または「Template stored in Amazon S3」（S3 に保存した YAML を参照）
4. Conformance pack name: 一意の名前を入力（例: pci-dss-v4-production）
5. Parameter overrides: テンプレートが要求するパラメータを入力（例: 対象 S3 バケット名・アクセスログの保持期間等）
6. 「Deploy conformance pack」でデプロイを実行する

デプロイ後、Config がすべての対象リソースをスキャンしてコンプライアンス状態を評価するまで数分〜数十分かかる。リソース数が多い大規模環境では評価完了に30分以上かかることもある。初回デプロイ後すぐに結果を確認しようとして「リソースが表示されない」と判断しないよう、評価完了を待ってから移行後検証（ステップ4）に進む。

3-2. CLI でのデプロイ状態確認

デプロイ後の状態確認に使う CLI コマンドを示す。

# デプロイ済み Conformance Pack 一覧と状態確認
aws configservice describe-conformance-packs \
  --query 'ConformancePackDetails[*].{Name:ConformancePackName,Status:ConformancePackState,ARN:ConformancePackArn}' \
  --output table

# 特定 Pack のコンプライアンスサマリー（準拠率確認）
aws configservice get-conformance-pack-compliance-summary \
  --conformance-pack-names pci-dss-v4-production \
  --query 'ConformancePackComplianceSummaryList[*].{Pack:ConformancePackName,Status:ConformancePackComplianceStatus}'

ConformancePackState が CREATE_COMPLETE になっていれば Pack のデプロイは完了だ。CREATE_IN_PROGRESS の間は評価がまだ進行中なので、完了を待つ。

3-3. Organization Conformance Pack の展開

複数アカウント展開では Management Account（または Delegated Admin）から展開する。展開状況の確認は以下のコマンドで行う。

# Organization Conformance Pack の展開状況確認
aws configservice describe-organization-conformance-packs \
  --query 'OrganizationConformancePacks[*].{Name:OrganizationConformancePackName,Status:LastUpdateTime}' \
  --output table

# メンバーアカウント単位の展開ステータス確認
aws configservice get-organization-conformance-pack-statuses \
  --organization-conformance-pack-names org-pci-dss-v4 \
  --query 'OrganizationConformancePackStatuses[*].{Account:AccountId,Status:Status}'

展開に失敗したメンバーアカウントがある場合、get-organization-conformance-pack-detailed-status コマンドでアカウント別のエラー理由を確認できる。IAM 権限不足や Config Recorder の未設定がよくある原因だ。

4-4. ステップ4: 移行後の検証

Conformance Pack デプロイ後、移行が意図通りに機能しているかを以下の3観点で検証する。

4-1. コンプライアンスステータスの確認

Config コンソールの「Conformance packs」画面で各 Pack のコンプライアンスステータスを確認する。確認ポイントは次の通りだ。

• コンプライアンス率（%）: Pack 全体の適合率が許容基準（例: 80%以上）を満たしているか。初回デプロイ直後はリソース設定の見直し前なので低い値になることが多い
• 非準拠ルール一覧: どの Config Rule が非準拠リソースを検出しているか。Audit Manager 時代に把握していた非準拠コントロールと照合して、検出の継続性を確認する
• 非準拠リソースの詳細: 具体的なリソース ID・タイプが一致しているかをサンプリングで確認する

Audit Manager 時代との重要な差分として、Conformance Pack は「COMPLIANT」「NON_COMPLIANT」「NOT_APPLICABLE」の3値で評価結果を返す。Audit Manager にあった「INCONCLUSIVE（判定保留）」はなくなり、判定が二値（準拠/非準拠）に明確化される。この変化は監査担当者への事前説明を要する場合がある。

4-2. レポート出力確認

Audit Manager の PDF/CSV 監査レポートに直接対応する機能は Config にない。移行検証の段階で、少なくとも以下の代替出力を試験的に実行しておく（詳細は §5 で解説）。

• Config Advanced Query: コンソールの「Advanced queries」でサンプルクエリを実行し、コンプライアンス結果が CSV エクスポートできることを確認する
• get-resource-config-history API: 特定リソースの設定変更履歴が指定期間で取得できることを CLI で確認する
• Athena: Config データが S3 に記録されており、Athena テーブルへのクエリが成功することを確認する

代替手段が機能していることを確認した後、監査チームへの引き渡し手順書に代替出力の手順を記録しておく。

4-3. アラーム設定

Conformance Pack の非準拠検出を Amazon EventBridge + Amazon SNS でアラーム化する。Audit Manager はダッシュボード上での定期確認が主だったが、Config + EventBridge の組み合わせでリアルタイムのアラーム通知が可能になる点は移行のメリットの一つだ。

設定の概要は次の通りだ。

1. EventBridge ルールを作成し、source: aws.config かつ detail-type: Config Rules Compliance Change のイベントをトリガーにする
2. イベントパターンで newEvaluationResult.complianceType: NON_COMPLIANT に絞り込む
3. ターゲットに SNS トピックを設定し、監査担当者へのメール通知を有効化する
4. （オプション）SNS → Lambda で Slack / Teams 通知などのカスタム通知ロジックを追加する

アラーム設定が完了したら、テスト用にコンプライアンス違反が発生するリソース設定（例: S3 バケットのパブリックアクセスブロック無効化）を一時的に作成し、通知が正常に届くことを確認した上で元の設定に戻す。

5. 証跡エクスポート移行

Audit Manager が担っていた「証跡の収集・保持・監査レポート化」は、Config Conformance Packs への移行後にどう引き継ぐかが移行設計の核心だ。まず Audit Manager の S3 証跡構造と Config の記録先の違いを整理したうえで、監査レポートの代替手段を 3 つのアプローチから解説する。

5-1. Audit Manager の evidence フォルダ構造と Config 記録先の違い

Audit Manager は evidence (証跡) を S3 バケットへ格納する。S3 上のパス構造は次の通りだ。

s3://{bucket}/{prefix}/
  {assessmentId}/
 {assessmentName}/
{controlSetId}/
  {controlId}/
 {evidenceId}.json

各 evidence オブジェクトは JSON 形式で、以下のフィールドを含む。

この構造は「コントロール単位で整理された証跡帳票」だ。監査者が特定のコントロールに紐づく証跡を一覧できるよう設計されており、外部監査人に対してコントロール単位のエビデンスフォルダを提示しやすい形式になっている。

Config Conformance Pack では、証跡の記録先が大きく変わる。Config は Configuration Item (CI) をリソース設定変更のたびに記録し、Config Delivery Channel 経由で S3 へ配信する。

重要なのは、Config が収集する CI は Configuration Item のみ であり、Audit Manager が収集していた CloudTrail イベント・Security Hub コントロール・サービス API 呼び出しの証跡は含まれない点だ。証跡の網羅性は下がるが、Config Rule 評価に基づく COMPLIANT / NON_COMPLIANT の二値判定で探索しやすくなる。また Audit Manager が提示していた「INCONCLUSIVE (判定保留)」証跡は Config には存在しない。全証跡が Config Rule 経由でコンプライアンス状態にマッピングされるため、判定は二値になる。

5-2. 監査レポートの代替手段 — 3 つのアプローチ

Audit Manager が提供する PDF/CSV 監査レポートに直接相当する機能は Config には存在しない。実用的な代替として次の 3 アプローチを目的別に使い分ける。

加えて、Audit Manager 無効化前に最後の監査レポートを PDF/CSV でエクスポートして S3 に保管しておくことを強く推奨する。Config への移行後は同形式でのエクスポートができなくなるため、「Audit Manager 最終監査レポート」として保管しておくと後日の監査ヒアリング時に役立つ。エクスポートには CLI が使える。

# Audit Manager 最終レポートの作成 (無効化前に実行)
aws auditmanager create-assessment-report \
  --name "FinalReport-MigrationSnapshot" \
  --description "Audit Manager 最終監査レポート (移行前エクスポート)" \
  --assessment-id {assessment-id}

また、Config Conformance Pack への移行後は Conformance Pack のコンプライアンス状態スナップショット を定期的にエクスポートすることで、監査レポートの代替として活用できる。スナップショットのエクスポートは Advanced Query から CSV でダウンロードするか、AWS CLI で取得する。

5-3. Config Advanced Query

Advanced Query は AWS Config コンソールの 「Saved queries」 から実行できる SQL ライクなクエリ機能で、クエリ結果は CSV または JSON 形式でダウンロードできる。監査レポート用途では、特定 Conformance Pack の非準拠リソースを一覧するクエリが典型的だ。

基本構文は次の形式をとる。

SELECT
  resourceId,
  resourceType,
  configuration.complianceType,
  awsRegion,
  tags
WHERE
  resourceType = 'AWS::S3::Bucket'
  AND configuration.complianceType = 'NON_COMPLIANT'

より広範なコンプライアンス状態の一覧を抽出する場合は、条件を省略したシンプルなクエリも有効だ。

SELECT
  resourceId,
  resourceType,
  awsRegion,
  configuration.complianceType
WHERE
  configuration.complianceType = 'NON_COMPLIANT'
ORDER BY
  awsRegion, resourceType

マルチアカウント・マルチリージョン対応: AWS Config Aggregator を設定すると、複数アカウント・複数リージョンの CI を単一クエリで横断検索できる。コンソールの「Aggregated view」に切り替えて実行する。Organizations 全体を対象にした Aggregated Conformance Pack ビューを確認する際に特に有用だ。

Advanced Query の主な制限を把握しておくことが重要だ。

• クエリ対象は 最新の CI のみ (過去のスナップショットは取得不可)
• 1 クエリあたりのレスポンスには件数上限があり、大量リソースにはページネーションか Athena を使用する
• テーブル間の JOIN クエリはサポートされていない
• カスタムフィールドの追加はできない (CI スキーマに依存)

Advanced Query は「現時点で非準拠のリソースを一覧する」「特定の設定値を持つリソースを抽出する」用途に最適だ。時系列での変化履歴が必要な場合は次の API を使用する。

5-4. get-resource-config-history API による変更履歴取得

特定リソースの設定変更履歴 (各変更時点のコンプライアンス状態を含む) を取得するには get-resource-config-history CLI コマンドを使用する。監査対応で「特定の期間に設定変更があったか」を問われた際に有効だ。

aws configservice get-resource-config-history \
  --resource-type AWS::S3::Bucket \
  --resource-id my-audit-bucket \
  --earlier-time 2026-01-01T00:00:00Z \
  --later-time 2026-06-30T23:59:59Z \
  --chronological-order Forward \
  --limit 100

主なパラメータと制限を以下に示す。

レスポンスには configurationItems 配列が返され、各アイテムに configurationItemCaptureTime・configurationItemStatus・configuration JSON が含まれる。nextToken が返された場合はページネーションが必要であり、スクリプト化して全件取得することを推奨する。

利用上の注意点:

• グローバルリソース (IAM ロール・ポリシーなど) は us-east-1 リージョンに記録されているため、他リージョンからクエリしても結果を返さない場合がある
• Config が記録を開始した日時より前の変更履歴は取得できない
• 大量の変更履歴がある長期稼働リソースでは繰り返しページネーションが必要になる

監査ヒアリングで「2025年12月から2026年3月の間に S3 バケットの設定変更があったか」を問われた際に、このコマンドで変更履歴を JSON で提出できる。CI には変更前後の configuration スナップショットが含まれるため、どの時点でどの設定が変更されたかを具体的に示せる。

5-5. Athena + Amazon QuickSight による分析・ダッシュボード化

複数リソース横断での集計・可視化が必要な場合は、Config の S3 Delivery Channel に出力された CI を Athena でクエリし、QuickSight でダッシュボード化するアーキテクチャが実用的だ。AWS 公式ブログ 「Visualizing AWS Config data using Amazon Athena and Amazon QuickSight」 でリファレンスアーキテクチャが公開されている。

セットアップの流れ:

1. Config Delivery Channel の S3 バケットを確認 — Config が CI を JSON で配信しているバケットとプレフィックスを aws configservice describe-delivery-channels で特定する
2. AWS Glue クローラーでスキーマ自動検出 — CI の JSON スキーマを Glue Data Catalog に登録する
3. Athena テーブルの定義 — Glue カタログを参照する Athena テーブルを作成し SQL クエリを実行する
4. QuickSight でダッシュボード作成 — Athena をデータソースとして接続し、コンプライアンストレンドを可視化する

Athena でのクエリ例 (月別・リソースタイプ別の非準拠リソース数の推移):

SELECT
  DATE_FORMAT(configurationitemcapturetime, '%Y-%m') AS month,
  resourcetype,
  COUNT(*) AS noncompliant_count
FROM config_items
WHERE configurationitemstatus = 'NON_COMPLIANT'
GROUP BY
  DATE_FORMAT(configurationitemcapturetime, '%Y-%m'),
  resourcetype
ORDER BY month, noncompliant_count DESC

このアーキテクチャにより、Audit Manager のダッシュボードが提供していた「フレームワーク別コンプライアンス率のトレンド表示」に近い分析を Config データで実現できる。初期構築にはコストと工数がかかるが、一度セットアップすれば組織全体のコンプライアンス状況を継続的に可視化できる。Athena は使用量課金のため小規模なクエリ用途にも適している。

5-6. 2 年間の evidence データ退避・保存戦略

Audit Manager を無効化した後も、既存の evidence は 収集日から 2 年間 は S3 に保持される (明示的に削除しない限り)。ただし、無効化後は Audit Manager コンソールから証跡を閲覧・エクスポートできなくなる。そのため、無効化前に Evidence Finder を有効化してエクスポートを完了しておくことが推奨される。

Evidence Finder の有効化手順:

1. Audit Manager コンソール → 「Settings」 → 「Evidence Finder」 → 有効化
2. 有効化すると、証跡が CloudTrail Lake のイベントデータストアに自動エクスポートされる
3. Audit Manager を無効化した後も、CloudTrail Lake のクエリ機能で証跡を検索・取得できる

# Evidence Finder の有効化状態を確認
aws auditmanager get-settings --attribute evidenceFinderEnablement
# 証跡 S3 バケットの確認
aws auditmanager get-settings --attribute defaultAssessmentReportsDestination

Evidence Finder 利用時の注意点:

• 有効化後から順次エクスポートが開始されるため、Audit Manager 無効化の 少なくとも 1〜2 週間前 に有効化しておくことを推奨する
• CloudTrail Lake のイベントデータストアには保持コストがかかる (使用量に応じた課金)
• デフォルトの保持期間は 7 年 (変更可能)

Evidence Finder を利用しない場合でも、Audit Manager の証跡 S3 バケットのライフサイクルポリシーを確認し、2 年の保持期間中に誤削除されないよう設定を維持することが重要だ。移行完了後も S3 バケットを保持することで、監査ヒアリング時に過去の evidence JSON を直接参照できる。2 年経過後の保管方針 (Glacier へのアーカイブや S3 Intelligent-Tiering への移行) を事前に計画しておくとコスト最適化にもなる。

6. ギャップ補完戦略

§3 で確認した通り、Config Conformance Packs は技術的な Core Controls (Config Rule で評価可能な設定検証) に特化しており、SOC2/GDPR/ISO 27001 に必要な「組織的コントロール・プロセス証跡・人的管理策」の評価は対象外だ。このギャップを補完するには、フレームワークの性質に応じて適切な手段を選択する必要がある。

6-1. サードパーティ GRC ツール — SOC2 / GDPR の本命

SOC2 と GDPR の監査対応においては、Vanta・Drata・Secureframe・Sprinto 等のサードパーティ GRC (Governance, Risk, Compliance) ツールとの併用が最も現実的な選択肢だ。AWS 公式も、これらのパートナーソリューションと Config を組み合わせることを推奨している。AWS が Audit Manager の移行先として Conformance Pack を案内しながらも「Conformance Pack は Audit Manager Framework の直接の代替ではない」と公式 FAQ で明言しているのは、まさにこのギャップが存在するためだ。

これらのツールが Config Conformance Pack との決定的な違いとして提供するのは以下の機能群だ。

各ツールの特徴:

• Vanta は特に SOC2 対応の自動化で実績があり、AWS Config の Config Rules を Vanta のコントロールに直接マッピングして技術的証跡を自動収集する統合機能を提供している。SOC2 Type I/II・HIPAA・ISO 27001 等の複数フレームワークをカバーする。
• Drata は SOC2 Type II・ISO 27001・GDPR 等の複数フレームワークに対応したコントロールマッピングと証跡ライブラリを持つ。継続的モニタリングによる準拠状態の可視化が強みだ。
• Secureframe はエンタープライズ向けに SOC2・ISO 27001・HIPAA・GDPR 等をカバーし、大規模組織向けの機能を提供している。
• Sprinto はスタートアップ・中小企業向けにコストを抑えた GRC 自動化を提供しており、SOC2 に特化した設計が特徴だ。

移行における役割分担の整理:

Audit Manager で SOC2/GDPR の Assessment を運用していた場合、Config Conformance Pack への単純な置き換えはできない。実用的な移行後の構成は次の二層分担になる。

• Config Conformance Pack: インフラの技術的設定を継続監視・修復 (Core Controls レイヤー)
• サードパーティ GRC ツール: SOC2/GDPR の組織的コントロール管理と完全な監査統制セット

この役割分担により、AWS インフラの技術的準拠監視を Config に任せながら、SOC2/GDPR の監査対応を専門ツールで完結させることができる。

注意すべきコスト面:

Audit Manager は「一つのコンソールで SOC2 と PCI DSS を並行管理できる」という集約的なメリットがあった。サードパーティ GRC ツールを追加導入する場合は、ツールのライセンス費用が新たに発生する。移行コスト評価には「Config 移行コスト + GRC ツール導入コスト」の両方を含めて試算することが重要だ。AWS Marketplace でも Vanta・Drata を含む複数の GRC ツールが提供されているため、現在 Audit Manager で管理しているフレームワークと同等のコントロールカバレッジを比較評価したうえで選定することを推奨する。

6-2. AWS Security Hub CSPM による補完

技術的フレームワーク (NIST 800-53・PCI-DSS・HIPAA 等) については、AWS Security Hub の CSPM (Cloud Security Posture Management) 機能が Config の補完・代替として有効な選択肢になる。

Security Hub が対応しているセキュリティスタンダードには以下が含まれる。

• NIST SP 800-53 Rev. 5
• PCI DSS v3.2.1 / v4.0
• HIPAA Security Rule
• CIS AWS Foundations Benchmark v1.4.0 / v3.0.0
• AWS Foundational Security Best Practices (FSBP)
• NIST Cybersecurity Framework (CSF)

Security Hub の特徴と Config Conformance Pack との使い分けを以下に示す。

Security Hub の活用ポイント:

1. Service-linked rules: Security Hub はスタンダードを有効化すると Config Rules (service-linked rules) を自動デプロイする。Config と Security Hub が二重で Rules を管理するのではなく、Security Hub が Config Rules を内包する形で機能するため、重複管理にはならない
2. Severity 付き findings: CRITICAL/HIGH/MEDIUM/LOW/INFORMATIONAL の severity が付与されており、優先度付きの対応計画を立てやすい。Audit Manager の「非準拠リソース一覧」よりも優先度情報が豊富だ
3. Central configuration: Organizations 統合 + Central configuration により、複数アカウント・複数リージョン横断での標準管理と findings 集約が実現する。Delegated Administrator アカウントから全組織の設定を一元管理できる

Security Hub は Config Conformance Pack と 並行して活用できる。Conformance Pack でカスタムルールや修復ワークフローを管理しつつ、Security Hub で findings の severity 評価・アラート連携するという組み合わせが典型的なパターンだ。

重要な注意点: Security Hub が対応するスタンダードも SOC2 (SSAE-18 の完全版) / GDPR は網羅していない。SOC2/GDPR のギャップには前述のサードパーティ GRC ツール (§6-1) が依然として必要だ。

Security Hub を有効化する CLI 手順 (参考):

# Security Hub を有効化 (リージョン指定が必要)
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region ap-northeast-1

# 有効なスタンダードを確認
aws securityhub describe-standards \
  --region ap-northeast-1 \
  --query 'Standards[*].{Name:Name,StandardsArn:StandardsArn}'

# NIST 800-53 Rev 5 スタンダードを有効化する例
aws securityhub batch-enable-standards \
  --standards-subscription-requests '[{"StandardsArn":"arn:aws:securityhub:ap-northeast-1::standards/nist-800-53/v/5.0.0"}]'

Security Hub の中央構成 (Central configuration) を利用すると、Organizations の管理者アカウントから全メンバーアカウントのスタンダードを一括で有効化・無効化できる。Audit Manager の Delegated Administrator で行っていた「組織全体のフレームワーク管理」と同等の集中管理が Security Hub でも実現する。

なお、Security Hub の findings は Amazon EventBridge と統合されており、非準拠リソースの検出時に Lambda・SNS・Slack 等への通知パイプラインを構築できる。Audit Manager では通知機能が限定的だったが、Security Hub + EventBridge による通知連携はより柔軟な運用監視を実現する。

6-3. AWS Control Tower — controls-only experience

AWS Control Tower は組織的なガバナンス制御を OU (Organizational Unit) 単位で展開するサービスだ。従来は Landing Zone (組織全体のセキュアなマルチアカウント基盤) のセットアップが前提だったが、controls-only experience の提供により、Landing Zone を前提とせずにコントロールのみを利用できるようになった。

controls-only experience の主な特徴:

• Landing Zone 不要: 既存の AWS Organizations 環境にコントロールのみを追加適用できる
• コントロールライブラリ: AWS が管理する予防的・検出的・プロアクティブなコントロールをフレームワーク別に選択して OU に適用できる
• 実装技術: 検出的コントロールは Config Rules として実装される
• AWS Organizations ネイティブ: OU 単位のガバナンスが Organizations 構造に直接紐づく

Conformance Pack との重要な違い:

Control Tower controls-only は、既存の Organizations 構造を維持しながら AWS のベストプラクティスコントロールを迅速に展開したい場合に適している。ただし remediation ワークフローは非対応 であり、Config Conformance Pack が持つ「自動修復」機能は使用できない点に注意が必要だ。自動修復が必要なコントロールには Conformance Pack を、AWS 管理の標準コントロールを OU 単位で迅速適用したい場合には Control Tower controls-only を使い分けるのが実用的だ。

6-4. Organizations 横断ガバナンス — Delegated Admin での集中管理

Config Conformance Pack を Organizations 全体に展開する場合は、Organization Conformance Pack と Delegated Administrator を組み合わせた集中管理構成が推奨される。

Organization Conformance Pack の特徴:
– Management Account または Delegated Administrator アカウントから全メンバーアカウントに Conformance Pack を一括展開できる
– 各メンバーアカウントでの個別デプロイが不要になり、ガバナンスを集中管理できる
– 特定のアカウントを --excluded-accounts で除外できる

Delegated Administrator の設定と Organization Conformance Pack のデプロイ例:

# Config の Delegated Administrator を設定 (Management Account から実行)
aws organizations register-delegated-administrator \
  --account-id {delegated-account-id} \
  --service-principal config.amazonaws.com

# Organization Conformance Pack のデプロイ (Delegated Admin から実行)
aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name "pci-dss-v4" \
  --template-s3-uri "s3://{bucket}/conformance-packs/pci-dss-v4.yaml" \
  --excluded-accounts {account-id-to-exclude}

移行時の注意点: Audit Manager の Delegated Administrator 設定は Config の Delegated Administrator とは独立して管理されている。移行後に Config の Delegated Administrator を設定する場合は、既存の Audit Manager 設定とは別に設定する。また、Audit Manager を無効化する際も組織展開していた場合は Management Account から行う必要がある (Delegated Administrator アカウントには既定で無効化権限がない)。

6-5. ギャップ補完の統合アーキテクチャ — 三層構成

実際の移行後の環境では、「Config Conformance Pack + Security Hub + サードパーティ GRC ツール」の三層構成が推奨されるアーキテクチャだ。それぞれが異なるレイヤーの役割を担うことで、Audit Manager が単体で提供していた「複数フレームワーク横断の統合管理」を再現できる。

【三層コンプライアンス構成】

Layer 1: Config Conformance Pack (技術的 Core Controls)
  ├── インフラリソースの設定継続監視
  ├── 非準拠リソースの自動修復 (remediation)
  └── Advanced Query / Athena による証跡エクスポート

Layer 2: AWS Security Hub CSPM (セキュリティ評価・通知)
  ├── NIST/PCI-DSS/HIPAA/CIS 等の標準化 findings
  ├── Severity 付き優先度評価
  └── EventBridge 経由のアラート連携

Layer 3: サードパーティ GRC ツール (組織的コントロール管理)
  ├── SOC2 / GDPR / ISO 27001 の完全な監査統制
  ├── 人的プロセス証跡・ポリシー管理
  └── 外部監査人向けポータル・レポート出力

この三層構成において、Layer 1 の Config は Layer 2 の Security Hub と統合される (service-linked rules により Config Rules が Security Hub の findings の源泉になる)。Layer 3 のサードパーティ GRC ツールは Layer 1/2 から技術的コントロールの評価結果を API 経由で取り込み、組織的コントロールと統合したダッシュボードを提供する。

三層構成での コスト最適化の観点: Audit Manager は単一サービスの料金で複数フレームワークをカバーしていたが、三層構成では各レイヤーのコストが独立する。Config の評価コスト (Config Rule 評価回数課金)・Security Hub の findings 処理コスト・GRC ツールのライセンス費用を合算して TCO を試算したうえで移行可否を判断することを推奨する。

SOC2/GDPR を現在 Audit Manager で管理していない場合: これらのフレームワークを Audit Manager で扱っていなければ、Layer 3 のサードパーティ GRC ツールは不要だ。Config Conformance Pack + Security Hub の二層で十分にカバーできる。無駄なコストを避けるため、現行の Audit Manager Assessment のフレームワーク棚卸し (§4-1) を移行設計の最初のステップとして必ず実施する。

補完手段の選定フローまとめ:

移行対象フレームワークが確定したら、以下の順序で補完手段を選定する。

1. §3 のマッピング表で Conformance Pack 対応テンプレートの有無を確認する
2. 対応テンプレートあり → Config Conformance Pack をデプロイ。必要に応じ Security Hub を並行稼働
3. 対応テンプレートなし (SOC2/GDPR/ISO27001 等) → サードパーティ GRC ツールの導入を計画する
4. 複数フレームワーク混在の場合 → 三層構成 (Config + Security Hub + GRC ツール) で対応する

7. 移行ロードマップ・チェックリスト

7-1. 移行フェーズ設計

フェーズ1: 評価 (2〜4週間)

移行可否と優先度を判断するための棚卸しフェーズ。現状把握なしに移行計画を立てると、カスタムコントロールのギャップや組織アカウントの対応漏れが後から発覚し手戻りが生じる。

主な作業:

• 現在稼働中のすべての Audit Manager Assessment を一覧化する
• 各 Assessment に紐づくフレームワーク・コントロール・対象アカウント・対象リージョンを記録する
• 各フレームワークに対応する Config Conformance Pack の有無を §3 の対応表で確認する
• 対応 Pack がないフレームワーク (SOC2/GDPR/ISO 27001 等) はギャップとして記録し、補完手段を §6 で選定する
• 現在使用しているカスタムコントロールを抽出し、カスタム Config Rules への移行難易度を評価する

# 現在の Assessment 一覧を確認する
aws auditmanager list-assessments \
  --query 'assessmentMetadata[*].{Name:name,Status:status,Framework:complianceType}' \
  --output table

# カスタムフレームワーク一覧を確認する
aws auditmanager list-assessment-frameworks \
  --framework-type Custom \
  --query 'frameworkMetadataList[*].{Name:name,ControlSets:controlSetsCount}' \
  --output table

評価フェーズの判断基準:

カスタムコントロールが多いほど移行工数は増大する。カスタムコントロールのうち Config Rule として評価可能なもの (例: 特定ポートの開放禁止・暗号化の有無) は移行できるが、「組織がセキュリティポリシーを文書化しているか」のような手動チェック項目は Config では代替できない。この仕分けが移行計画の精度を左右する重要な評価作業だ。

リスク・注意点: 既存カスタムコントロールのギャップ

Audit Manager で定義したカスタムコントロールのうち、Config Rule に直接対応しないものはギャップとなる。ギャップが多い場合は §6 で示したサードパーティ GRC ツール (Vanta/Drata 等) の導入も検討する。

フェーズ2: 計画 (2〜3週間)

評価結果をもとに移行計画を策定するフェーズ。

主な作業:

• 対応 Conformance Pack の選定 (各フレームワークについて)
• ギャップが生じるフレームワークの補完手段を確定する (Vanta/Drata 等のサードパーティ、Security Hub CSPM、Control Tower の組み合わせ)
• 並行運用期間の設計 (最低4週間を推奨。監査イベントや定期レビューのタイミングと重ならないよう調整する)
• Evidence Finder の有効化と証跡エクスポートの実施計画
• CloudTrail data lake の構成・容量見積もり
• 監査レポート代替経路の選定 (Advanced Query / Athena / QuickSight)

計画フェーズの重要ポイント:

移行計画は「いつ Audit Manager を無効化するか」ではなく、「いつ Config Conformance Pack が Audit Manager と同等の運用品質に達するか」を基準にする。並行運用期間中は両ツールの結果を照合し、Config 側の検出に漏れがないかを確認してから無効化に進む。

リスク・注意点: 移行期間の二重管理コスト

並行運用期間中は Audit Manager と Config Conformance Pack の両方を維持するため、運用コスト (人的工数・AWS コスト) が一時的に増加する。並行運用期間を必要最小限に抑えるため、評価フェーズで精度高くギャップを特定することが重要だ。

フェーズ3: 実装 (3〜6週間)

Config Conformance Pack のデプロイと並行運用を開始するフェーズ。

主な作業:

• 選定した Conformance Pack を各アカウント・リージョンにデプロイする
• 組織横断で展開する場合は Organizations Delegated Admin を設定する
• Config Recorder が対象リソースタイプをすべてカバーしていることを確認する
• デプロイ後、Config Conformance Pack のコンプライアンスダッシュボードを Audit Manager のダッシュボードと並べて確認する
• 証跡エクスポート経路 (Advanced Query / get-resource-config-history / Athena) をテストし、監査レポートとして利用可能な状態にする
• Evidence Finder を有効化し、証跡を CloudTrail data lake へエクスポートする

Conformance Pack のデプロイ自体は Terraform で一元管理できる。Config Recorder 設定・HCL コード・SSM Automation の実装詳細は実装ハンズオン記事を参照。

フェーズ4: 検証 (4〜8週間)

並行運用を通じて Config Conformance Pack の精度・カバレッジを検証するフェーズ。このフェーズを短縮することは推奨しない。移行後に不備が発覚すると、監査レポートの再提出が必要になるリスクがある。

主な作業:

• Audit Manager の Assessment 結果と Config Conformance Pack の結果を毎週比較し、乖離を記録する
• 乖離が発生した場合はその原因を特定する (Config Rule の誤設定・リソースタイプの未対応・スコープ差異)
• カスタム Config Rules が正常に機能していることを確認する
• 証跡エクスポートを実際の監査報告に使用し、監査人・コンプライアンス担当者からのフィードバックを得る
• SOC2/GDPR ギャップについては補完ツール (Vanta/Drata 等) の導入・検証を並行して行う

検証フェーズの完了判断基準:

以下がすべて満たされた時点で完了フェーズに移行する。

1. Config Conformance Pack のコンプライアンス結果が Audit Manager と一致またはそれ以上の精度を示している
2. 監査レポートの代替経路が確立され、実際の監査報告で使用できる状態になっている
3. ギャップフレームワーク (SOC2/GDPR 等) の補完手段が稼働している
4. Evidence Finder での証跡エクスポートが完了している

フェーズ5: 完了 (1〜2週間)

Audit Manager の安全な無効化と移行完了の確認フェーズ。

主な作業:

• Evidence Finder での全証跡エクスポートが完了していることを最終確認する
• 既存証跡は収集日から2年間保持されることを確認する (明示削除しない限り)
• Audit Manager を無効化する (7-3 を参照)
• 移行完了を監査人・関係部門に通知する
• Config Conformance Pack の定期モニタリング・アラート設定を最終確認する

7-2. 証跡退避: Evidence Finder → CloudTrail data lake

Audit Manager を無効化する前に、既存の監査証跡 (evidence) を安全に保全する手順が必要だ。Evidence Finder を活用することで、収集済みの証跡を CloudTrail Lake にエクスポートし、Audit Manager 無効化後もクエリ可能な状態を維持できる。

Evidence Finder の有効化

Evidence Finder は Audit Manager の設定タブから有効化する。有効化すると、Audit Manager が収集した証跡データを CloudTrail Lake のイベントデータストアに格納し始める。

# Evidence Finder の有効化状態を確認する
aws auditmanager get-settings \
  --attribute EVIDENCE_FINDER_ENABLEMENT \
  --query 'settings.evidenceFinderEnablement'

注意点:

• Evidence Finder の有効化には初期インデックス作成に数時間かかる場合がある
• 大量の証跡 (数万件以上) がある場合は、有効化から完全にエクスポートされるまでの時間を考慮して早期に実施する

CloudTrail Lake へのエクスポート

Evidence Finder 有効化後、Audit Manager コンソールの「サービス設定」>「証跡エクスポート」から CloudTrail data lake へのエクスポートを開始できる。エクスポートされた証跡は Athena 互換の SQL でクエリ可能になる。

# CloudTrail Lake のイベントデータストア一覧を確認する
aws cloudtrail list-event-data-stores \
  --query 'EventDataStores[*].{Name:Name,Status:Status,RetentionPeriod:RetentionPeriod}' \
  --output table

無効化後の証跡保持について

Audit Manager を無効化した後も、既存の証跡は収集日から2年間 (730日) 保持される。ただし CloudTrail data lake にエクスポートしておくことで、2年の保持期間を超えた長期保管も可能になる。監査対応や規制要件によって必要な保持期間が異なるため、事前にポリシーを確認しておくことを推奨する。

なお、無効化は新規証跡の収集を停止するが、既存の収集済み証跡は削除されない。Audit Manager の再有効化 (re-enable) 自体は技術的に可能だが、メンテナンスモード移行後の再有効化は既存顧客の単一アカウント利用範囲内に限定される。

7-3. Audit Manager 無効化手順

移行完了フェーズで Audit Manager を無効化する際の手順と注意点を整理する。

コンソールからの無効化手順

1. AWS マネジメントコンソールで Audit Manager を開く
2. 左ナビゲーションの「設定 (Settings)」をクリックする
3. 「Audit Manager を無効にする (Disable AWS Audit Manager)」ボタンをクリックする
4. 無効化の影響範囲を確認するダイアログが表示される
5. 影響内容を確認した上で「無効にする」を実行する

CLI からの無効化

# 単一アカウントの Audit Manager を無効化する
aws auditmanager deregister-account

# 組織展開がある場合: Delegated Administrator の設定を先に解除する
aws auditmanager deregister-organization-admin-account \
  --admin-account-id <delegated-admin-account-id>

組織展開時の順序

Organizations で Delegated Administrator を設定している場合、無効化の順序が重要になる。

1. まず Delegated Administrator のアカウントから Audit Manager の設定を解除する
2. 次に Management Account から Audit Manager を無効化する

Delegated Administrator アカウントには Audit Manager の無効化権限がデフォルトで付与されていないため、Management Account から操作する必要がある。この順序を誤ると「正しく無効化されているか」の確認が複雑になるため注意が必要だ。

無効化後に残るもの

8. まとめ

本記事では、AWS Audit Manager の2026年4月30日メンテナンスモード移行を受けて、監査・コンプライアンス・GRC 担当者が移行の判断・設計・実行をするための情報を整理した。

8-1. 本記事の要点

ポイント1: メンテナンスモード移行は「終了」ではなく「進化の停止」

2026年4月30日以降、AWS Audit Manager は新規アカウントでのセットアップが不可になるが、既存顧客は継続利用できる。ただし新機能・新フレームワーク・新リージョン対応は行われないため、中長期的には移行が現実的な選択肢になる。「今すぐ使えなくなる」という誤解を防ぎ、計画的な移行を選択することが重要だ。

ポイント2: Config Conformance Packs が公式推奨の移行先であり「remediation」という新メリットがある

AWS 公式が移行先として推奨する Config Conformance Packs は、Audit Manager にはなかった自動修復 (remediation) 機能を持つ。「検出するだけ」から「検出して自動修復する」への進化が移行の大きなメリットになる。Conformance Pack テンプレートは100種以上あり、PCI DSS / HIPAA / NIST 800-53 / FedRAMP / CIS 等に対応している。

ポイント3: SOC2 / GDPR / ISO 27001 は Config 単独では代替できない

最も重要なギャップがここにある。SOC2 (SSAE-18)・GDPR・ISO 27001 に対応する Conformance Pack テンプレートは存在しない。これらのフレームワークで Audit Manager を運用してきた組織は、Config Conformance Pack 単独での移行は不十分であり、Vanta・Drata 等のサードパーティ GRC ツールの併用が必要になる。「Config だけで全フレームワーク準拠が完結する」という誤解は特に注意が必要だ。

ポイント4: 証跡は Advanced Query / Athena / API で代替し、Evidence Finder で退避する

Audit Manager の PDF/CSV 監査レポートに直接相当する機能は Config にない。代替として Config Advanced Query (SQL エクスポート)・get-resource-config-history API (変更履歴)・Athena + QuickSight (横断分析) の3経路を活用する。また Audit Manager 無効化前に Evidence Finder を有効化し、証跡を CloudTrail data lake にエクスポートしておくことで、無効化後もアクセスを維持できる。

ポイント5: 段階的な並行運用で安全に移行する

移行は一度の切り替えではなく、評価→計画→実装→検証→完了の5フェーズで進める。検証フェーズでは Audit Manager と Config Conformance Pack の結果を並べて比較し、Config 側のカバレッジを確認してから Audit Manager を無効化する。並行運用期間は最低4週間を確保することを推奨する。

8-2. 次のステップ

移行設計の全体像を把握したら、次のアクションに進もう。

Config Conformance Pack の Terraform 実装を始める方:

本記事で設計した移行先の実装詳細 — Config Recorder・Delivery Channel・3種 Conformance Pack 同時適用・SSM Automation・Lambda Remediation の Terraform HCL コード — は以下の実装ハンズオン記事に詳説している。

AWS セキュリティ運用の全体像を学ぶ方:

Audit Manager・Config・Security Hub・CloudTrail 等のセキュリティサービスを統合した運用の全体像を把握したい方は、以下の AWS セキュリティ運用ファンダメンタルズ記事を参照。

移行の判断・設計の段階で本記事の情報を活用し、実装フェーズでは各専門記事を参照することで、Audit Manager から Config Conformance Packs への安全かつ確実な移行が実現できる。

8-3. 公式ドキュメントと移行サポートリソース

移行を進める上で参照すべき AWS 公式ドキュメントを以下にまとめる。

Audit Manager 関連:

• AWS Audit Manager ユーザーガイド (メンテナンスモード情報含む) — メンテナンスモードの詳細と移行の FAQ が記載されている
• Evidence Finder ユーザーガイド — CloudTrail data lake へのエクスポート手順の詳細
• Audit Manager の無効化手順 — コンソール・CLI での無効化ステップと組織展開時の注意点

Config Conformance Packs 関連:

• AWS Config Conformance Pack サンプルテンプレート一覧 — フレームワーク別のマネージドテンプレートを確認できる
• Comparing compliance solutions (公式比較表) — Audit Manager と Conformance Pack の機能比較・移行ガイド
• Organization Conformance Pack 展開ガイド — 複数アカウント展開の詳細手順

移行サポート:

AWS Professional Services や AWS Partner Network (APN) のパートナーを通じた移行支援も提供されている。SOC2/GDPR のギャップ補完ツール (Vanta/Drata 等) の導入支援も APN パートナーが対応しているケースが多い。大規模な組織展開や複雑なカスタムコントロールの移行が必要な場合は、AWS サポートへの問い合わせも検討してほしい。

移行は準備が整った段階から着手できる。まずは評価フェーズの Assessment 棚卸しから始め、自社のフレームワーク構成・カスタムコントロールの状況を把握することが、安全な移行計画の第一歩となる。