VPC Block Public Access と CloudFront VPC Origins を使ってみて気づいた色々な勘所

はじめに

毎年開催されるAWSのイベント「re:Invent」では沢山の新サービス、新機能が発表されます。
また、例年re:Inventの開催前から非常に沢山の発表が行われます。

開催前の発表は「予選落ち」と称されることもありますが、実はこの予選落ちな発表の中には注視すべき発表が潜んでいることがあります。

この記事では、re:Invent 2024の予選落ちアップデートの中で私が特に気になった新機能を2つ取り上げたいと思います。

この2つは今後のアーキテクチャ設計に大きな影響を与える新機能だと感じたので、実際に触ってみて感じた勘所も交えて紹介していきたいと思います。

なお、この記事の内容をもとに社内の勉強会で登壇もしています。資料もアップロードしているので、ご興味がある方はこちらの資料も合わせてご覧いただければと思います。

VPC Block Public Accessとは

まずご紹介する1つ目の新機能は「VPC Block Public Access（以下、BPAと呼称）」です

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/block-public-access-amazon-virtual-private-cloud/

BPAは、VPCとインターネットの間の通信をブロックすることに特化した機能です。
従来はセキュリティグループやNACLを使用してインターネットとの通信制御を行っていましたが、セキュリティグループやNACLよりも優先される強力な設定となっています。

BPAはリージョン単位で設定をするため、「このリージョンにあるVPCはすべて、インターネットとの通信を完全に遮断する」という設定が簡単にできます。

BPAの設定には以下2種類の設定があります。

双方向：インターネットからVPCへのインバウンド通信、VPCからインターネットへのアウトバウンド通信を両方ブロック
Ingress-only：インターネットからVPCへのインバウンド通信のみブロック

また、特定のサブネットをBPAの設定から除外するという設定もでき、除外する通信の方向も以下2種類から設定可能です。

双方向：インターネットからVPCへのインバウンド通信、VPCからインターネットへのアウトバウンド通信を両方とも除外対象にする
Egress-only：VPCからインターネットへのアウトバウンド通信のみを除外対象とする

CloudFront VPC Originsとは

次に紹介する機能は「CloudFront VPC Origins」です

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/amazon-cloudfront-vpc-origins/

これはプライベートサブネットにあるALB、NLB、EC2をCloudFrontのオリジンに設定できるという機能です。

AWS上でWebサーバーを稼働させてCDNにCloudFrontを利用するという構成をとる場合、従来はELBをパブリックサブネットに配置する必要がありました。

しかしCloudFront VPC Originsを使用すると、ELBをプライベートサブネットに配置することが可能になります。

構成図に書いてあるように、自動的に作成されるENIを経由してプライベートサブネットにあるELBとCloudFrontが繋がるという仕組みになっています。

このような構成にすると、インターネットに露出するリソースを減らすことができるだけでなく、パブリックIPを利用しなくて良くなります。

AWSでは、2024年の2月からELBで使用されるパブリックIPにも課金されるようになっています。
https://aws.amazon.com/jp/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/

CloudFront VPC Originsを利用することでパブリックIP課金を削減することができるので、コスト削減効果も見込める新機能となっています。

実際に触ってみた

ここから、実際に2つの機能を触って検証してみた内容を記載していきます。

なお、今回の検証は以下の公式ブログの内容を参考に実施していますので、合わせてご覧ください。

https://aws.amazon.com/jp/blogs/news/vpc-block-public-access/

検証に使用する構成

まずは、Webサーバーを構築する際によくある構成で検証環境を構築してみました。

VPCとELBはデュアルスタックで構成し、インターネットとの通信パターンを3パターン用意しました。

EC2からインターネットへのEgress（IPv4）
EC2からインターネットへのEgress（IPv6）
インターネットからALBへのIngress（IPv4、IPv6）

Egress通信の確認の際には、EC2からGoogleのDNSサーバー（8.8.8.8、2001:4860:4860::8888）に対してpingを打っています

VPC Block Public Accessの設定を入れてみる

まずは、除外設定を何もせずに双方向ブロックでBPAの設定を入れてみます。（この設定は1分ほどで有効になりました）

これは「インターネットとの通信を全て遮断する」という設定です。なので当然のことながら、3パターンの通信が全てブロックされる結果となりました。

