はじめに
AWS上の通信はNitro Systemによって暗号化される。
そう聞くと、「ではVPC Encryption Controlsは何をする機能なのか」と疑問に思うかもしれません。
VPC Encryption Controlsは、新しい暗号アルゴリズムではありません。VPC内やVPC間の通信について、暗号化状態を監視し、暗号化を保証できないリソースを特定し、Enforceでは暗号化されない構成を制限するための仕組みです。
ただし、Monitorで「暗号化」と表示された通信がEnforceでも必ず許可されるわけではありません。Flow Logsのapplication-encryptedも、AWSが任意のTLS通信をパケット解析して確認した結果ではありません。
この記事では、VPC Encryption Controlsを「何ができるか」だけでなく、暗号化状態をどう読み、Enforceへ移行できる構成かをどう判断するかという観点から整理します。
VPCの通信はもともとNitroで暗号化されているのではないか
AWSでは以前から、一部のNitroベースEC2インスタンス間で、条件を満たす通信をハードウェアレイヤーで透過的に暗号化できます。
ただし、暗号化にはインスタンスタイプや通信経路などの条件があります。
「条件を満たせば暗号化される」と「暗号化されない構成を許さない」は別です。
VPC Encryption Controlsは、Nitroによるハードウェア暗号化とアプリケーションレイヤーの暗号化を組み合わせ、VPC単位で暗号化状態を監視・強制します。
さらに、Nitroのハードウェア暗号化をFargate、Application Load Balancer、Transit Gatewayなど、EC2以外のAWSサービスへ広げる役割も持っています。
つまり、単なる監視機能ではありません。
AWS基盤側の暗号化範囲を広げながら、その状態をVPC単位で統制する仕組みです。
VPC Encryption Controlsとは｜MonitorとEnforceで何が変わるのか
VPC Encryption ControlsにはMonitorとEnforceがあります。
| モード | 役割 |
|---|---|
| Monitor | 暗号化状態を可視化し、Enforceを阻害するリソースを確認する |
| Enforce | 暗号化を保証できないリソース・サービスの利用を制限する |
既存VPCは、まずMonitorを有効にします。
非準拠リソースを是正するか、必要なExclusionを設定した後でEnforceへ移行します。新規VPCは作成時からEnforceを指定できます。
Enforceは既存通信を後から暗号化するスイッチではない
Enforceを有効にしても、既存リソースの通信へ後から暗号化処理を追加するわけではありません。
例えばRDSでは、Enforce VPCへ転送中暗号化に対応しないDBインスタンスを新規作成しようとすると、APIリクエストがブロックされます。既存ワークロードは動作を継続します。
AWS公式：Working with a DB instance in a VPC
ただしPrivateLinkは注意が必要です。
Enforce VPC内のPrivateLink Endpointでは、アプリケーションレイヤーで暗号化されていないトラフィックが破棄されます。
そのため、「Enforceは新規作成だけを止める」と一律には考えられません。
VPC Flow Logsで暗号化状態を見る｜encryption-statusの3つの落とし穴
VPC Flow Logsではencryption-statusで通信の暗号化状態を確認できます。
| 値 | 意味 |
|---|---|
0 | not encrypted |
1 | nitro-encrypted |
2 | application-encrypted |
3 | Nitro＋application encrypted |
- | 暗号化状態不明、またはEncryption Controls無効 |
なお、一部のネットワークアプライアンスでは暗号化状態を報告できず、encryption-statusが-になる場合があります。
-を即座に平文と判断しないことも重要です。
落とし穴1｜application-encryptedは任意のTLS検査ではない
AWSがapplication-encryptedとして扱う通信は限定されています。
これは、AWSが通信内容を復号してペイロードを検査しているという意味ではありません。Interface EndpointやGateway Endpointでは、AWSはpacket dataを確認せず、使用しているポートから暗号化状態を推定しています。
したがって、
encryption-status=2だから、任意のアプリケーション通信についてTLSを実証した
とは言えません。
逆にOracle NNEなどで暗号化していても、Flow Logs上でapplication-encryptedと判定されるとは限りません。
アプリケーション／DBレイヤーの暗号化は、そのレイヤーの方法で別途確認する必要があります。
落とし穴2｜既存Flow Logsにはencryption-statusが追加されない
Encryption Controlsを有効にしても、encryption-statusは既存Flow Logsへ自動追加されません。
さらにFlow Logは、作成後にrecord formatのフィールドを追加・削除できません。
既存環境でencryption-statusを取得するには、このフィールドを含む新しいFlow Logを作成します。
すでにSIEMや監査基盤へ連携している場合は、新ログの保存先や切替・並走も運用設計に含めます。
落とし穴3｜MonitorのencryptedとEnforceの準拠判定は同じではない
ここが最も重要です。
Monitorでencryptedでも、Enforceでは非準拠になる場合があります。
一つは、AWSサービスが作成したENIを含む通信です。
フロー自体が暗号化されていても、そのAWSサービスがEncryption Controlsをサポートしている必要があります。
もう一つはVPC Peeringです。
Peeringで転送中暗号化を保証するには、同一リージョンの両VPCがExclusionなしのEnforceである必要があります。
逆にMonitorでnot encryptedでも、関連リソースをExclusionにしていればEnforceでは許容される場合があります。
つまり、
Flow Logsのencryption-statusは「そのフローをどう観測したか」
Enforceは「その構成をポリシー上許容できるか」
を見ています。
同じ判定ではありません。
Transit GatewayはEncryption Supportを別途有効化する
Transit Gatewayを利用している場合は、Encryption Supportを明示的に有効化します。
有効化は既存通信を停止せずに行われますが、enablingからenabledになるまで最大14日かかる場合があります。
また、Connect、Peering、Network Firewall、Client VPNなど、Encryption Supportと併用できないAttachmentや機能があります。
AWS公式：Transit Gateway Encryption Support
Encryption Supportを有効化したTGWで、両側のVPCがExclusionなしのEnforceなら、VPC間通信は暗号化された経路を通ります。
一方、
Enforce VPC → Transit Gateway → Monitor VPC
という構成では、暗号化が保証されるのはMonitor側のTGW Attachmentまでです。
その先は宛先リソースに依存します。
図：Enforce VPCからMonitor VPCへTransit Gateway経由で通信する場合の暗号化保証範囲
つまり、TGWを暗号化しただけで相手VPC内部まで暗号化が保証されるわけではありません。
RDSでVPC Encryption Controlsを使うときの注意点
RDSもVPC Encryption Controlsに対応しています。
AWSサービスによって、Enforceへの対応方法は異なります。
NLB、ALB、Fargate、EKS Control Planeは、Monitorを有効にするとAWS側で暗号化対応ハードウェアへ自動移行します。
一方、RDSは必要に応じて利用者がインスタンスクラスを見直すmanual migration側です。
すでに対応クラスなら変更不要ですが、古い非対応クラスではNitro native encryptionに対応したクラスへの変更が必要です。
また、VPCがEnforceでも、Oracle NetがNNEやSSL/TLSで暗号化されていることを意味しません。
RDS for Oracleでは、
- KMSによるRDSストレージ暗号化
- Oracle TDE
- Oracle NetのNNE／SSL/TLS
- AWS基盤側の通信暗号化
は別レイヤーです。
この違いは、以下の記事で整理しています。
導入するならMonitorから始める｜Exclusion・Enforce移行・料金
既存VPCでは、次の順序で進めると整理しやすくなります。
- Monitorを有効にする
encryption-statusを含むFlow Logsを作る- Enforceを阻害するリソースを確認する
- 対応構成へ移行する
- 必要なExclusionを判断する
- PeeringやTGWも確認する
- Enforceへ移行する
EnforceできるかはExclusionと非対応リソースで決まる
Exclusionを設定できるのは8種類だけです。
- Internet Gateway
- NAT Gateway
- Egress-only Internet Gateway
- 非Enforce VPCへのVPC Peering
- Virtual Private Gateway
- VPC内Lambda
- VPC Lattice
- EFS
Exclusionは、「AWSが暗号化済みと保証する」設定ではありません。
利用者がエンドツーエンド暗号化を維持する責任を負う、監査可能な例外です。
Exclusionを設定した通信はVPC Encryption Controlsによる暗号化保証の対象外となるため、AWSの責任共有モデルで見ても、利用者側で暗号化方式と証跡を明示的に管理する必要があります。
一方、Gateway Load BalancerとAWS Network FirewallはEnforce非対応で、これらがあるVPCはMonitorで運用する必要があります。
Local Zone subnetもEnforceでは利用できません。
したがってMonitorの目的は、平文通信を探すだけではありません。
「このVPCをそもそもEnforceへ移行できるのか」
を判断することです。
複数VPC・複数アカウントでは集中管理もできる
Account LevelではUnmanaged、Attempt Monitor、Attempt Enforceを設定でき、複数VPCへまとめて適用できます。
ただしAttempt Enforceは全VPCの移行成功を保証しません。
1つ以上のVPCが期待したモードへ移れなかった状態として、transitions-partially-successfulも定義されています。
AWS公式：AccountVpcEncryptionControl
AWS OrganizationsのDeclarative Policyを使えば、組織・OU・アカウント単位で集中適用することもできます。
Monitorでも料金は発生する
VPC Encryption Controlsは2026年3月1日から有料です。
Network Interfaceを持つnon-empty VPCでMonitorまたはEnforceを有効にすると、固定時間料金が発生します。
TGWでEncryption Supportを有効にした場合は、接続VPCのEncryption Controlsモードに関係なく料金対象になる場合があります。
具体的な単価はリージョンごとの最新料金を確認します。
AWS公式：VPC Encryption Controls pricing
Monitorのまま長期間放置する場合も、コスト設計上は無視できません。
まとめ｜「暗号化されることを期待する」から「暗号化されない構成を許さない」へ
VPC Encryption Controlsで押さえる点は3つです。
- Nitroの自動暗号化とEncryption Controlsによる統制は同じものではない
- Flow Logsの
encryption-statusとEnforceの準拠判定は同じではない - EnforceしてもTLSやOracle NNEなどアプリケーション／DBレイヤーの暗号化設計は別途必要
VPC Encryption Controlsによって、AWSの通信暗号化設計は、
「条件を満たせば暗号化されることを期待する」
から、
「暗号化を保証できない構成を許さない」
へ一段進みました。
導入時はまずMonitorで現在の構成と通信を可視化し、何をAWS基盤側で保証し、何をアプリケーション側で保証するのかを整理したうえでEnforceへ進むのがよいでしょう。
関連記事
VPC Encryption Controlsでは、AWS基盤側の通信暗号化をMonitor／Enforceで監視・強制できますが、実際の通信ではサービスごとの転送時暗号化もあわせて理解しておく必要があります。
特にEFSはVPC Encryption ControlsでExclusionを設定できるリソースの一つであり、ECS／FargateからEFSへ接続する場合は、NFS通信の転送時暗号化がどのように実現されるかを分けて考える必要があります。あわせて確認したい方は、以下の記事も参考にしてください。
- ECS/FargateでEFSが127.0.0.1にマウントされる｜NFSの接続先がlocalhostになる理由
ECS／FargateでEFSの転送時暗号化を有効にすると、NFSの接続先が127.0.0.1として見える理由を、TLSトンネルとEFSマウント処理の仕組みから整理しています。
コメント