IPv6を用いてセキュリティとコスト最適化を追求したVPCの構築例をご紹介します。
従来の構成との違い
これまで筆者はIPv4をベースとするVPCをよく作ってきました。
もちろんそれはそれでちゃんと動いたわけですが、一方で課題もありました。第一に外部通信を行うためのNAT Gatewayが高コストなことです。使わなくても維持費がかかりますし、データ転送料もそこそこのお値段がします。第二にパブリックサブネットを必要としたことです。インターネットから直接アクセスできる場所に、踏み台をはじめとするEC2を配置できる構成は、できれば避けたいことでした。
しかし昨今はAWSのIPv6が進み、NATゲートウェイを使わずともサービスを提供できる構成が増えてきました。また踏み台サーバーやALBなども特殊な設定を使うことでプライベートサブネットに置くことができるようになり、パブリックサブネットを撤廃する道のりが示されました。
そこで今回、IPv6メインかつプライベートサブネットのみとしてVPCを構築することにしました。なお、フロントエンドにCloudFront + S3、バックエンドにALB + ECS Fargate + RDS AuroraとSSM Parameter Storeを使う、よくある構成での利用を想定しています。実際にテストアプリケーションが動作することは確認済です。
構成図と説明
下図が構成図となります。見やすくするためアベイラビリティゾーンごとに表示するのは避け、まとめてあります。
プライベートサブネットが二種類あります。IPv6専用と、IPv4/IPv6のデュアルスタックです。初めて見るとやや奇異な印象を受けるこの構成についてご説明いたします。
まず前提としてALBを使う想定なのですが、ALBはIPv6-onlyでは使えません（CreateLoadBalancer ）。そこでデュアルスタックのサブネットが必要となります。
一方、ECSタスクからIPv6でSSM Parameter Storeに接続するためには、IPv6専用のサブネットの配置する必要があります。デュアルスタックのサブネットに置くとNAT GatewayへのIPv4経路を使ってしまう仕様らしく（Fargateタスクのネットワーク ）動作しなかったのです。
このためプライベートサブネットが二種類できています。
ALBはプライベートサブネットに配置する
ALBはCloudFront VPC Originsと組み合わせて使う想定としています。このためALBはinternalタイプをプライベートサブネットに配置できます。
パブリックサブネットがないのにigwがセットされているのも、CloudFront VPC Originsの利用を前提としているためです（CloudFront VPC Origins ）。
まとめ
よくあるフロントエンド・バックエンド＋データベースという構成をとりつつも、従来よりローコストかつ同程度にセキュアなVPCを構築する方法をご紹介しました。数年前は、フロントエンド＋バックエンド＋DBというよくある構成をNATゲートウェイなしで行おうとすると、セキュリティを若干犠牲にしてパブリックサブネットに配置するなど、お客様に提案するのがためわれる施策となってしまったものですが、昨今ようやくセキュリティ面でも妥当な構成で構築できるようになっています。
これから新規サービスのためにVPCを構築する際には、ぜひNATゲートウェイを外せないか検討してみてください。