---
title: "ブロックパブリックアクセス（VPC BPA）の設定手順：モード選択・除外とSecurity Hub EC2.172の通し方"
url: "https://www.issoh.co.jp/tech/details/4396/"
published: 2024-12-04
updated: 2026-11-03
categories: ["AWS"]
publisher: "株式会社一創"
---

# ブロックパブリックアクセス（VPC BPA）の設定手順：モード選択・除外とSecurity Hub EC2.172の通し方

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の公式ガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)）。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とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](/tech/details/15433/)、AMIの共有設定は[AWS AMIとは？スナップショットとの違い・種類・料金と作成から削除までの手順【2026年10月】](/tech/details/17998/)で扱っています。

## block-bidirectionalとblock-ingressの選び方

モードはCLIの`--internet-gateway-block-mode`で指定し、値は`off`、`block-bidirectional`、`block-ingress`の3つです。コンソールではそれぞれ「オフ」「双方向」「Ingress-only」と表示されます。`block-bidirectional`は、除外したVPCとサブネットを除き、そのリージョンのIGWとEIGWに出入りする全トラフィックを止めます。

### block-ingressで残る通信と止まる通信

[公式の定義](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa.html)では、`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](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html)）。

### 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`で宣言します。[リソースリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-ec2-vpcblockpublicaccessoptions.html)の許容値は`block-bidirectional`と`block-ingress`だけで、`off`は既定値なので作成できません。無効化はスタックからリソースを消して表現します。AWS CDKのL1コンストラクト`CfnVPCBlockPublicAccessOptions`も同じ制約を受けます。

