CTOの原口です。
個人的にすごいCloudFrontのニュースが飛んできました。
ざっくり言うとCloudFrontがVPCとくっついて動かせますよ、的な感じでVPCのプライベートサブネット内にあるALB、NLB、EC2インスタンスを直接公開する事ができるようになります。
ALBやEC2にPublic IPを持たせる事なく公開できるようになりました。
さて、ここの意味に対する我々のメリットは何でしょうか？
AWSの通信。たとえばCloudFront ↔ Public ALB や CloudFront ↔ EC2(Public IP) の通信は元々AWSグローバルネットワークに閉じた通信であり、パブリックインターネットを経由しないため基本的には安全な通信網とされています。
しかし、パブリックIPを持たなくてよいという点は以下のようなメリットが生まれるでしょう
- パブリックIPアドレスを削減でき費用を下げる事ができる
- リソースを外に出す必要がなくなるためセキュリティレベルが上がる
- オリジンを守る事に対する考慮を少なくする事ができる (CloudFrontバイパス問題など)
80や443のみを公開しているシステムにおいては、VPC Originsを使いPublic IPを持たない構成とする事がこれからのベストプラクティスになりそうですね。
やってみる
という事で早速、プライベートサブネットにあるPublic IPを持たないEC2をVPC originsで公開してみようと思います。
ドキュメントの確認
まずは公式に増えていたドキュメントを軽く確認。
VPC オリジンによるアクセス制限
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html
このあたりの前提条件を留意します
- VPCとCloudFrontは同じAWSアカウントにある事 (今後マルチアカウントも対応予定)
- VPCにはIGWがある事。(VPCサブネットのルーティングには不要)
- オリジンレスポンスタイムアウトは30秒、オリジンキープアライブは5秒の設定で変更できない
プライベートサブネットにApache入れたEC2を準備
プライベートサブネットにApacheなどで80ポートで何か返す状態のEC2を立ち上げます。
プライベートサブネットであるためパブリックIPv4アドレスはありません。
セキュリティグループはとりあえず80ポートを全て許可するものをつけました。通常はCloudFront マネージドプレフィックスリストを利用するのが正しいです。
EC2のARNとプライベート IP DNSを控えておきます。
VPC originsの作成
CloudFrontのページにVPC originsのメニューができているのでクリックして作成します。
Oringnのリソース(EC2、ALB、NLB)のARNを入力します。
今回は先ほど作成したEC2のARNを入力します。
ここでのプロトコルの選択は結構重要で、後から変更するには一度CloudFrontから外さないと変更できなくなりましたので注意してください。
VPCオリジンのDeployingがDeployedに変わったら完成です。
CloudFrontディストリビューションの作成
通常のCloudFront distribution作成時のオリジンの指定に「VPC origins」の項目が出現し、選択ができるようになっています
全体としてはオリジン設定は以下の感じに。
VPC Originsを選択すると VPC origin domain の入力欄ができるので、EC2のPrivate IPv4 DNSを入力して作成。
完了したらcloudfrontのエンドポイントに接続します。
プライベートサブネットでPublic IPを持たないEC2がCloudFrontで公開できました。
まとめ
個人的にはやっぱりIPv4のIPのコストを削減できるのが大きいですね。
ELBをMulti-AZで構築した場合、サブネットが3つあると、それだけでIPv4アドレスが3つ必要でIPだけで1500円/月くらいの費用がかかるのが、これが不要となるのはとても大きいです。
今後のベストプラクティスな構成がVPC Originsを使う、となりそうですね。
(こうなるとプライベートサブネットのEC2へのSSMへの接続が、S3のようにGateway型の、、無料のVPCエンドポイントになって欲しいなぁ…)
以上です！
