先日Amazon CloudFront の新機能、VPC オリジンを利用して
Amazon VPC の Internal ALB へ CloudFront 経由でアクセスする機能がリリースされました。
個人的には待望の機能だったので、早速導入してみた記録です。
個人的背景
以前AWSがパブリックIPv4アドレス有料化を発表し、追加の課金が発生するようになってしました。
新たなコスト高に直結する箇所となるため、AWSが推進するIPv6採用・移行が急務となるのですが、実際はブロッカー要素が多くありました。
例えばCloudfrontのオリジンでALBを利用する場合を考えてみましょう。
標準で複数のAvailability Zone (以下AZ) で稼働するように設定します。 すると、このAZの個数分のパブリックIPv4アドレスを利用してしまい、予想以上の料金が発生します。
具体的には、東京リージョン (ap-northeast-1) でALBを利用する場合は3AZを設定することが一般的です。
しかしこの場合、3個分のパブリックIPv4アドレスを利用してしまい、この分の料金が発生します。
パブリックIPv4アドレスの利用単価は 0.005 USD/時ですが、1月分(31日換算) と考えると 3.72 USD/月 となります。 これがAZの個数分発生するので、普通の設定をしている場合は毎月10USD程度の追加料金が発生します。 ALB そのものの維持料金が毎月20USD程なので、この点で考えると料金が約1.5倍になってしまいます。
大規模運用もですが、特に小規模で運用しているインフラにおいて、この変更はコスト影響が大きいです。
(私自身上のアーキ図と同様のインフラを個人で利用しており、モロに影響を被って苦しんでおります。。)
移行におけるブロッカーについて
今回ご紹介するCloudFront Originを導入前の時点では、これらの課金の回避方法がありませんでした。
というのも、AWSが推進しているIPv6移行において、ALBはIPv6 onlyに対応していましたが、CloudFrontではIPv6オリジンに対応していなかったのです。。
この問題はAWS re:Post でも話題となっており、多くのユーザから機能要望が上がっていたケースでもありました。
しかし最初のissueから1年経過後もアップデートがなく、ユーザからの不満も多く投稿されていた模様。(結構キレながらクレーム入れてるユーザいて笑った)
待望のアップデート
冒頭でもご紹介した通り、今回のアップデートによりCloudFrontが直接VPC Originへアクセスすることが可能となり、ALBにパブリックIPアドレスを付与する必要がなくなりました。
このことで余分なコストを削減できるだけでなく、パブリック経路も最小限に排除できるようになったため、セキュリティ観点からも望ましい形になりました。
図にするとこんな感じ
なおCloudfrontとVPC Origin間のパブリックIPは発生しませんが、パブリックサブネットとIGWは必要になります。
設定方法
コンソールで設定する分には基本的にはクラスメソッドさんの記事を参考に進めればOKでした。
ぶっちゃけ私もこれ見て設定しました。
ただ、一部注意点や自分なりの覚書があったので以下にメモします
注意点
- VPC OriginでサポートされるリージョンとAZの一覧が以下ドキュメントに記載されています。
ここの記載のないリージョン、AZではオリジンを作成できないので注意。
1つハマった点として、一部リージョンにおいて対応していないAZがあるようです。
(東京リージョンだと(except AZ apne1-az3)
という記載があり、おそらく ap-notheast-1b
を指しているものと思われる)
このゾーンは現在新規で利用できるものではないので、通常は選択できないのですが、他のリージョンでは普通に選択できてしまうことがあります。
その場合、作成中にエラーで失敗しますが、具体的なエラーコードが出ずトラシューが難航するのでご注意ください。
- VPCオリジン作成が完了すると、CloudFront用のENIとSecurityGroupが自動的に作成されます。
オリジンのリソースのSecurityGroupにこのENI/SecurityGroupからの通信許可を入れてあげてください。
ちなみにVPC Originへの変更後、マネージドプリフィックスを利用したセキュリティグループによる制限や、CloudFrontのカスタムヘッダーを利用した制限などは必要なくなるので解除してしまって良いと思います
後記
Cloudfront/VPC Originと直接関係ないですが、ルーティングターゲット先のEC2インスタンスはプライベートサブネットに配置するケースがほぼだと思います。
外部インターネットアクセスが必要な場合、NAT Gatewayなど利用することが多いですが、ここに付与されるパブリックIPv4についても課金対象となるので、削減を目指す場合はEgress-Only Internet Gatewayを利用するとよいでしょう。
ただアプリ・バックエンド側で完全にIPv6 only対応できているもののほうが少ないと思うので、ここの課金を完全に排除するのは難しいかもですねぇ。。。
まぁ、今後の課題です。