目次
BeeXの榊原です。先日VPCオリジンという機能が追加されました。前はCloudFrontからALBへ接続する際はパブリックサブネットに配置する必要がありました。それが今回VPCオリジンを用いることでALBがプライベートサブネットに配置されていても接続が可能となりました。今回はそちらの検証機会があったので、備忘として手順を記載しました。VPCオリジンについては以下をご参照ください。
以下引用です。
Amazon Simple Storage Solution (Amazon S3)、AWS Elemental Services、AWS Lambda 関数 URL からコンテンツを提供しているお客様は、オリジンアクセスコントロールをマネージドソリューションとして使用してオリジンを保護し、CloudFront をアプリケーションへの唯一の入口にすることができます。ただし、Amazon Elastic Compute Cloud (Amazon EC2) でホストされているアプリケーションやロードバランサーを使用するアプリケーションでは、同じ結果を得るために独自のソリューションを作成する必要があったため、これを実現するのは困難でした。エンドポイントが CloudFront 専用であることを確認するには、アクセスコントロールリスト (ACL) の使用、ファイアウォールルールの管理、ヘッダー検証などのロジックやその他のいくつかの手法の使用など、複数の方法を組み合わせて使用する必要があります。
CloudFront VPC オリジンでは、CloudFront ディストリビューションをプライベートサブネット内の Application Load Balancer (ALB)、 Network Load Balancer (NLB)、または EC2 インスタンスに直接ポイントできるマネージドソリューションを提供することで、このような差別化されていない作業を行う必要がなくなります。
VPCオリジンを使うための前提条件
まだ英語版のページしかありませんが、こちらの公式ドキュメントから引用します。
VPC は、CloudFront ディストリビューションと同じ AWS アカウントに存在する必要があります。
VPC は、VPC オリジンでサポートされている AWS リージョンのいずれかに存在する必要があります。詳細については、「VPC オリジンでサポートされている AWS リージョン」を参照してください。
VPC に次のものを含めます。
・インターネット ゲートウェイ– VPC がインターネットからのトラフィックを受信できるようにするために必要です。インターネット ゲートウェイは、サブネット内のオリジンへのトラフィックのルーティングには使用されないため、ルーティング ポリシーを更新する必要はありません。
・少なくとも 1 つの利用可能な IPv4 アドレスを持つプライベートサブネット– CloudFront は、プライベートオリジン CloudFront リソースを定義した後に CloudFront が作成する Elastic Network Interface (ENI) を使用してサブネットにルーティングします。ENI 作成プロセスが成功するには、プライベートサブネットに少なくとも 1 つの利用可能な IPv4 アドレスが必要です。IPv4 アドレスはプライベートにすることができ、追加料金はかかりません。
プライベートサブネットで、オリジンとして使用する Application Load Balancer、Network Load Balancer、または EC2 インスタンスを起動します。
起動するリソースは、VPC オリジンとして使用する前に、完全にデプロイされ、アクティブステータスになっている必要があります。
VPC オリジンとして使用するには、Network Load Balancer にセキュリティ グループがアタッチされている必要があります。
デュアルスタック ネットワーク ロードバランサーと TLS リスナーを備えたネットワーク ロードバランサーは、オリジンとして追加できません。
ゲートウェイ ロード バランサーは VPC オリジンではサポートされていません。
VPC プライベートオリジンのセキュリティグループを更新して、CloudFront マネージドプレフィックスリストを明示的に許可します。詳細については、「CloudFront マネージドプレフィックスリストの使用」を参照してください。
VPC オリジンが作成された後、セキュリティ グループをさらに制限して、VPC オリジンからのトラフィックのみを許可することができます。これを行うには、許可されたトラフィック ソースをマネージド プレフィックス リストから CloudFront セキュリティ グループに更新します。
構成
今回の想定構成は以下の通りです。サブネットは全てプライベートサブネットです。
クライアントからALBまではHTTPS通信で暗号化され、ALB以降はHTTP通信です。
設定手順
※下記手順は省略します。
・VPCの作成
・EC2の作成
・ターゲットグループの作成
・証明書に用いるドメイン名の取得(今回はtest-sakaki.com)
・証明書の作成(東京リージョン、北米リージョン)→ALB用とCloudFront用
ALB
スキームは「内部」でプライベートサブネット2つを指定して作成します。ターゲットグループは作成済みのものを指定してください。今回は80番で指定しました。
ALBの項目は以上です。
VPCオリジン
VPC内のどこに接続させたいか設定します。今回はALBを選択しています。オリジンに付ける名前は後から変更不可なのでご注意ください。プロトコルは今回HTTPSのみを選択しますが、要件によって「HTTPのみ」やHTTPとHTTPSどちらも使える「マッチビューワー」を選択可能です。SSLの最小バージョンは「TLSv1.2(デフォルト)」、「TLSv1.1」、「TLSv1」、「SSLv3」から選択可能ですが今回はデフォルトのTLSv1.2を選択しています。
VPCオリジンが作成されたら、選択したリソースと同じサブネット内に説明欄に「CloudFront configured ENI」ENIと専用の「CloudFront-VPCOrigins-Service-SG」という名前のセキュリティグループが作成されます。
セキュリティグループは下の画像の通り、インバウンドにルール表記は無く、アウトバウンドは全開放されていました。
VPCオリジンの項目は以上です。
CloudFrontディストリビューション
CloudFrontディストリビューションの項目は以上です。
Route 53
CloudFrontにアクセスするために、「test-sakaki.com」のホストゾーンに「www.test-sakaki.com」のエイリアスレコードを作成します。
Route 53の項目は以上です。
疎通確認
それでは最後に「www.test-sakaki.com」に接続してみます。
ちゃんと接続できました。短いですが、今回は以上です。ここまでお読みいただきありがとうございました。