VPC Block Public Access（以下VPC BPA）は、VPCとサブネットへのパブリックアクセスをブロックする機能です。リージョン内のVPCがインターネットゲートウェイ（IGW）やエグレスのみのインターネットゲートウェイ（EIGW、送信専用IGW）を通って外部と通信することを、アカウント単位でまとめて禁止します。設定を1回入れれば、以後どのVPCを作っても公開経路が生えません。ここではモードの選び分け、AWS CLIでの有効化と状態確認、除外（exclusion）の作り方と効かない条件、有効化前の影響調査と有効化後の監視、AWS Organizationsでの組織適用までを公式ドキュメントの記述に沿って整理します。
まとめ：VPC BPAで先に押さえる6点
- 適用範囲はアカウント×リージョン単位。VPCごとのスイッチではなく、そのリージョンの全VPCが対象になる。
- モードは
block-bidirectional（IGW・EIGWの出入り全遮断）とblock-ingress（通るのはNATゲートウェイとEIGW経由の通信のみ。IGWへ直接ルーティングしているEC2の外向き通信も止まる）の2つ。 - 例外は「除外」で作る。VPC単位またはサブネット単位で、
allow-bidirectionalかallow-egressを指定する。上限は1アカウント1リージョンあたり50件（引き上げ申請可）。 - 遮断されるのはIGW・EIGWを経由する通信。Site-to-Site VPN、Client VPN、Transit Gateway経由の通信は遮断されない。
- 有効化前の影響はNetwork Access Analyzerの専用テンプレートで洗い出せる。有効化後に落ちた通信はVPCフローログの
reject-reasonがBPAになる。 - 2024年11月19日提供開始で追加料金はなし。組織全体へはAWS Organizationsの宣言型ポリシーで強制できる。
以下、それぞれの設定値と判断基準を順に見ていきます。
2つのモードの遮断範囲と選び分け
モードは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に出入りする通信だけ」です。NATゲートウェイとEIGWは外向きの接続開始しか許さない性質があるためこの2つが残ります。逆に言えば、パブリックサブネットに置いてIGWへ直接ルーティングしているEC2は、外部からのアクセスだけでなく自身からの外向き通信も止まります。「着信だけが止まるモード」と理解していると、パブリックサブネットのインスタンスがパッチ取得に失敗して原因調査から始めることになります。
モード選択の判断基準
OSパッチの取得やSaaS APIの呼び出しなど外向きの通信が必要なワークロードでは、NATゲートウェイ経由に寄せたうえでblock-ingressが現実的な着地点です。外部との通信が一切不要な分析用アカウントや検証用リージョンならblock-bidirectionalまで倒せます。なおblock-ingressは、NATゲートウェイとEIGWを作成できないLocal Zonesではサポートされません。Local Zonesにワークロードがあるリージョンでは、この制約を前提に設計を組む必要があります。
S3のブロックパブリックアクセスとの違い
同じ「ブロックパブリックアクセス」という名前でも、Amazon S3のブロックパブリックアクセスは対象がストレージのアクセス許可です。S3側はBlockPublicAcls、IgnorePublicAcls、BlockPublicPolicy、RestrictPublicBucketsの4設定で、バケットポリシーやACLによる公開を無効化し、組織・アカウント・バケット・アクセスポイントの各レベルで設定します。ネットワーク経路を止めるVPC BPAとは効き方が独立しているため、どちらか一方では代替になりません。S3側の設計はAmazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説で扱っています。
パブリックアクセスをブロックする手順（コンソールとAWS CLI）
コンソールではVPCコンソールの左メニュー「設定」を開き、「パブリックアクセスの設定を編集」から「ブロックパブリックアクセスをオンにする」を選び、方向として「双方向」または「Ingress-only」を指定して保存します。設定が有効になりステータスが更新されるまで数分かかる場合があります。設定できるのは自分が所有するVPCとサブネットで、他アカウントへ共有しているサブネットには所有者側のモードが適用され、参加アカウント側からは変更できません。機能自体は商用の全リージョンに加えGovCloudと中国リージョンでも提供されています。
AWS CLIでの有効化と状態確認
CLIでは有効化と確認を2コマンドで行います。リージョンを明示しないと想定外のリージョンに適用されるため、--regionは必ず付けます。
aws ec2 --region ap-northeast-1 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
aws ec2 --region ap-northeast-1 describe-vpc-block-public-access-options
describeの応答で見るべきフィールドは3つです。Stateはdefault-state、update-in-progress、update-completeのいずれかを返すため、update-in-progressのうちは反映途中と判断します。ManagedByがdeclarative-policyなら組織のポリシーで設定されていてアカウント側では変更できません。ExclusionsAllowedがnot-allowedなら除外を新規作成できません。切り戻しは--internet-gateway-block-mode offです。
CloudFormationで宣言する場合の注意
IaCで管理する場合はAWS::EC2::VPCBlockPublicAccessOptionsでモードを、AWS::EC2::VPCBlockPublicAccessExclusionで除外を宣言します。前者に指定できる値はblock-bidirectionalとblock-ingressだけで、offは既定値のためリソースとして作成できません。つまり「BPAを無効の状態でテンプレートに書き残す」ことはできず、無効化はリソースの削除で表現します。
遮断されるサービスと遮断されない経路
判定基準は「その通信がIGWまたはEIGWを通るか」です。インターネット向けのロードバランサやNATゲートウェイは自身がIGWを必要とするため、BPAの影響を受けます。
| 対象 | 挙動 |
|---|---|
| インターネットゲートウェイ | 受信・送信とも遮断 |
| EIGW（エグレスのみ） | 送信を遮断 |
| NATゲートウェイ | 受信・送信とも遮断 |
| インターネット向けALB・NLB | 受信・送信とも遮断 |
| Gateway Load Balancer | 遮断（要除外） |
| AWS Network Firewall | 遮断（要除外） |
| CloudFront VPC Origins | 受信・送信とも遮断 |
| Direct Connect パブリックVIF | 受信・送信とも遮断 |
| AWS Global Accelerator | 受信を遮断 |
| Wavelength キャリアゲートウェイ | 受信・送信とも遮断 |
「要除外」の2つは、エンドポイントを配置したサブネットを除外しない限り遮断される、という条件付きの挙動です。ロードバランサについて公式一覧が挙げているのは「インターネット向け」のみで、内部向けのALB・NLBはこの一覧の対象外です。
一方、遮断されない経路もあります。Site-to-Site VPN、Client VPN、Transit Gateway、AWS Cloud WAN、Outpostsのローカルゲートウェイ、Verified Accessはいずれも影響を受けません。またRoute 53 ResolverのようにVPC内で完結する私設通信もIGWを通らないため許可されますが、公式ドキュメントはこれらのサービスが利用者に代わってVPC外へ問い合わせる際、VPC内リソースの活動に関する情報が露出しうる点を注意喚起しています。
この「遮断されない側」がVPC BPAの限界です。ピアリングやTransit Gateway越しに来る通信は、たとえ発信元がインターネット寄りでもBPAでは止まりません。境界の作り込みはセキュリティグループとルートテーブルの設計に依存し続けます。ネットワークACLも含めた役割分担は、BPAが「IGW・EIGWという出口の開閉」、ネットワークACLがサブネット境界のステートレスなフィルタ、セキュリティグループがENI単位のステートフルな許可リストという整理になります。初期設計の全体像はAWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説で確認できます。
除外設定の作り方と効かない2つの条件
除外はVPC単位またはサブネット単位で作成し、VPCに張った除外は配下の全サブネットへ自動的に適用されます。BPAが未有効の状態でも先に除外を作成できるため、公開が必要なサブネットの除外を用意してからBPAを有効化すれば通信断を起こしません。AWSのネットワーク系公式ブログも、この順序と、最小権限の観点から可能な場合はサブネット単位の除外を使うことを推奨しています。上限は「VPC Block Public Access exclusions per account per Region」として既定50件で、引き上げはサポートケースで申請します。
allow-bidirectionalとallow-egressの使い分け
除外モードのallow-bidirectionalは除外対象の受信・送信を両方許可します。allow-egressは送信のみ許可して受信は遮断したままにする設定です。公開Webサーバーやインターネット向けロードバランサのサブネットはallow-bidirectional、外向き通信だけを通したいサブネットはallow-egressが対応します。作成と確認のコマンドは次のとおりです。
aws ec2 --region ap-northeast-1 create-vpc-block-public-access-exclusion --subnet-id subnet-0123456789abcdef0 --internet-gateway-exclusion-mode allow-bidirectional
aws ec2 --region ap-northeast-1 describe-vpc-block-public-access-exclusions --exclusion-ids vpcbpa-exclusion-example
--exclusion-idsには作成時の応答に含まれるExclusionIdを渡します。除外にも独自のStateがあり、create-in-progressからcreate-completeへ遷移して初めて有効です。create-failedやdelete-in-progressも返るため、BPA有効化の前に除外を用意する運用ではcreate-completeを確認してから次へ進みます。
除外が効かない2つの条件
公式の検証シナリオは、除外を作っても通信が通らないケースを2つ明示しています。第1に、アカウントのBPAがIngress-onlyのときallow-egressの除外は無視されます。除外先サブネットのIGWへのルーティングはBPAで制限されたままで、外向き通信も遮断されます。公式は「直感に反する」と前置きしたうえで、そのサブネットの外向き通信を通したいならBPAをBidirectionalへ切り替える必要があると書いています。第2に、Bidirectionalモードでは、除外がNATゲートウェイまたはEIGWへの経路を持たない限り通信は遮断されます。除外を張る前に、そのサブネットのルートテーブルがどの出口を向いているかを確認してください。
ロードバランサとアプライアンス構成での落とし穴
インターネット向けロードバランサのサブネットを一部だけ除外してはいけません。公式ドキュメントは、除外されたサブネットでロードバランサが公開トラフィックを受け取り、それを未除外サブネットのターゲットへ内部的に転送しうると明記しています。遮断を成立させるには、ロードバランサが使う全サブネットを除外しないことが条件です。逆に、EC2上のアプライアンスへVPC Ingress Routingで通信を迂回させている構成では、アプライアンス側ではなくワークロード側のサブネットを除外する必要があります。
有効化前の影響調査と有効化後の監視
本番アカウントでBPAを有効化する前に、どの経路が落ちるかを機械的に洗い出せます。ここを飛ばして有効化するのが最も事故になりやすい進め方です。
Network Access Analyzerで落ちる経路を洗い出す
Network Insightsコンソールの「Network Access Scope」作成時に「Assess impact of VPC Block Public Access」テンプレートを選ぶと、アカウント内のIGWを出入りする経路を対象としたスコープが最初から設定された状態で作られます。分析結果の各Findingが、BPA有効化後に遮断される通信経路1本に対応します。ここに現れたVPCまたはサブネットのうち、除外を作らないものが遮断対象です。注意点は3つあります。分析ごとに課金され、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が返ります。
除外の削除をCloudTrailで追跡する
運用フェーズで監査したいのは、誰かが除外を消して公開経路を戻す操作です。公式が示す手順は除外の削除の追跡で、CloudTrailのリソースタイプAWS::EC2::VPCBlockPublicAccessExclusionを指定します。
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::VPCBlockPublicAccessExclusion
設定値の継続的な評価まで含めるならAWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】、検出結果の集約はAWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説が対応します。なおコンプライアンスチェックで「VPC Block Public Access settings should block internet gateway traffic」という文面の項目に遭遇した場合、通過条件はInternetGatewayBlockModeがblock-bidirectionalまたはblock-ingressであることです。
組織全体へ強制する（宣言型ポリシーとControl Tower）
アカウントごとの有効化は、新規アカウントの作成漏れで抜けます。AWS OrganizationsのEC2宣言型ポリシーを使うと、組織単位やOU単位でモードを指定し、メンバーアカウント側からの変更を封じられます。
宣言型ポリシーの記述と値の表記差
ポリシーはec2_attributes配下にvpc_block_public_accessを置く構造で、公式の例は次の形です。
{
"ec2_attributes": {
"vpc_block_public_access": {
"internet_gateway_block": {
"mode": {
"@@assign": "block_ingress"
},
"exclusions_allowed": {
"@@assign": "enabled"
}
}
}
}
}
ここで実装者が引っかかるのがモード値の表記です。CLIとCloudFormationはハイフン区切りのblock-ingress、宣言型ポリシーはアンダースコア区切りのblock_ingressで、同じ設定なのに書式が異なります。exclusions_allowedをdisabledにするとメンバーアカウントは除外を一切作れません。またこのポリシーを適用したアカウントではModifyVpcBlockPublicAccessOptions、CreateVpcBlockPublicAccessExclusion、ModifyVpcBlockPublicAccessExclusionを実行できなくなります。公式はこの一覧を網羅的なものではないと明記しているため、既存の自動化が他のAPIを叩いている場合は個別に検証が必要です。ポリシーの階層と継承の考え方はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説を前提知識として押さえておくと設計しやすくなります。
Control Towerのコントロールで有効化する場合
AWS Control Tower環境なら、コントロールCT.EC2.PV.8を有効にすることで同じ宣言型ポリシーが配布されます。このコントロールは予防的・選択的で既定では無効、有効化するとモードはblock_bidirectional、除外はdisabledが割り当てられます。ただしアーティファクトの各設定には@@operators_allowed_for_child_policiesとして@@allが入っており、子OUやアカウントに適用される宣言型ポリシー側で追加・打ち消し・上書きが可能です。つまり組織のベースラインとして当てつつ、公開が必要なOUだけ子ポリシーで緩める設計が取れます。OU設計そのものはAWS Control Towerとは？マルチアカウント統制の仕組みと導入判断と合わせて検討してください。
BPAだけでは足りない場面と導入の進め方
VPC BPAはIGWとEIGWという2つの出口を閉める機能であり、それ以外の到達経路は評価対象外です。ピアリング接続、Transit Gateway、仮想プライベートゲートウェイから届く通信は、AWSのコントロールリファレンスが明示するとおりBPAでは止まりません。API GatewayやLambdaのようなサーバーレスサービス由来の受信も、IGWやEIGWを通らない限り影響を受けません。オンプレミスや他アカウント側が侵害された場合の横移動は、依然としてセキュリティグループとルートテーブル、そして権限設計の問題です。BPAを入れたことを理由に、AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説で扱う最小権限の詰めやセキュリティグループの棚卸しを緩めるべきではありません。
導入順序は、検証アカウントでblock-bidirectionalを試し、本番では影響調査を行ってから必要なサブネットの除外を先に作り、block-ingressで入れて数日フローログを見る流れが安全です。公式ブログも非本番OUから始めて挙動を検証し、そのうえで本番へ広げる段階展開を推奨しています。いきなり組織全体へblock_bidirectionalを配ると、NATゲートウェイ経由のパッチ取得やコンテナイメージの取得まで落ちて広範囲に影響が出ます。なお除外が50件必要になる構成は、そもそもBPAで守るには公開点が多すぎるという設計上のシグナルとして扱うのが妥当です。
よくある質問
ブロックパブリックアクセスとは何ですか？
AWSでは同名の機能が2つあります。ネットワーク側のVPC BPAと、バケットやオブジェクトの公開許可を無効化するS3のブロックパブリックアクセスです。本記事は前者を扱っています。
VPC BPAの利用に料金はかかりますか？
VPC BPA自体に追加料金はありません。ただし影響調査に使うNetwork Access Analyzerの分析は課金対象で、フローログの保管費用も別途発生します。
除外はいくつまで作れますか？
既定で1アカウント1リージョンあたり50件です。この上限は調整可能で、引き上げにはサービスクォータの増加申請（サポートケース）が必要です。
ingress-onlyにすればEC2からの外向き通信は維持されますか？
NATゲートウェイまたはEIGWを経由する外向き通信は維持されます。IGWへ直接ルーティングしているEC2は外向き通信も遮断されるため、残したい場合はNATゲートウェイ経由の構成に寄せる必要があります。
VPC BPAを有効にすればセキュリティグループの見直しは不要になりますか？
不要にはなりません。遮断されるのはIGWとEIGWを通る通信だけで、VPCピアリングやTransit Gateway、VPN経由の制御はセキュリティグループとルートテーブルが担い続けます。
