dshimizu/blog/alpha

とりとめのないITブログ

Application Load Balancer の前段に CloudFront を置いておいた方が良いのかどうなのか

AWS Amazon CloudFront

はじめに

Application Load Balancer の前段に CloudFront があると何が良いのかと稀によく聞かれるので、簡単に整理してみました。

と思っていたら以下のようなツイートを見つけました。

なのでわざわざ整理する必要もなさそうでしたが、一応自分用メモとして記載しておきます。

目次

セキュリティの側面

AWS Shield Standard で保護される

AWS には AWS Shield というマネージド型の DDoS 保護サービスがあります。

AWS Shield には Standard と Advance がありますが、Standardの方はデフォルトで有効になっており、CloudFront が前段にいると一定の保護を受けることができます。

すべての AWS のお客様は、追加料金なしで AWS Shield Standard の保護の適用を自動的に受けることができます。AWS Shield Standard は、ウェブサイトやアプリケーションを標的にした、最も一般的で頻繁に発生するネットワークおよびトランスポートレイヤーの DDoS 攻撃を防御します。AWS Shield Standard を Amazon CloudFront や Amazon Route 53 とともに使用すると、インフラストラクチャ (レイヤー 3 および 4) を標的とした既知の攻撃すべてから包括的に保護されます

ただ、これは上記にある通りL3-L4に対するものなので、HTTPのようなL7に対しては別途対策を講じる必要があります。

アクセス元が固定で、限定したIPからのみアクセス制限を行うことができるようなものだと、ALB 直でセキュリティグループやネットワークACLで頑張るというのでも良いのかもしれません。

ネットワーク構成面

論理的には、ALB は VPC の内部にいます。そのため、インターネットから直接 ALB へ通信を受ける際には、ALBがいる VPC のパブリックサブネット内まで通信が来ていることになると思います。 一方で、CloudFrontはVPC外にいます。なので、CloudFrontがいると、論理的には、VPCの外でまずは通信を受けてくれることになります。

これも限定したIPからのみアクセス制限を行うことができるようなものだと、あまり気にせず、ALB 直というのでも良いのかもしれません。 ただ、CloudFrontがAWSバックボーンネットワークにいて、そこで通信を受け付けてくれるという一定の安心感はある気がします。

日本向けサービスで東京リージョンで稼働しているサービスで、コンテンツ等はなくシンプルなRESTベースのAPI等である場合等に対して、ACloudFront+AWSバックボーンネットワークを介するケースでどのくらいレイテンシーに差があって恩恵を受けられるのかは検証できてないので分かっていない。

IP 制限

ALBだとセキュリティグループが使えるので、IP制限は結構楽にやれるかと思います。 CloudFrontだと、セキュリティグループは使えないので、AWS WAFを使う形になります。また、この場合のAWS WAFはバージニアリージョン(us-east-1)に作成する必要があります。若干の手間はあります。

通信料

ALB からインターネットへのアウトバウンド通信は、通信量に応じて料金がかかります。通信料はEC2の料金が適用されるようです。

データ転送料金

ELB 料金に加えて、標準の AWS データ転送料金が発生します。詳細については、Amazon EC2 料金ページのデータ転送セクションをご覧ください。

以下の ALB の推奨セキュリティグループ設定から、ALB単体で外部に通信することはないと思われるので、ターゲットグループに登録されているターゲットに来た通信の戻り通信にこの料金がかかると思います。

続いて、EC2 の料金を見てみます。

2023/6 時点では、東京リージョンでは下記のようでした。

  • Amazon EC2 からインターネットへのデータ転送 (アウト)
最初の 10 TB/月 0.114USD/GB
次の 40 TB/月 0.089USD/GB
次の 100 TB/月 0.086USD/GB
150 TB/月以上 0.084USD/GB

一方で、CloudFront の通信料ですが、これもEC2と同等のようでした。

ただ、以下の通り毎月の無料枠があり、これに収まる場合は無料で利用できます。

常時無料利用枠に含まれます

1 か月あたり 1 TB のデータ転送 (OUT)

1 か月あたり 10,000,000 件の HTTP または HTTPS リクエスト

1 か月あたり 200 万件の CloudFront 関数呼び出し

無料の SSL 証明書

制限なし、すべての機能が利用可能

また、AWS のサービスから CloudFront へのデータ転送 (アウト) の料金は 0 USD/GB です。

そのため、ALB 直の場合だとデータ転送 (アウト) の料金がそのまま適用されますが、CloudFrontを挟むと、ALB -> CloudFront 間のデータ転送 (アウト) の料金は無料で、CloudFrontのデータ転送 (アウト) の料金は最初の 1 TB のデータ転送 (OUT)は無料なので、通信料の点ではメリットがありそうです。

リクエスト数

CloudFront は HTTP リクエスト数に応じて料金がかかります。

上述の通り、「1 か月あたり 10,000,000 件の HTTP または HTTPS リクエスト」は無料ですが、それを上回るリクエストが発生すると料金がかかります。この場合は、ALB の前段にCloudFrontを置いた場合には追加の費用がかかることになりそうです。

機能等

CloudFront でキャッシュやオリジンルーティングなど色々やれて機能は充実していると思います。 一方でキャッシュの設定や管理などは割と慎重にやらないとインシデントになりそうなので、やや運用コストは上がるかもしれません。

障害

CloudFront の障害対策となると、待機用に別CDNを使うとか、DNSをALBに割り当ててALB直で疎通できるようにする、といったことは技術的には可能そうですが、なかなか準備するのは大変そうです。ALB の方でも障害となるケースもあり得るので、この点は何をどこまでケアするか、という感じになるように思います。

まとめ

他にも色々な観点がありそうですが、個人的には、CloudFrontはとりあえずALBの前段に置いておいた方が良さそうには思います。 一方で設定や検証などはやはり慎重に行う必要がありそうです。

参考