re:Invent 2022のセッション「Optimizing performance with CloudFront: Every millisecond matters」でCloudFrontの最新情報をキャッチアップ！ #reinvent
はじめに
清水です。AWS re:Invent 2022のセッション「Optimizing performance with CloudFront: Every millisecond matters」をYouTubeで視聴しました。事前にセッション内容を確認していたわけではなくYouTubeのAWS Eventsチャンネルで見つけたものなのですが、CloudFrontを用いたアプリケーションの可用性向上やレイテンシ削減といったユーザエクスペリエンスの向上の事例に焦点を当てつつ、ここ半年ほどのCloudFrontのアップデートの多くを紹介する非常に魅力的なセッションでした。
本エントリではこのセッションについて、内容をまとめつつアップデートについては関連するDevelopersIOブログエントリへのリンクを含める、といった形式のセッションレポートとしてまとめてみました。セッションの内容を具体的にまとめる、という点では少し薄いかもしれませんが、詳細についてはぜひセッション動画のほうでお楽しみください。
このセッションの（個人的な）見どころ
このセッション、「Optimizing performance with CloudFront: Every millisecond matters (NET313)」ですが、Mapbox社のCloudFrontの事例を紹介しつつ、ここ半年ほどのCloudFrontのアップデート、例えばCloudFront continuous deployment（継続的デプロイメント）やJA3 fingerprinting header対応など最新のものについても触れられています。特にこのセッションの直前にアップデートされたcontinuous deploymentについての解説は、AWS Blogやドキュメント以外では初ではないでしょうか。またこれらアップデートに対し、このセッションで（おそらく）はじめて述べられた機能追加などもありました。
CloudFrontを用いたサイト・アプリケーションの高速化を扱ったセッション、ということで、実はタイトルを見たときに以下のAWS re:Invent 2019のセッション「Optimizing for performance in CloudFront: Every millisecond counts! (NET309)」が思い浮かびました。この続編?なのかな、と思ったわけですね。
このre:Invent 2019のセッションはCloudFrontでの負荷対策ではなく、高速化のほうに特に焦点を当てた、当時割と珍しいセッションだったと記憶しています。実際は登壇者も異なり、たまたま同じようなタイトルになっただけだとは思うのですが、re:Invent 2022のセッションでも「Every millisecond matters」という副題(?)のとおり、いかにしてレイテンシを小さくしカスタマーエクスペリエンスを高めるか、という点についてもしっかりと解説されています。
CloudFrontを用いたサイト・アプリケーションの高速化、ならびにそれらに関連するここ最近のアップデートをまるっと抑えることのできる点が、個人的にこのセッションの大きな見どころかと思っています。
セッション情報
セッション情報についてSession Catalogから引用します。セッションタイトル並びにセッション情報の日本語訳は機械翻訳したものです。
- セッションタイトル
- Optimizing performance with CloudFront: Every millisecond matters
- （CloudFrontによるパフォーマンスの最適化: 1ミリ秒単位が重要）
- セッションID
- NET313
- 現地でのセッション日時
- Tuesday, November 29, 4:15 PM - 5:15 PM
- セッションレベル
- 300 - Advanced
- セッションタイプ
- Breakout Session
- 登壇者
- Sagar Desarda, US Tech Leader – Edge Services, AWS
- Blake Thompson, Director of Maps APIs, Mapbox
- セッション概要
- Improve application availability and reduce latency with Amazon CloudFront features such as serverless edge compute and Origin Shield. In this session, learn how to integrate canary deployments into a CI/CD pipeline and develop an effective monitoring strategy with CloudFront logs. Dive into some of the recent launches within the CloudFront service. Also hear from Mapbox, a company built on Amazon CloudFront, and learn how CloudFront has fueled its success. Mapbox is a platform that equips organizations with a full set of tools to power the navigation of people, packages, and vehicles everywhere.
- （サーバーレスエッジコンピュートやOrigin ShieldなどのAmazon CloudFrontの機能により、アプリケーションの可用性を向上させ、レイテンシーを削減することができます。このセッションでは、CI/CDパイプラインにカナリアデプロイメントを統合し、CloudFrontログを使用して効果的な監視戦略を開発する方法について学びます。また、CloudFrontのサービスにおける最近の発表についてもご紹介します。また、Amazon CloudFront上に構築された企業であるMapboxの話を聞き、CloudFrontがいかにその成功を後押ししたかを学びます。Mapboxは、あらゆる場所で人、荷物、車のナビゲーションを可能にするフルセットのツールを組織に提供するプラットフォームです。）
セッション動画
YouTubeで公開されているセッション動画は下記になります。
AWS Global Infrastructure
それではセッション内容に入ります。まずはAWSのSagar Desardaさんから、AWS Global Infrastructureについての説明です。恒例のリージョン数やエッジロケーション数の説明からはじまりますが、その話は使用しているハードウェアやセキュリティ、DDoS対応など多岐に広がり、非常にDeepな内容となっています。
まずAWS Global Infrastructureとして、30すべてのAWSリージョン、95のAZ、410以上のEdgeロケーション、これらはみな低遅延なプライベートネットワークで接続されており、そのバックボーンとして海底ケーブルの利用、複数の100GbEプライベートファイバーリンクが使われていることなどが紹介されました。
そしてAWS Network Infrastructureとして、スイッチや光モジュールなどをAWSでカスタム設計していること、またこのカスタム設計のネットワークスイッチを使用することで、故障率が80%削減できたことが紹介されました。
AWS Network Infrastructureのセキュリティにも触れられています。AWSのグローバルネットワークを流れるデータはデータセンター内部、リージョン間などで自動的に暗号化され、また高度な改ざん検知を使用してデータを保護。そしてハードウェア部品の製造サプライチェーンについても管理しハードウェア攻撃にも対応しているということです。
DDoSについては、AWS Shieldにより月に10,000件を超える攻撃に対処、そのほとんどは自動的に診断してトラフィックを最適化、カスタマーのアプリケーションが影響を受ける前に対応をしているそうです。
Regional Expansionとして、以下のスライドも提示されました。AWSではネットファークファブリックを再設計し展開を容易にし、より高速なスケーリングが可能となっているとのことです。このため、昨年はAWSの最初の15年間を合わせたよりも多くのネットワーク容量をAWS Edgeロケーションに展開、また過去3年間で全体的なネットワーク容量は3倍に増やされたそうです。リージョン数のだけみても、ここ数年での広がりぐあいがわかりますよね。（日本だけでみるとこれまでの東京リージョンに加え、大阪リージョンが2021年3月に正式利用開始になりました。リージョン数は国内で2つとなり、いまのところ第3のリージョンの予定は公表されていません。それほどリージョン数の拡充はないのかな、とも思われがちかもしれませんが、世界を見渡すとここ数年で多くのリージョンが開設され、もしくは開設予定となっていることがわかります。）
Mapbox journey on Amazon CloudFront
続いてMapbox社のBlake Thompsonさんに替わります。CloudFrontの事例の話ではあるのですが、CloudFrontの各種機能を用いて具体的にどのぐらいの改善ができた、と数字で説明している箇所が多くあり、説得力があります。
Mapboxはウェブサイトやアプリケーション向けのオンラインカスタムマップのプロバイダです。本社はアメリカで、アメリカで利用されているほか、日本にもMapbox Japanがあります。例えばYahoo! Japanのスマホ地図アプリなどで見かける名前ですね。
月間700万のアクティブユーザがおり、Mapboxを使って年間40億以上、1時間に50万回以上の同社のカスタムマップを用いた配送が行われているそうです。
そんなMapbox、構成としては8つ以上のAWSリージョンを使ってオリジンを準備、すべてアクティブな状態で運用しつつAmazon Route 53を使って世界中のオリジンにルーティング、そしてCloudFrontを用いてデータをエンドユーザ近づけ、ユーザ体験を向上させているとのことです。またCloudFrontを用いることで総帯域幅の90%以上をオフロード、アプリケーションサーバへは10%未満しかリクエストが到達していないということでした。なかなか驚異的な数字ですよね。
CloudFrontの活用方法についてもいくつか紹介がありました。
HTTP 304 Not Modifiedの利用
CloudFrontのCache Policyを活用しつつ、リクエストの際にはIf-None-Matchヘッダを送信、ETagによる検証を用いてコンテンツに更新があればコンテンツに更新がない場合はHTTP 304 Not Modifiedでコンテンツ自体を送信しないようにしているということです。
このHTTP 304、リクエスト全体の40%以上が該当するということで、それだけコンテンツのダウンロードが減り使用する帯域も削減できているということになります。
Byte-range requestsの利用
続いてはByte-range requestの利用です。対象は容量の大きなファイルで、例えばカスタマーがトンネルのある道路を運転しながらダウンロードを行う（地図アプリ特有の使用状況ですよね）など、コネクションが不意に切れるシチュエーションで有効ということです。
Byte-range requestを用いることで大きなファイルのダウンロードが途中で中断しても、はじめからやり直すのではなくレジュームが可能になります。Byte-range requestの利用でダウンロードのリスタートは5%削減し、またエンドユーザのエクスペリエンス向上にもつながっているとのことです。
Origin Shieldの利用
Origin Shieldの利用についても紹介がありました。地図情報の更新の際、CloudFrontではPOP: Point of Presenceと、POPとオリジンサーバとの間に位置するREC: Regional Edge Cacheが利用されます。RECによりキャッシュがオフロードされオリジンサーバの負荷は下がりますが、それでも複数のRECから同じコンテンツに対するリクエストが発生しオリジンの負荷が向上します。
CloudFrontのOrigin Shieldを使うと、Originの前段にキャッシュ用のレイヤーが追加されます。他のRECもこのOrigin Shieldのキャッシュを利用するかたちになるので、キャッシュのオフロードが更に改善されオリジンの保護に繋がります。またオリジンへのレイテンシが最も低いAWSリージョンにてOrigin Shieldを有効にすることで、はるかに優れたネットワークパフォーマンスを得ることが可能です。
Brotliでのコンテンツの圧縮
Brotliでのコンテンツ圧縮も利用しているとのことです。Brotliではストリームをオンザフライで圧縮するように設計されており、Gzipよりも圧縮、解凍の両面で高速です。
CloudFrontではクリックして有効にするだけでBrotliでのコンテンツ圧縮を有効にすることができます。ブラウザ側でBrotliがサポートされていればBrotli形式で、未対応の場合はGzip形式にてコンテンツが提供されます。オリジンサーバ側での対応は不要です。
実際MapboxではBrotli形式でのコンテンツ圧縮の利用で8%の帯域削減ができたそうです。ただし、Maboxで提供しているコンテンツはバイナリ形式が主であり、従来のWebアプリケーションであれば帯域削減率はより高く、一般的には25%の帯域削減が期待できると言われています。
CloudFrontのログの活用
Mapboxではユーザエクスペリエンス向上のため、アプリケーションのモニタリング、パフォーマンス監視にも力を入れているとのことで、そこで解析対象となってくるCloudFrontのログについては1日でなんと20TB以上にもなるそうです。
このCloudFrontログを利用したリアルタイムダッシュボードを作成しているということで、構成図が紹介されました。
上記で構成されるダッシュボードを用いて、レイテンシについていはエッジロケーションごとモニタリング、さらに遅いリクエスト（レイテンシが大きすぎるリクエスト）は可用性の計算から除外している（エラーリクエストと同じように処理している）など、ログ活用方法からパフォーマンス監視について徹底的に行なっていることが伺えました。
またアクセスログによるモニタリングの説明の中で、今年2022年10月にリアルタイムログに追加された3つの新しいフィールドについても紹介がありました。
CloudFront's serverless compute environment
Sagar Desardaさんに戻り、CloudFrontのサーバレスコンピューティングについての話です。
CDNの利用においては、よりパーソナライズされたエクスペリエンスをエンドユーザに提供すること、また非常に低いレイテンシーでデータを処理する必要性が高まっており、MapboxでもCloudFrontの重要な機能の1つとしてサーバレスコンピューティング環境を挙げている、とのことです。
このパートでは、2つのCloudFrontで利用できるサーバーレスコンピューティング環境、Lambda@EdgeとCloudFront Functionsについてそれぞれの使い分け、ユースケースの紹介などがありました。また特に、Lambda@Edgeと比べて新しい機能であるCloudFront Functionsについては、そのアーキテクチャについても紹介がありました。
Lambda@EdgeとCloudFront Functionsそれぞれのユースケース
Lambda@Edgeのユースケースとしては、処理に数ミリ秒以上かかる場合や、ネットワークアクセス、ファイルシステムへのアクセスが必要な場合を挙げています。またLambda@EdgeではHTTPリクエスト本文へのアクセスも可能です。
対してCloudFront Functionsはキャッシュの正規化、ヘッダーの操作やURLの書き換えやリダイレクト、リクエストの承認などが最適なユースケースとなります。
Lambda@Edgeの具体的なユースケースとして、Waiting Room機能が紹介されました。過剰なトラフィックへの対応として機能するVirtual Waiting Room、日本でも以前話題になったかと思います。CloudFrontでもLambda@Edgeを利用することで実現可能です。
CloudFront Functionsの具体的なユースケースとしてはURLリダイレクトのEdgeへのオフロードが紹介されました。サイトの統合や、ブランディング、マーケティングの観点などからサイトのリダイレクトが必要になるケースがあります。オリジンサーバ側での対応もできますが、CloudFront Functionsを使うことで、これらの処理がCDNのエッジ側にオフロードできるわけですね。
Looking ahead with Amazon CloudFront
最後のパートで、ここ数ヶ月でリリースしたCloudFrontの機能について紹介しています。
Server Timing Headers
まず1つ目はServer Timing Headersです。今年2022年4月にアップデートされた内容ですね。
リクエストが完了するまでには様々な箇所で処理時間が発生します。その中でもサーバ側の処理時間はかなりの割合を占めるのですが、ブラウザの開発者ツールではサーバ側のどこでどのように時間がかかっているのか、といった詳細な情報を把握することはできませんでした。別途サーバログを解析して分析する必要があったわけですね。
Server Timing Headerはサーバに関連するパフォーマンスメトリックスをクライアントに伝達できるようにし、クライアントが開発者ツールでそれらを直接表示できるようにする標準化されたメカニズムです。レスポンスの生成中にどこでどのように時間がかかっているか、といった情報が返されます。最新のブラウザのほとんどでこのServer Timinig Headerをサポートするようになっているとのことです。
Server Timing Headerを有効にすることでCloudFrontならびにオリジンサーバ側の処理で、どこにどのぐらいの時間がかかっているか、ということがブラウザに伝達されます。具体的な例として以下が提示されました。こちらの例では、CloudFrnotがオリジンへのTCP接続を完了するのに30ミリ秒かかったことがわかります。またリクエストされたオブジェクトがCloudFrontキャッシュになく、コード"PHX50-C2"で識別されるエッジロケーションによってリクエストが受信されたこと、リクエストを受け取ったあと、レスポンスの最初のバイトをエンドユーザに送信するのにCloudFrontで436ミリ秒かかったこと、などがわかります。
JA3 Fingerprinting on CloudFront
続いてはJA3 Fingerprintingについてのアップデートです。今年2022年11月にリリースされたものですね。（ところで「JA3」の読み方、私は「じぇいぇーすりー」と読んでいたのですがセッション内では「じゃーすりー」と読んでいました。）
以前からクライアントのUser Agent情報などをもとにフィンガープリントを計算し、これをもとに悪意のあるリクエストとみなしてブロックを行うという手法がありました。しかし、今日ではなりすましが容易になってきているとのことです。
JA3フィンガープリントでは、暗号化されたセッション中にクライアントとサーバ間で交換されるデータを使用して署名を作成します。この署名は特定のアプリケーションのものであるのか、攻撃者が使用しているクライアントアプリケーションであるかの比較に利用できます。User AgentやIPアドレス、ドメイン名などよりも偽装されにくい情報です。このJA3フィンガープリントをもとにしたトラフィックのリダイレクト、マルウェアやボットの特定とブロック、特定のアプリケーションのみにアクセスを許可する、といったことが可能です。
そしてAmazon CloudFrontでは、このJA3フィンガープリントがcloudfront-viewer-ja3-fingerprintというヘッダでオリジンに転送できるようになりました。またヘッダの順序についての情報（Header Order Information）についても利用可能です。
なお、JA3 fingerprint headersのアップデートブログでcloudfront-viewer-ja3-fingerprint ヘッダは利用可能になっていることを確認していましたが、Header informationのcloudfront-viewer-header-orderならびにcloudfront-viewer-header-countの2つのヘッダについてはまだアップデート情報がなく、おそらくこのセッションが初出かと思います。本エントリ最後に実際に動作検証のようすをまとめていますが、2022/12/07現在、正式なアップデート情報やドキュメントの記載はなくとも動作はしているようでした。
CloudFront continuous deployment
そしてこのセッション開催（現地時間2022/11/29）の直前（AWS Blogが2022/11/18、What's New at AWSが2022/11/21）にアップデートされた新機能、CloudFront continuous deploymentについても紹介がありました。AWS BlogやDeveloper Guide以外での解説としては、おそらくはじめてではないでしょうか。
CloudFront continuous deploymentローンチまでの背景として、開発環境でCDNの変更をテストしても必ずしも万全ではないという点がありました。新しいCDN環境へ徐々にトラフィックを移したい、問題があればロールバック可能な、CloudFrontでblue-green環境を構築したいという要望がありました。
CloudFront continuous deploymentを使用することで、本番トラフィックの一部だけをを新しいCDN設定に向けてテストを行う、ということが可能になります。具体的には、CloudFront continuous deploymentを使用すると新しいアプリケーションコードを含む2つ目のディストリビューションを作成できます。最初にヘッダーベースまたはビューアーIPベースのポリシーを使用して内部的にテストを行い、重みを設定して新しいアプリケーションコードを持つ2つ目のディストリビューションにトラフィックを分割できます。
CloudFrontではポリシー内容によりトラフィックを分割します。また新しいディストリビューションでに関連する情報が提供されるので、デプロイメントを続行するのかロールバックするのかの判断が可能です。テストが完了したら、新しいディストリビューションのコードをメインディストリビューションにマージします。これですべてのトラフィックが新しいコードにて処理されるようになります。
今回のローンチでcontinuous deployment機能を用いて、CloudFrontディストリビューションに加えることができる変更について以下の通り紹介がなされました。
SDKやCLI、AWSコンソールやCloudFormationを利用して、このセットアップを数分で作成可能とのことです。ディストリビューションを複製して必要な変更を適用します。重み付け（Weight based）、ヘッダーベース、ビューアIPベースのようなポリシーを設定してこのディストリビューションへのトラフィックを段階的に増やしていきます。テストが完了したら、変更をメインのディストリビューションにコピーします。この方式により、新しい設定のグローバルロールアウトの前に、変更をより適切にテストできるようになりました。コードを高速でプッシュし、ソフトウェア配信をより細かく制御できます。
ところでCloudFront continuous deploymentでは2022/12/07現在、Weight-basedとHeader-basedの2種類のリクエストの振り分け方法がサポートされています。ただこのセッション中、2回ほど「Viewer IP based」と言っているんですよね。英語が不得手な筆者の勘違いでなければ、こちらもこのセッションが初出となるアップデートになるかと思います。本エントリ最後にこちらの詳細（個人的な期待）についてもまとめたいと思います。
Enable HTTP/3 on Amazon CloudFront
最後にCloudFrontのHTTP/3サポートについてです。今年2022年8月のアップデートですね。
2022年6月に仕様が最終決定されたHTTP/3、HTTP/2の欠点を改善し、UDPベースのQUICプロトコル上で構築されています。UDPで実行されているため、パケットがドッロップされた場合のハンドシェイクがHTTP/2よりも迅速に行われます。またすべてのストリームではなく1つのストリームのみが中断されるなど、エラー処理がはるかに優れています。
CloudFrontのHTTP/3サポートでは、s2n-quicを用いた強化されたセキュリティを提供しているとのことです。s2n-quicはオープンソースのRust実装で、AWSの暗号化オープンソースライブラリに加えられています。（参考: AWS は、QUIC プロトコルの新しいオープンソース実装である s2n-quic を導入）
HTTP/3はまだ標準化されたばかりで、引き続きHTTP/2の利用率が高い状況ではあるが、今後はHTTP/3の利用の増加がみられると予想しているということでした。
なお、Amazon CloudFrontのHTTP/3（QUIC）対応については以下のセッションも詳しそうです。（セッションを見つけただけでまだ詳細の確認はしていないのですが、珍しい?400番台のBreakout Sessionということで期待できるのかなと思います。）
- AWS re:Invent 2022 - Deliver great experiences with QUIC on Amazon CloudFront (NET401) - AWS Events
- AWS re:Invent 2022 - Deliver great experiences with QUIC on Amazon CloudFront (NET401) - YouTube
セッション内で新規に公開？されたアップデート
以上、セッション内容について関連リンクなどとともにまとめてきたわけですが、ここでセッション内でアップデートと紹介されつつ、What's New on AWSなどでまだ確認できていないアップデートについて再度振り返っておきましょう。2点あります。
2つのCloudFrontヘッダの追加
1つ目はJA3 Fingerprinting on CloudFrontで紹介があった、Header informationに関するCloudFront HTTPヘッダです。具体的にはcloudfront-viewer-header-orderとcloudfront-viewer-header-countの2つですね。2022/12/07現在、まだアップデート情報やドキュメントの更新はなく、マネジメントコンソールのOrigin request policyでも選択項目には表示されない状況でした。
しかし、Origin request policyでヘッダを追加する際に[Add Custom]ボタンよりヘッダを指定することで利用可能となるようでした。正式なアップデート情報がないためあくまで推測になりますが、CloudFrontがViewerから受け取るヘッダの順序、ならびにその数を示しているようですね。（オリジン側ではPHPで受け取ったリクエストヘッダ情報を出力するようにしています。）
% curl https://dl7vxxxxxxxxx.cloudfront.net <p>Host: ec2-18-xxx-xxx-172.ap-northeast-1.compute.amazonaws.com</p> <p>User-Agent: Amazon CloudFront</p> <p>X-Amz-Cf-Id: z3RPqxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxHw==</p> <p>Connection: Keep-Alive</p> <p>Via: 2.0 c074xxxxxxxxxxxxxxxxxxxxxxxxbb2e.cloudfront.net (CloudFront)</p> <p>X-Forwarded-For: 2axx:xxxx:xxxx:xx::xx:xd</p> <p>CloudFront-Viewer-Header-Order: host:user-agent:accept</p> <p>CloudFront-Viewer-Header-Count: 3</p>
CloudFront continuous deploymentのIPベース振り分け
2つ目はCloudFrontの最新機能であるcontinuous deployment（継続的デプロイメント）のステージングディストリビューション（New application code）への振り分け方式についてです。AWS BlogやAWS What's Newで現段階（2022/12/07）で公開されている情報では、重み付け（Weight-based）とヘッダーベース（Header-based）の2種類のみ対応しているという状況です。
マネージメントコンソールで確認しても以下の通り、Weight-basedとHeader-basedの選択となっていますね。
ただこのセッション中、2回ほど「Viewer IP based」と言っています。（その1、その2）英語が不得手な筆者が勘違いしている可能性もありますが、ビューアIPベース（Viwer-IP-based）、つまりクライアントのIPアドレスによってステージングディストリビューションに振り分ける、という方式のアップデートが期待できるかと思います。
私も以下ブログエントリ執筆時にHeader-basedな振り分けを確認した際、curlコマンドなどでのStaging Distributionの動作確認は容易に行えたのですが、Webブラウザでの確認に難儀しました。ブラウザの拡張ツールでリクエスト時のHeaderを追加するかたちになると思うのですが、拡張ツールの選定など、なかなか手間ではあるんですよね。そんなとき、たしかにViewerのIPベースでStaging Distributionへの振り分けができると便利だなと思いました。
実はHeader-basedな振り分けを確認したあと、その延長でCloudFront Functionsを使って特定のIPアドレスであればリクエストヘッダを追加、このリクエストヘッダでStaging Distributionへの振り分けができないか、ということも試したのですが、これはうまくいきませんでした。セッション中のスライドでもあったように、動作としてはCloudFront Distributionに到達する前にSelection PolicyでPrimaryかStagingかの振り分けを行っているかと思います。そのため、どちらかのDistributionに割り振られたあとの実行となるCloudFront Functionsでヘッダを追加しても、時既に遅しという動作になるのかなと考えています。
まとめ
AWS re:Invent 2022 Breakout Session「Optimizing performance with CloudFront: Every millisecond matters (NET313)」についてまとめてみました。CloudFrontのアップデート情報については適宜DevelopersIO内ブログエントリへの関連リンクも付与していますので、このセッション内容プラスDevelopersIOのブログエントリ、そしてそこからリンクされているAWS What's Newなどの情報でここ半年ほどのアップデート内容の多くを、バッチリキャッチアップできるのではないかと思います。
また本エントリではセッション内で触れられたアップデート情報について多めにレポートしていますが、Mapbox社の事例についてもCloudFrontの機能をフル活用し、高速化によりユーザエクスペリエンスを向上させるすばらしいものになっています。ぜひとも冒頭に記載しているYouTubeのリンクからセッション動画を視聴いただければと思います。
![[アップデート] Application Load Balancer コンソールから CloudFront + WAF を統合出来るようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f650a3011b384cc3781610c17755bc71/c37c67c9bc40b72e6dce1a49f4153283/elastic-load-balancing)
