技術記事 2026/8/1

VPC間の伝送中暗号化を組織全体に強制する — 宣言型ポリシーによる一括適用と、監視から強制への移行設計

AWS Organizations の宣言型ポリシーで VPC Encryption Controls を組織全体に適用できるようになりました。SCP・RCPとの効き方の違い、attempt_monitor から attempt_enforce への移行手順、8種類しかない除外リソース、VPCあたりの時間課金までを公式仕様に沿って整理します。

#AWS
#VPC
#セキュリティ
#暗号化
#Organizations
#ガバナンス

2026年7月6日、AWS Organizations の宣言型ポリシーで VPC Encryption Controls を扱えるようになりました。これまで VPC ごとに個別管理していた伝送中暗号化の統制を、組織全体・特定の OU・個別アカウントの単位でまとめて宣言でき、対象は既存・将来の VPC 両方です。本記事では、この機能が何を保証するのか、SCP との違い、監視モードから強制モードへの移行で詰まる場所を公式仕様に沿って整理します。

VPC Encryption Controls は何を保証する機能か

VPC Encryption Controls は、同一リージョン内の VPC 内部・VPC 間の通信（伝送中データ）が暗号化されているかを可視化し、最終的に暗号化されない通信を許さない状態を強制する機能です。HIPAA・FedRAMP・PCI DSS など暗号化が要件の領域で、環境全体の暗号化状態を中央から説明できるようにする狙いがあります。

保存時暗号化のキー管理とはレイヤーが違う点も押さえます。KMS のキー設計は「ディスクのデータを誰が復号できるか」を扱い、こちらは「流れている最中のデータが暗号化されているか」を扱います（キー設計はAWSの暗号化キー、自分で持つべきか）。

暗号化の実現手段はNitro ハードウェア組み込みの伝送中暗号化と**アプリケーション層の暗号化（TLS など）**の2つです。前者は本来 Nitro ベースの EC2 インスタンス同士のものですが、本機能は Fargate・ALB・Transit Gateway にも広げます。

暗号化状態の確認には VPC フローログの encryption-status フィールドを使います。

値	意味
`0`	暗号化されていない
`1`	Nitro による暗号化（VPC Encryption Controls が管理）
`2`	アプリケーション層で暗号化
`3`	Nitro とアプリケーション層の両方で暗号化
`(-)`	状態不明、または暗号化コントロール無効

このフィールドは既存のフローログには自動で追加されず、encryption-status を含むフローログを新規作成する必要があります（移行の最初で見落としやすい点）。

監視モードと強制モード — 移行が一方通行である理由

**監視モード（monitor）**は通信の暗号化状態を可視化し、平文通信を許すリソースを特定します。作成・通信はブロックしません。洗い出しにはコンソールのほか GetVpcResourcesBlockingEncryptionEnforcement が使えます。

**強制モード（enforce）**は VPC 境界内で暗号化されない通信を許す機能を使えなくします。旧世代 EC2 インスタンスなど暗号化を保証できないリソースの作成・アタッチが止まります。

重要なのは既存 VPC は強制モードへ直接移行できない制約です。監視モードで非準拠リソースを改修・除外してから強制モードへ切り替える順序が仕様で強制されます。新規 VPC は最初から強制モードで立ち上げられます。

何が変わったか — 宣言型ポリシーによる一括適用

発表以前も VPC・アカウント単位の設定はできました。変わったのは組織全体・特定の OU・個別アカウントの粒度でまとめて宣言できる点です。既存・将来のすべての VPC が対象になり、「新規 VPC での設定漏れ」を構造的に潰せます。

宣言型ポリシーは SCP とどう違うのか

同じ AWS Organizations のポリシーでも、効く場所が違います。SCP と RCP は認可のレイヤーで働き、API レベルで許可の上限を絞ります。対して宣言型ポリシーは、サービスのコントロールプレーンで望ましい設定そのものを宣言し維持させます。

SCP・RCP・宣言型ポリシーの比較表。SCP・RCPはAPIレベルで許可を絞る認可の仕組みでサービスリンクロールには効かない。宣言型ポリシーはAWSサービスの設定をコントロールプレーンで維持し、サービスリンクロールにも効く。 — 図1: SCP・RCP・宣言型ポリシーは効く層が異なる。排他ではなく併用する

この違いは実務では、新 API が増えても宣言した設定が維持される点（SCP は拒否対象の列挙が漏れやすい）、サービスにリンクされたロールにも効く点（SCP・RCP は統制できない）、デタッチすると付与前の状態に巻き戻る点の3点に表れます（図1）。

なお EC2 系の宣言型ポリシーには、ほかに VPC ブロックパブリックアクセスや IMDSv2 の強制などがあり、いずれも ec2_attributes の下に並べます。

ポリシーの書き方とモードの意味

VPC Encryption Controls の宣言型ポリシーは次の形になります。