今回の構成ではパブリックサブネットでインバウンドとアウトバウンドを両方除外してあげる必要があります。
なので、パブリックサブネットで双方向の除外設定を入れてみます。（この設定は有効になるまでに5分くらいかかりました）

すると、EC2からのIPv6でのEgressのみ拒否される結果となりました。

ここでドキュメントを確認してみると、ブロック対象は「インターネットゲートウェイとエグレスのみのインターネットゲートウェイ」であると書かれています

[双方向]: このリージョンのインターネットゲートウェイとエグレスのみのインターネットゲートウェイとの間のすべてのトラフィック (除外された VPC とサブネットを除く) がブロックされます。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/security-vpc-bpa.html

なので、今回の構成では以下のように、プライベートサブネットからのアウトバウンド通信も除外対象にしてあげる必要があります。

ちなみに、今回の検証ではBPAの設定を双方向ブロックにしましたが、BPAの設定をIngress-onlyにするとパブリックサブネットでの除外設定だけで良くなります。
なので、今回の構成でBPAを導入するのであれば、以下の2パターンのどちらかを採用することになります。

パターン1
- BPAで双方向ブロック
- パブリックサブネットでの双方向除外
- プライベートサブネットでのEgress-only除外
パターン2
- BPAでIngress-onlyブロック
- パブリックサブネットでの双方向除外

なお、IPv6のアウトバウンド通信が拒否された時のVPCフローログを確認してみると、reject-reasonフィールドにBPAと書かれていることが確認できます。

時系列を見ると、一度許可（ACCEPT）された後に拒否（REJECT）するという内容になっていました。このことから、セキュリティグループやNACLでACCEPTされた後に、BPAで拒否されるという挙動だとわかります。

VPCエンドポイントとの通信について検証してみる

すこし脱線しますが、ここでVPCエンドポイントとの通信がBPAのブロック対象になるのかどうかを検証してみます。

インターフェイス型とゲートウェイ型の2種類とも対象とし、それぞれ以下のように検証してみました。

インターフェイス型
- 先ほどの構成からNAT Gatewayを削除し、VPCエンドポイント経由でセッションマネージャーを使用する構成に修正
- BPAでブロック設定を入れても、セッションマネージャーで接続ができるかどうかを確認
ゲートウェイ型
- DynamoDBを新規に作成し、EC2の中からAWS CLIを叩いてDynamoDBに対する操作を行ってみる

結果として、インターフェイス型とゲートウェイ型どちらもBPAのブロック対象にはならないことがわかりました。
ドキュメントに記載の通り、インターネットゲートウェイもしくはEgress-Only インターネットゲートウェイを使用する通信のみがBPAのブロック対象となるようです。

CloudFront VPC Originsを使った構成に作り変えてみる

ここからは、BPAとCloudFront VPC Originsを組み合わせた構成で検証をしていきます。
検証をするために、CloudFront VPC Originsを使った構成に作り替えていきます。

まずはBPAの設定を無効化した上で、CloudFrontを追加し以下の構成に作り替えます。

最初に作ったALBとは別に、内部ALBを新しく追加します

CloudFront VPC Originsを使用するためには、「VPCオリジン」を別途作る必要があります。なので、CloudFrontの画面から先ほどの内部ALBを指定してVPCオリジンを作成します。

VPCオリジンの作成が完了すると、「cloudfront_managed」というタイプのENIが自動的に2つ追加されます

作成したVPCオリジンをCloudFrontのオリジンに追加し、ビヘイビアに設定しているオリジンも修正します

これでCloudFront VPC Originsを使った構成への作り替えが完了しました！

BPAとCloudFront VPC Originsを組み合わせてみる

「双方向ブロック、パブリックサブネットで双方向除外、プライベートサブネットでEgress-Only除外」という、作り替える前に使用した設定を入れてみます。すると、インターネットからのインバウンドが拒否される結果となりました。

これはインターネットからVPCオリジンに対する通信が、BPAによりインバウンド通信だと判定されてブロックされたためです。
そのため、プライベートサブネットでの設定をEgress-only除外から双方向除外に変更する必要があります。
実際に双方向除外の設定に変更すると、正常にWebサイトに接続することができました。

なお、今回の構成でBPAを導入するのであれば、以下の2パターンのどちらかを採用することになります。