TerraformではAWS Provider v5.79.0で追加された[aws\_vpc\_block\_public\_access\_options](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc%5Fblock%5Fpublic%5Faccess%5Foptions)と`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](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#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との違い・料金と有効化手順を実装者目線で解説](/tech/details/15890/)、Configルールの料金は[AWS Configとは？設定変更の記録・ルール評価・料金の実額と導入判断をCLI設定例つきで解説【2026年時点】](/tech/details/15616/)で確認できます。

## 遮断されるサービスと遮断されない経路

判定基準は「その通信が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つの条件

公式の[検証シナリオ](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-example.html)は、除外を作っても通信が通らないケースを2つ示しています。1つ目は、アカウントのBPAがIngress-onlyのとき`allow-egress`の除外が無視されることです。除外先サブネットのIGWへのルーティングは制限されたままで、外向き通信も止まります。公式は「直感に反する」と前置きしたうえで、外向きを通したいならBPAをBidirectionalへ切り替える必要があると書いています。2つ目は、Bidirectionalで`allow-egress`の除外を使う場合、NATゲートウェイかEIGWを経由しない通信は遮断されることです。`allow-bidirectional`の除外には、この制約はありません。除外を張る前に、そのサブネットのルートテーブルがどの出口を向いているかを確かめてください。

### ロードバランサ・アプライアンス・リージョナルNATの除外先

ロードバランサ配下のターゲットへのパブリックアクセスを完全に遮断したい場合は、ロードバランサのどのサブネットも除外してはいけません。除外したサブネットでロードバランサが公開トラフィックを受け、それを未除外サブネットのターゲットへ内部的に転送できてしまうためです。VPC Ingress RoutingでEC2上のアプライアンスへ通信を迂回させている構成では、アプライアンス側ではなくワークロード側のサブネットを除外します。

リージョナルNATゲートウェイは[パブリックサブネットを必要としない独立したリソース](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateways-regional.html)なので、サブネット単位の除外では指定先がありません。VPC BPAのガイドにはリージョナルNATの記述がまだ無く、[クラスメソッドの2026年3月の検証](https://dev.classmethod.jp/articles/reginal-nat-gateway-vpc-block-public-access/)では、双方向ブロック下でVPC単位の`allow-egress`除外を作ったところ外向き通信が通っています。サブネット単位より粒度が粗くなるため、リージョナルNATを使うVPCでは`block-ingress`を選ぶか、VPC単位の除外を前提に公開サブネットの有無を見直します。NATゲートウェイの構成は[NAT Gatewayの構築手順とリージョナル移行：AZ設計とポート枯渇の実装対処](/tech/details/17747/)にまとめています。

## 集中型エグレス・イングレスとの組み合わせ

除外が増えるほどBPAの効き目は薄れます。AWSのネットワークブログ（[2026年5月11日](https://aws.amazon.com/blogs/networking-and-content-delivery/enhanced-security-with-dmz-architecture-using-amazon-vpc-block-public-access/)）が示す型は、インターネットとの出入口を専用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年の新機能](/tech/details/4263/)を参照してください。

### SCPでIGW作成を禁止する方法との違い

従来はSCPで`ec2:CreateInternetGateway`や`ec2:AttachInternetGateway`を拒否して公開経路を作らせない方法が使われてきました。SCPはAPI呼び出しを止めるだけなので、すでにIGWが付いているVPCの通信には影響しません。BPAは既存のIGWがあっても通信そのものを止め、VPC・サブネット単位の除外も持てます。既存環境の公開経路を閉じたいならBPA、新しい公開経路の作成自体を禁じたいならSCP、と役割が分かれるため、両方を併用する設計が取れます。SCPの書き方は[AWS SCPの書き方と適用手順：JSON例・CLI・Terraform・検証の切り分けまで解説](/tech/details/18038/)で扱っています。

## 有効化前の影響調査と有効化後の監視

必要な公開経路と除外を確認せずに本番で有効化すると、既存ワークロードの通信を遮断するおそれがあります。[影響調査と監視の手順](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-assess-impact-main.html)は公式に揃っています。

### 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ポリシーの公式例](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-policy-examples.html)が扱う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・アカウント単位でモードを配り、メンバー側の変更を封じられます。

### 宣言型ポリシーの書き方と値の表記差

[構文ページ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs%5Fmanage%5Fpolicies%5Fec2%5Fsyntax.html)の例は次の形です。

```
{
  "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・一括請求の仕組みと設計判断を実装者目線で解説](/tech/details/15618/)が前提になります。

### 宣言型ポリシーの適用順序・設定値と通信への影響

AWSのネットワークブログ（[2026年3月25日](https://aws.amazon.com/blogs/networking-and-content-delivery/deploy-vpc-block-public-access-across-aws-organizations/)）は、組織へ配る順序と結果を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](https://docs.aws.amazon.com/controltower/latest/controlreference/ct-ec2-pv-8.html)を有効にすると同じ宣言型ポリシーが配られます。既定は無効で、有効化するとモードは`block_bidirectional`、除外は`disabled`になります。アーティファクトの各設定には`@@operators_allowed_for_child_policies`として`@@all`が入っており、子OUやアカウント側の宣言型ポリシーで上書きできます。公開が必要なOUだけ子ポリシーで緩める設計が取れます。OU設計は[AWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断をCLI例つきで解説](/tech/details/15623/)と合わせて検討してください。

## BPAで守り切れない場面と導入の順番

VPC BPAが閉めるのはIGWとEIGWの2つの出口だけです。オンプレミスや他アカウントからの横移動は、セキュリティグループ、ルートテーブル、[AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](/tech/details/15427/)で扱う最小権限の問題のままです。BPAを入れたことを理由にセキュリティグループの棚卸しを緩めてはいけません。

導入は、検証アカウントで`block-bidirectional`を試し、本番ではNetwork Access Analyzerで影響を調べて除外を先に作り、`block-ingress`で入れて数日フローログを見る順が安全です。除外が既定上限の50件に近づいたら、各除外の必要性と対象範囲を棚卸しし、枠を増やす前に集中型エグレス・イングレスへ寄せる設計変更を検討します。VPCの初期設計から見直すなら[AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説](/tech/details/15359/)が出発点になり、マルチアカウントのネットワーク設計を外部に任せる場合は[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)も相談先の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経由の制御はセキュリティグループとルートテーブルが担い続けます。

## 関連記事

- [AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説](/tech/details/15359/)
- [AWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説](/tech/details/15890/)
- [AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説](/tech/details/15618/)
- [AWS Transit Gatewayとは？VPC Peeringとの違い・TGW Peering・料金と2026年の新機能](/tech/details/4263/)
- [AWS SCPの書き方と適用手順：JSON例・CLI・Terraform・検証の切り分けまで解説](/tech/details/18038/)

---

出典: [ブロックパブリックアクセス（VPC BPA）の設定手順：モード選択・除外とSecurity Hub EC2.172の通し方](<https://www.issoh.co.jp/tech/details/4396/>)（株式会社一創）