{
  "ec2_attributes": {
    "vpc_encryption_control": {
      "mode": {
        "@@assign": "attempt_enforce"
      },
      "exclusions": {
        "@@assign": ["internet_gateway", "nat_gateway", "vpc_lattice"]
      }
    }
  }
}

mode は必須で、取りうる値は3つです。

値	挙動
`unmanaged`	暗号化コントロールを管理しない（オフ）
`attempt_monitor`	対象の全 VPC が監視モードへの移行を試みる。新規 VPC も監視モード
`attempt_enforce`	対象の全 VPC が強制モードへの移行を試みる。新規 VPC は強制モード

attempt_enforce を指定しても、暗号化コントロールが無効な VPC はいったん監視モードを経て自動的に強制モードへの遷移が試みられます。非準拠リソースが残る VPC は監視モードに留まりますが、組織全体の適用が丸ごと失敗するわけではありません。

exclusions はリージョンごとに指定する除外リソースの一覧で、指定できるのは後述の8種類だけです。除外の優先順位は組織 → OU → アカウント → VPC の順で、上位が下位を上書きします。

組織全体への適用手順4ステップと除外の優先順位。STEP1でattempt_monitor適用、STEP2で棚卸し、STEP3で改修または除外定義、STEP4でattempt_enforceへ切り替え。除外の優先順位は組織・OU・アカウント・VPCの順で上位が下位を上書きする。 — 図2: 監視モードで棚卸ししてから強制モードへ。除外は上位の階層が優先される

どの粒度で適用するか — 組織／OU／アカウント

判断の軸は除外が必要なリソースの分布です。上位の除外が下位を上書きするため、組織ルートに広めの除外を付けると本来は不要な OU にも効いてしまい、統制が緩みます。除外の粒度は必要な範囲に寄せるのが筋です。

現実的な進め方は、まず組織全体に attempt_monitor を適用して可視化を揃え、強制モードは OU 単位で段階的に広げる形です。強制モードと併用できないリソース（後述）を持つワークロードは別 OU に切り出せば、そこだけ監視モードに留められます。適用状況はアカウントステータスレポートで確認でき、attempt_enforce へ進める判断材料になります。なお組織レベルのポリシーを付けるとVPC 所有者・アカウント管理者は暗号化コントロールの作成・変更・削除ができなくなるため、開発チームの試行中に被せると作業を止めてしまいます。

移行の実務で詰まる場所

除外できるのは8種類だけです。 インターネットゲートウェイ、NAT ゲートウェイ、egress-only インターネットゲートウェイ、VPC ピアリング接続、仮想プライベートゲートウェイ、VPC 内の Lambda 関数、VPC Lattice、Elastic File System。これ以外は除外できず、非準拠なら改修が要ります。

移行負荷は3段階です。

区分	対象	必要な作業
自動で準拠	PrivateLink 経由の大半の AWS サービス	作業不要（アプリ層で暗号化されない通信は破棄される）
自動で移行	NLB、ALB、Fargate、EKS コントロールプレーン	監視モードを有効にすると AWS が対応ハードウェアへ移行。ただし NLB の TLS リスナーによる暗号化オフロードは強制モードで使えず、ターゲット側での TLS 終端に変える必要がある
手動で移行	EC2、Auto Scaling、RDS、DocumentDB、ElastiCache、Redshift、EKS、ECS on EC2、OpenSearch、EMR	旧世代インスタンスは新世代へアップグレード。Redshift は既存クラスタの VPC を強制モードへ移せずスナップショット復元が要る

個別の制約にも注意します。 Gateway Load Balancer と AWS Network Firewall を含む VPC は強制モードと併用できず監視モードでの運用になります。ローカルゾーンのサブネットも非対応です。ピアリングで暗号化を保証するには両側の VPC が同一リージョン・除外なしの強制モードである必要があり、Transit Gateway は明示的に暗号化サポートを有効化しないと VPC 間通信が暗号化されません。

料金は2階建てです。 宣言型ポリシー自体は無料ですが、VPC Encryption Controls を有効にした非空 VPC には、監視・強制どちらのモードでもリージョン別の時間課金が発生します（米国東部＝バージニア北部で1 VPC あたり1時間 0.15 USD、2026年7月時点）。組織全体への attempt_monitor 適用は非空 VPC すべてに課金が乗ることを意味します。提供リージョン・料金は公式の最新情報で確認してください。

まとめ

VPC Encryption Controls は伝送中データの暗号化を扱い、KMS の保存時暗号化のキー管理とはレイヤーが異なります（encryption-status で可視化）。
宣言型ポリシーは SCP・RCP と効く層が違います。 コントロールプレーンで設定を維持するため、新 API が増えても宣言が保たれ、サービスにリンクされたロールにも効きます。
ロールアウトは監視モードからの一方通行です。 attempt_monitor で棚卸しし、除外8種類とそれ以外を切り分けてから attempt_enforce へ進めます。ポリシー自体は無料でも、非空 VPC には時間課金が発生します。