パターン1
- BPAで双方向ブロック
- パブリックサブネットでのEgress-only除外
- プライベートサブネットでの双方向除外
パターン2
- BPAでIngress-onlyブロック
- プライベートサブネットでの双方向除外

今後意識すべき観点

使い方によっては非常に便利な機能ですが、今までとは異なる観点が必要になると感じました。
主に3つ感じたことがあるので、個人的な意見も踏まえて紹介していきます。

構成によってBPAのブロック方向と除外設定の組み合わせが変わってくる

CloudFront VPC Originsの使用の有無によって、BPAの設定内容が微妙に異なることに気づいたでしょうか？
パブリックサブネットとプライベートサブネット、どっちのサブネットにどんな除外設定を入れるべきなのかが微妙に異なります。

また、BPAの方向が双方向なのかIngress-onlyなのかによっても除外設定の中身が異なります。

このように、構成やBPAの方向設定によって除外設定が変わってくるため、事前に検証などをした上で設定を行うべきだと感じました。

作業の際には除外設定を前もって入れておく

今回の検証では最初にBPAを有効化しましたが、除外設定を先に設定しておいた上でBPA設定を有効化するという手順でも設定は可能です。
なので、実際に作業をする際には最初に除外設定を入れておいた上で、BPA設定を有効にするという手順をとることになります。

ちなみに、BPAで双方向ブロックではなくIngress-onlyブロックを設定すると、除外設定が比較的シンプルになります。とりあえず試したい場合には、Ingress-onlyブロックを選択すると良いかもしれません。

なお、設定は非常にシンプルですが影響が大きい機能なので、商用環境で使用する際には作業手順に十分ご注意ください。

BPAに対する権限設定

BPAは非常に強力な機能なので、権限管理をしておくと良いと思います。

例えばIAMポリシーを使用して権限管理を行う場合には、「VpcBlockPublicAccess」が含まれるEC2のAPIアクションのみを制限するようなポリシー設定を行うと良いと思います。
2025年1月現在、対象のAPIアクションは6つ存在しているため具体的には以下のようなポリシー設定になります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmtxxxxxxxxxxxxx",
      "Action": [
        "ec2:CreateVpcBlockPublicAccessExclusion",
        "ec2:DeleteVpcBlockPublicAccessExclusion",
        "ec2:DescribeVpcBlockPublicAccessExclusions",
        "ec2:DescribeVpcBlockPublicAccessOptions",
        "ec2:ModifyVpcBlockPublicAccessExclusion",
        "ec2:ModifyVpcBlockPublicAccessOptions"
      ],
      "Effect": "Deny",
      "Resource": "*"
    },
    {
      "Sid": "Stmtxxxxxxxxxxxxx",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

また、BPAはOrganizationsの宣言型ポリシーでサポートされています。

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html

宣言型ポリシーはre:Invent 2024で発表された機能で、ある特定のAWSサービスの設定内容を、Organizations組織内で強制的に指定できるという機能です。

例えば、Organizations組織配下のアカウントではBPA設定を強制的に有効化するという設定ができます。

強いガバナンスを効かせることが可能なのですが、宣言型ポリシーでは除外設定までは指定できません。

属性を使用して、除外を許可するかどうかを設定できますが、この属性自体を使用して除外を作成することはできません。除外を作成するには、を所有するアカウントで除外を作成する必要がありますVPC。VPC BPA 除外の作成の詳細については、「Amazon VPCユーザーガイド」の「除外の作成と削除」を参照してください。

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples

実際に使用するときは各アカウントで除外設定を入れてあげる必要があるので、それを意識した上で使用することをお勧めします。

まとめ

BPAとCloudFront VPC Originsは、今までのデファクトスタンダートな構成を大きく変える影響がある機能です。
ただし、今までとは異なる観点も必要になると思いますので、使用される際には事前に検証をした上で利用する方が良いと強く感じました。

特にBPAは強力な機能なので注意が必要ですが、うまく活用すれば大きな効果があります。
ぜひBPAとCloudFront VPC Originsの利用を検討してみてください。

この記事が誰かの参考になったら幸いです。

VPC Block Public Access と CloudFront VPC Origins を使ってみて気づいた色々な勘所

はじめに

VPC Block Public Accessとは

CloudFront VPC Originsとは