VPC Block Public Access（以下VPC BPA）は、リージョン内のVPCがインターネットゲートウェイ（IGW）とエグレス専用インターネットゲートウェイ（EIGW）を通って外部と通信することを、アカウント単位でまとめて止める機能です。2024年11月19日に提供が始まり、追加料金はかかりません。Security Hub CSPMでは2025年1月15日にコントロールEC2.172が追加され、「EC2 VPC Block Public Access settings should block internet gateway traffic」という検出は、VPC BPAの設定を見直すきっかけになります。以下、モードの選び方からEC2.172の合格条件、除外が効かない条件、組織へ配る順序までを公式ドキュメントに沿って整理します。
まとめ：VPC BPAで先に押さえる7点
- 設定はアカウント×リージョン単位。そのリージョンの全VPCが対象で、VPCごとのスイッチではない。
- モードは
block-bidirectional（IGW・EIGWの出入りを全遮断）とblock-ingress（NATゲートウェイとEIGW経由の通信だけ残す）の2つ。IGWへ直接ルーティングしているEC2はblock-ingressでも外向き通信まで止まる。 - Security Hub EC2.172は、モードがどちらかになっていれば合格する。パラメータで片方に絞ることもできる。
- 例外は「除外」で作る。VPC単位かサブネット単位で、上限は既定50件。アカウントがIngress-onlyのとき
allow-egressの除外は無視される。 - 遮断されるのはIGW・EIGWを通る通信だけ。Site-to-Site VPN、Transit Gateway、Client VPNなどの私設経路は対象外。
- 有効化前はNetwork Access Analyzerの専用テンプレートで落ちる経路を洗い出し、有効化後はフローログの
reject-reasonがBPAになる記録で確認する。 - 組織へ配るときは、除外を先に作ってから宣言型ポリシーを当てる。逆順や
exclusions_allowedをdisabledにした配布は、既存の公開経路を即座に切る。
AWSの「ブロックパブリックアクセス」4機能の違い
AWSには「ブロックパブリックアクセス」と名の付く機能が複数あり、止める対象が異なります。
| 機能 | 止めるもの | 設定の単位 |
|---|---|---|
| VPC BPA | IGW・EIGW経由の通信 | アカウント×リージョン |
| S3 ブロックパブリックアクセス | ACL・ポリシーによる公開 | 組織・アカウント・バケット・アクセスポイント |
| EBSスナップショット | スナップショットの公開共有 | アカウント×リージョン |
| AMI | AMIの新規公開共有（既存公開は維持） | アカウント×リージョン |
S3側はBlockPublicAclsなど4設定で、組織レベルでは4つをまとめてオン・オフします（S3の公式ガイド）。VPC BPAとは効き方が独立していて、片方がもう片方の代わりにはなりません。Security Hub CSPMのコントロールも別々で、S3はS3.1（アカウント）とS3.8（バケット）、EBSスナップショットはEC2.182、VPC BPAはEC2.172が対応します。AMI側は新規アカウントで既定有効ですが、2023年7月15日以降に公開AMIを持っていたアカウントでは既定で無効です。S3側の設計はAmazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説、AMIの共有設定はAWS AMIとは？スナップショットとの違い・種類・料金と作成から削除までの手順【2026年10月】で扱っています。
block-bidirectionalとblock-ingressの選び方
モードはCLIの--internet-gateway-block-modeで指定し、値はoff、block-bidirectional、block-ingressの3つです。コンソールではそれぞれ「オフ」「双方向」「Ingress-only」と表示されます。block-bidirectionalは、除外したVPCとサブネットを除き、そのリージョンのIGWとEIGWに出入りする全トラフィックを止めます。
block-ingressで残る通信と止まる通信
公式の定義では、block-ingressは「そのリージョンのVPCへ向かう全インターネットトラフィックを遮断し、許可されるのはNATゲートウェイとEIGWに出入りする通信だけ」です。裏返すと、IGWへ直接ルーティングしているパブリックサブネットのEC2は、着信だけでなく自分からの外向き通信も止まります。「着信だけが止まるモード」と誤解したまま入れると、パッチ取得の失敗から原因調査を始めることになります。
ワークロード別のモード選択
OSパッチの取得やSaaS APIの呼び出しなど外向き通信が要るアカウントは、NATゲートウェイ経由に寄せたうえでblock-ingressが現実的な着地点です。外部との通信が一切要らない分析用アカウントや未使用リージョンはblock-bidirectionalまで倒せます。block-ingressはNATゲートウェイとEIGWを作れないLocal Zonesではサポートされないため、該当するLocal Zoneの通信もBPAで制御する場合は、双方向モードと必要な除外を検討します。
VPC BPAを有効化する手順（コンソール・CLI・IaC）
コンソールではVPCコンソールの左メニュー「設定」から「パブリックアクセスの設定を編集」を開き、「ブロックパブリックアクセスをオンにする」と方向（双方向／Ingress-only）を選んで保存します。反映には数分かかります。共有サブネットには所有者側のモードが効き、参加アカウントからは変更できません。提供リージョンは商用の全リージョンとGovCloud、中国リージョンです（VPC BPA basics）。
AWS CLIによるVPC BPAの有効化と状態確認
リージョンを省略すると環境変数や選択中のプロファイルなどから適用先が決まるため、--regionは必ず付けます。
aws ec2 modify-vpc-block-public-access-options \
--region ap-northeast-1 \
--internet-gateway-block-mode block-ingress
aws ec2 describe-vpc-block-public-access-options --region ap-northeast-1応答で見るのは3項目です。Stateがupdate-in-progressの間は反映途中、update-completeで完了です。ManagedByがdeclarative-policyなら組織のポリシーで設定されていて、アカウント側では変更できません。ExclusionsAllowedがnot-allowedなら除外を新規作成できません。切り戻しは--internet-gateway-block-mode offです。
CloudFormationとTerraformで異なるoffの扱い
CloudFormationはモードをAWS::EC2::VPCBlockPublicAccessOptions、除外をAWS::EC2::VPCBlockPublicAccessExclusionで宣言します。リソースリファレンスの許容値はblock-bidirectionalとblock-ingressだけで、offは既定値なので作成できません。無効化はスタックからリソースを消して表現します。AWS CDKのL1コンストラクトCfnVPCBlockPublicAccessOptionsも同じ制約を受けます。
TerraformではAWS Provider v5.79.0で追加されたaws_vpc_block_public_access_optionsとaws_vpc_block_public_access_exclusionを使います。こちらはoffも受け付け、リソースを削除するとアカウントのモードがoffに戻ります。terraform destroyで保護も外れるため、BPAは他と別のステートで管理します。
resource "aws_vpc_block_public_access_options" "this" {
internet_gateway_block_mode = "block-ingress"
depends_on = [aws_vpc_block_public_access_exclusion.public_alb]
}
resource "aws_vpc_block_public_access_exclusion" "public_alb" {
subnet_id = aws_subnet.public_a.id
internet_gateway_exclusion_mode = "allow-bidirectional"
}除外リソースはvpc_idかsubnet_idのどちらかを指定します。モード側のdepends_onで除外の作成を先に済ませ、有効化した瞬間の通信断を避けています。
Security Hub EC2.172の合格条件と検出の解消手順
EC2.172は、AWS基礎セキュリティのベストプラクティス（FSBP）標準に含まれる重要度Mediumのコントロールで、Security Hub CSPMのドキュメント履歴では2025年1月15日に追加されています。評価はAWS Configのカスタムルールec2-vpc-bpa-internet-gateway-blockedによる変更トリガー型です。
合格条件は1つだけで、InternetGatewayBlockModeがblock-bidirectionalかblock-ingressであることです。つまりblock-ingressでも合格します。組織として双方向を必須にしたい場合は、パラメータvpcBpaInternetGatewayBlockModeにblock-bidirectionalを指定すると、そのモードと一致したときだけ合格になります。公式の説明に除外の有無は判定条件として書かれていないため、除外の増えすぎは後述のCloudTrailで別に見ます。
VPC BPAはリージョン単位の設定なので、Security Hubを有効にしているリージョンごとにmodify-vpc-block-public-access-optionsを実行するか、宣言型ポリシーで全リージョンへ配ります。使っていないリージョンの検出は、そこをblock-bidirectionalにするのが最も手早い解消策です。Security Hub自体の有効化と標準の選び方はAWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説、Configルールの料金はAWS Configとは？設定変更の記録・ルール評価・料金の実額と導入判断をCLI設定例つきで解説【2026年時点】で確認できます。
遮断されるサービスと遮断されない経路
判定基準は「その通信がIGWまたはEIGWを通るか」です。インターネット向けロードバランサやパブリックNATゲートウェイのインターネット通信は、BPAの影響を受けます。以下の表は、block-bidirectionalで該当する除外がない場合の挙動です。block-ingressではNATゲートウェイとEIGW経由の通信が許可されます。
| 対象 | 挙動 |
|---|---|
| インターネットゲートウェイ | 受信・送信とも遮断 |
| EIGW | 送信を遮断 |
| NATゲートウェイ | 受信・送信とも遮断 |
| インターネット向けALB・NLB | 受信・送信とも遮断 |
| Gateway Load Balancer | 遮断（エンドポイントのサブネット除外で通る） |
| AWS Network Firewall | 遮断（エンドポイントのサブネット除外で通る） |
| CloudFront VPC Origins | 受信・送信とも遮断 |
| Direct Connect パブリックVIF | 受信・送信とも遮断 |
| AWS Global Accelerator | VPCへの受信を遮断 |
| Wavelength キャリアゲートウェイ | 受信・送信とも遮断 |
遮断されない経路はSite-to-Site VPN、Client VPN、Transit Gateway、AWS Cloud WAN、Outpostsのローカルゲートウェイ、Verified Accessです。Route 53 ResolverのようにVPC内で完結する通信もIGWを通らないため許可されますが、代わりにVPC外へ問い合わせる際に活動情報が外へ出うると公式は注意しています。ピアリングやTransit Gateway越しの通信の制御は、セキュリティグループとルートテーブルの仕事のままです。
除外設定の作り方と効かない2つの条件
除外はVPC単位かサブネット単位で作り、VPCに張った除外は配下の全サブネットに効きます。BPAが無効の状態でも先に作れるので、公開が必要なサブネットの除外を用意してから有効化すれば通信は途切れません。上限は既定50件で、Service Quotasから引き上げを申請できます。
allow-bidirectionalとallow-egressの使い分け
allow-bidirectionalは除外先の受信・送信を両方許可し、allow-egressは送信だけを許可して受信は遮断したままにします。インターネット向けロードバランサのサブネットはallow-bidirectional、NATゲートウェイを置くサブネットのように外向きだけ通したい場所はallow-egressが対応します。
aws ec2 create-vpc-block-public-access-exclusion \
--region ap-northeast-1 \
--subnet-id subnet-0123456789abcdef0 \
--internet-gateway-exclusion-mode allow-bidirectional
aws ec2 describe-vpc-block-public-access-exclusions \
--region ap-northeast-1 \
--exclusion-ids exclusion-id除外はStateがcreate-completeになって初めて効くため、有効化の前にこれを確かめます。
除外を作っても通らない2つの条件
公式の検証シナリオは、除外を作っても通信が通らないケースを2つ示しています。1つ目は、アカウントのBPAがIngress-onlyのときallow-egressの除外が無視されることです。除外先サブネットのIGWへのルーティングは制限されたままで、外向き通信も止まります。公式は「直感に反する」と前置きしたうえで、外向きを通したいならBPAをBidirectionalへ切り替える必要があると書いています。2つ目は、Bidirectionalでallow-egressの除外を使う場合、NATゲートウェイかEIGWを経由しない通信は遮断されることです。allow-bidirectionalの除外には、この制約はありません。除外を張る前に、そのサブネットのルートテーブルがどの出口を向いているかを確かめてください。
ロードバランサ・アプライアンス・リージョナルNATの除外先
ロードバランサ配下のターゲットへのパブリックアクセスを完全に遮断したい場合は、ロードバランサのどのサブネットも除外してはいけません。除外したサブネットでロードバランサが公開トラフィックを受け、それを未除外サブネットのターゲットへ内部的に転送できてしまうためです。VPC Ingress RoutingでEC2上のアプライアンスへ通信を迂回させている構成では、アプライアンス側ではなくワークロード側のサブネットを除外します。
リージョナルNATゲートウェイはパブリックサブネットを必要としない独立したリソースなので、サブネット単位の除外では指定先がありません。VPC BPAのガイドにはリージョナルNATの記述がまだ無く、クラスメソッドの2026年3月の検証では、双方向ブロック下でVPC単位のallow-egress除外を作ったところ外向き通信が通っています。サブネット単位より粒度が粗くなるため、リージョナルNATを使うVPCではblock-ingressを選ぶか、VPC単位の除外を前提に公開サブネットの有無を見直します。NATゲートウェイの構成はNAT Gatewayの構築手順とリージョナル移行：AZ設計とポート枯渇の実装対処にまとめています。
集中型エグレス・イングレスとの組み合わせ
除外が増えるほどBPAの効き目は薄れます。AWSのネットワークブログ（2026年5月11日）が示す型は、インターネットとの出入口を専用VPCに集め、そこだけを除外する構成です。
エグレスVPCだけを除外する構成
アプリケーション用のスポークVPCは双方向ブロックのまま、NATゲートウェイとIGWを置いたエグレスVPCにだけ除外を作り、スポークの0.0.0.0/0をTransit Gatewayへ向けます。Transit GatewayはBPAの対象外なので、スポークからの外向き通信はエグレスVPCのNATゲートウェイを経由して出ていきます。受信側も同じで、インターネット向けALBやNLBを置いたイングレスVPCだけを除外し、Transit Gateway経由でスポークのターゲットへ渡します。除外は出入口の数だけで済みます。Transit Gatewayのルートテーブル設計はAWS Transit Gatewayとは？VPC Peeringとの違い・TGW Peering・料金と2026年の新機能を参照してください。
SCPでIGW作成を禁止する方法との違い
従来はSCPでec2:CreateInternetGatewayやec2:AttachInternetGatewayを拒否して公開経路を作らせない方法が使われてきました。SCPはAPI呼び出しを止めるだけなので、すでにIGWが付いているVPCの通信には影響しません。BPAは既存のIGWがあっても通信そのものを止め、VPC・サブネット単位の除外も持てます。既存環境の公開経路を閉じたいならBPA、新しい公開経路の作成自体を禁じたいならSCP、と役割が分かれるため、両方を併用する設計が取れます。SCPの書き方はAWS SCPの書き方と適用手順：JSON例・CLI・Terraform・検証の切り分けまで解説で扱っています。
有効化前の影響調査と有効化後の監視
必要な公開経路と除外を確認せずに本番で有効化すると、既存ワークロードの通信を遮断するおそれがあります。影響調査と監視の手順は公式に揃っています。
Network Access Analyzerによる遮断対象経路の調査
Network Insightsコンソールで「Network Access Scope」を作るときに「Assess impact of VPC Block Public Access」テンプレートを選ぶと、IGWを出入りする経路を対象にしたスコープができます。分析結果の各Findingが、有効化後に遮断される経路1本に対応し、ここに出たVPC・サブネットのうち除外しないものが遮断対象です。分析は課金対象で、IPv6を扱えないためEIGW経由のIPv6送信への影響はこの手段では見えません。Network Access AnalyzerとReachability Analyzerは、BPA本体と違って全リージョンには提供されていません。
フローログとReachability Analyzerによる遮断原因の確認
有効化後に「落ちたのはBPAが原因か」を切り分けるには、VPCフローログをカスタム形式で作ってreject-reasonフィールドを含めます。BPAで拒否された通信はこの値がBPAになります。BPA起因のレコードにはbytesが入らず、スキップレコードも含まれないため、通信量の集計には使えません。特定経路の単発確認はReachability Analyzerが向いていて、到達不能の理由コードとしてVPC_BLOCK_PUBLIC_ACCESS_ENABLEDが返ります。
除外変更のIAM権限制御とCloudTrailによる追跡
運用中に防ぎたいのは、誰かが除外を足したり消したりして公開経路を変える操作です。IAMポリシーの公式例が扱うVPC BPAのアクションはDescribe系2つと、ModifyVpcBlockPublicAccessOptions、CreateVpcBlockPublicAccessExclusion、ModifyVpcBlockPublicAccessExclusion、DeleteVpcBlockPublicAccessExclusionの計6つです。更新系の4つはネットワーク管理者のロールにだけ許可し、事後の追跡はCloudTrailのリソースタイプAWS::EC2::VPCBlockPublicAccessExclusionで絞り込みます。
aws cloudtrail lookup-events \
--region ap-northeast-1 \
--lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::VPCBlockPublicAccessExclusion宣言型ポリシーとControl TowerによるVPC BPAの組織適用
アカウントごとの設定は新規アカウントで漏れます。AWS OrganizationsのEC2宣言型ポリシーなら、ルート・OU・アカウント単位でモードを配り、メンバー側の変更を封じられます。
宣言型ポリシーの書き方と値の表記差
構文ページの例は次の形です。
{
"ec2_attributes": {
"vpc_block_public_access": {
"internet_gateway_block": {
"mode": { "@@assign": "block_ingress" },
"exclusions_allowed": { "@@assign": "enabled" }
}
}
}
}引っかかりやすいのが値の表記で、CLI・CloudFormation・Terraformはハイフン区切りのblock-ingress、宣言型ポリシーはアンダースコア区切りのblock_ingressです。ポリシーで決められるのは除外を許すかどうかだけで、除外そのものはVPCを所有するアカウント側で作ります。2026年5月のAWSブログの例にはblock_modeやexclusionsといった構文ページに無いキーが使われているため、書くときは構文ページの形に合わせてください。適用したアカウントでは、ModifyVpcBlockPublicAccessOptions、CreateVpcBlockPublicAccessExclusion、ModifyVpcBlockPublicAccessExclusionなどによる、宣言型ポリシーで強制された設定に反する変更が拒否されます。exclusions_allowedがenabledなら、アカウント側で除外を作成できます。既存の自動化は、適用するポリシーの設定値に照らして検証します。継承の考え方はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説が前提になります。
宣言型ポリシーの適用順序・設定値と通信への影響
AWSのネットワークブログ（2026年3月25日）は、組織へ配る順序と結果を4通りに分けています。
- 除外を先に作り、
exclusions_allowedをenabledで配る：通信は途切れない（推奨）。 - 先にポリシーを配り、後から除外を作る：除外ができるまで公開経路が止まる。既存ワークロードの無い新規アカウントなら、この順で安全側に倒してよい。
- 除外を作ってあっても
exclusions_allowedをdisabledで配る：組織のポリシーが優先され、除外していた経路も止まる。 - アカウントがIngress-only、組織がBidirectional：組織の設定が勝ち、アカウントは双方向ブロックに変わる。
配る前には組織のアカウントステータスレポートで現状を確かめます。レポートの生成には最大48時間かかるため、作業日から逆算して依頼しておきます。ポリシーを外すとBPAの設定は付与前の状態に戻るので、切り戻しはデタッチで済みます。
Control Tower CT.EC2.PV.8の既定設定と子ポリシーによる上書き
AWS Control Tower環境では、コントロールCT.EC2.PV.8を有効にすると同じ宣言型ポリシーが配られます。既定は無効で、有効化するとモードはblock_bidirectional、除外はdisabledになります。アーティファクトの各設定には@@operators_allowed_for_child_policiesとして@@allが入っており、子OUやアカウント側の宣言型ポリシーで上書きできます。公開が必要なOUだけ子ポリシーで緩める設計が取れます。OU設計はAWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断をCLI例つきで解説と合わせて検討してください。
BPAで守り切れない場面と導入の順番
VPC BPAが閉めるのはIGWとEIGWの2つの出口だけです。オンプレミスや他アカウントからの横移動は、セキュリティグループ、ルートテーブル、AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説で扱う最小権限の問題のままです。BPAを入れたことを理由にセキュリティグループの棚卸しを緩めてはいけません。
導入は、検証アカウントでblock-bidirectionalを試し、本番ではNetwork Access Analyzerで影響を調べて除外を先に作り、block-ingressで入れて数日フローログを見る順が安全です。除外が既定上限の50件に近づいたら、各除外の必要性と対象範囲を棚卸しし、枠を増やす前に集中型エグレス・イングレスへ寄せる設計変更を検討します。VPCの初期設計から見直すならAWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説が出発点になり、マルチアカウントのネットワーク設計を外部に任せる場合はAWS・Google Cloud・Azureのインフラ構築支援も相談先の1つです。
よくある質問
ブロックパブリックアクセスとは何ですか？
AWSでリソースの公開を一括で止める設定の総称で、VPC、S3、EBSスナップショット、AMIにそれぞれ同名の機能があります。本記事はネットワーク経路を止めるVPC BPAを扱っています。
VPC BPAはどこで設定しますか？
VPCコンソールの左メニュー「設定」にある「ブロックパブリックアクセス」タブです。CLIではaws ec2 modify-vpc-block-public-access-optionsを使います。組織で一括管理する場合はAWS Organizationsの宣言型ポリシーで設定します。
VPC BPAの利用に料金はかかりますか？
VPC BPA自体に追加料金はありません。影響調査に使うNetwork Access Analyzerの分析と、フローログの保管には別途費用がかかります。
block-ingressにすればEC2からの外向き通信は維持されますか？
NATゲートウェイかEIGWを経由する外向き通信は維持されます。IGWへ直接ルーティングしているEC2は外向きも止まるため、残したい場合はNATゲートウェイ経由の構成に寄せます。
VPC BPAを有効にすればセキュリティグループの見直しは不要になりますか？
不要にはなりません。止まるのはIGWとEIGWを通る通信だけで、VPCピアリング、Transit Gateway、VPN経由の制御はセキュリティグループとルートテーブルが担い続けます。
