１．前回の振り返り

皆さん、こんにちは！
この記事はタイトル通り、AWSのド初心者である私が、シナリオを題材に構成図を作る、という内容になっています。
ご興味のある方は、よければ前回の記事をお読み頂けると嬉しいです。
↓
https://qiita.com/yamamoto_KC/items/769520bd9de03047da65

では、簡単に前回の振り返りです。
①シナリオ

②作成した構成図

③答え合わせ（改善点）
～以下、AIからの返答です～

改善点・アドバイス

Webアプリ（SPA）の配信経路が抜けている
ユーザーはまず「Webアプリ（SPA）」にアクセスしますが、その静的ファイル（HTML/JS/CSS）はS3＋CloudFrontで配信するのが一般的です。
今回の図では「動画配信」だけになっているので、アプリ配信の流れも追加するとより実践的です。
例：
ユーザー
↓
Route 53
↓
CloudFront（ACM）
↓
S3（Webアプリ的ファイル）

Cognito（ユーザー認証）の記載
ユーザー認証・認可はCognitoを使うのが一般的です。API GatewayやWebアプリの近くにCognitoを配置し、「認証」の流れを矢印で示すとベストです。

CloudFrontとLambda@Edgeの関係
Lambda@EdgeはCloudFrontの「中」で動くイメージ、CloudFrontの横や下に小さく添える形が分かりやすいです。
CloudFront→Lambda@Edge→S3という直列ではなく、「CloudFrontのリクエスト時にLambda@Edgeが動く」という表現がベストです。

WAFの位置
WAFはCloudFrontやAPI Gatewayの「前」に配置するのが一般的です（リクエストを最初に検査するため）。

ACMの表現
ACMは「証明書を提供する」だけなので、CloudFrontやAPI Gatewayの横に「ACM（証明書）」と注釈で表現するのが一般的です。

GatewayとCloudFrontの関係
APIリクエストと動画配信は別経路です。API Gatewayは動画ファイルの配信には関与しません。

～ここまで～

２．いざ！改善！-①

では、AIからの採点に沿って１つずつ修正をしていきましょう。
まずは１つめから！

Webアプリ（SPA）の配信経路が抜けている*
ユーザーはまず「Webアプリ（SPA）」にアクセスしますが、その静的ファイル（HTML/JS/CSS）はS3＋CloudFrontで配信するのが一般的です。
今回の図では「動画配信」だけになっているので、アプリ配信の流れも追加するとより実践的です。
例：
ユーザー
↓
Route 53
↓
CloudFront（ACM）
↓
S3（Webアプリ的ファイル）

・・・ふむふむ。
実際であれば『配信用アプリ取得→ログイン認証→動画が配信される』という３段階であったところ、後半の２段階しか構成図が作られてないですよ、ということですね。
上記で流れが書いてありますが、細かくはどういうことか？AIに聞いてみましょう。

具体的な流れ
ユーザーがWebブラウザで特定のURLにアクセス（例: https://example.com）
Route 53がドメインをCloudFrontに紐づける
CloudFrontがS3から静的ファイル（HTML/JS/CSS）を取得
これらのファイルがユーザーのブラウザに配信される
ブラウザがこれらのファイルを読み込み・実行することで、Webアプリ（SPA）が起動する

とのことです。
あくまでスマホやPCにアプリをインストールするわけでは無いみたいですね。
さて、早速構成図に追加していきましょう。

早速アプリ取得を上に追記してみました！
さあ、この調子でどんどん行きましょう。

２．いざ！改善！-②

Cognito（ユーザー認証）の記載
ユーザー認証・認可はCognitoを使うのが一般的です。API GatewayやWebアプリの近くにCognitoを配置し、「認証」の流れを矢印で示すとベストです。

・・・ふむ。
これを追記するには、まずはCognitoを理解する必要がありそうですね。

【Cognitとは？】
AWS Cognitoは、ウェブやモバイルアプリに簡単にユーザー管理と認証機能を追加できるAWSのサービスです。

なるほど。
Cognitを使うと、ログイン画面（システム）を導入する時に、一から設計しなくてもいいようです。
・・・いや便利だな！？
調べながら「すごー！」なんて独り言を言ってしまいました。
さて、早速構成図に追記していきましょう。

作成しながら気付いたのですが、Cognitは直接S3と繋がるわけではなく、あくまでwebアプリへの認証をした上で、webアプリがS3と繋がる・・・といった流れになるそうです。
なんだかいい感じの構成図になってきましたね。
この調子でどんどんいきましょう！

２．いざ！改善！-③

CloudFrontとLambda@Edgeの関係
Lambda@EdgeはCloudFrontの「中」で動くイメージ、CloudFrontの横や下に小さく添える形が分かりやすいです。
CloudFront→Lambda@Edge→S3という直列ではなく、「CloudFrontのリクエスト時にLambda@Edgeが動く」という表現がベストです。

・・・ほえ～～。
ﾎﾟｶ━(　ºдº　)━ﾝ...

あれ、Lambdaって独立したサービスじゃないの？？
ここで謎が増えてきましたね。
調べてみましょう。

【Lambda@Edgeについて】
Lambda@Edge は通常の Lambda とは異なる特性 を持ちます。
Lambda@Edge はCloudFrontのエッジロケーション内で実行される特殊なタイプの Lambda 関数 です。

だそうです。
へえ・・・全然知らなかった・・・。
ここで一つ賢くなったところで、早速構成図へ落とし込んでみましょう。

うん、こんな感じでいいんじゃないでしょうか。
では次ィ！

２．いざ！改善！-④

WAFの位置
WAFはCloudFrontやAPI Gatewayの「前」に配置するのが一般的です（リクエストを最初に検査するため）。

と、AIさんは仰っています。
ただ私の感覚的にWAFはAPI Gatewayにアタッチするものなのでは？
と思ったので、調べてみました。

はい。
というわけで、結論WAFの表記は正しいようです。
AIさん・・・まだまだですね(＊｀ω´＊)ﾄﾞﾔｯ（←おい）
API GatewayにWAFをアタッチして、ACMでSSL/TLS証明書を提供しているという表現になります。
ここでは修正なしでいきましょう。

２．いざ！改善！-⑤

ACMの表現
ACMは「証明書を提供する」だけなので、CloudFrontやAPI Gatewayの横に「ACM（証明書）」と注釈で表現するのが一般的です。

これに関しては構成の間違いというよりは、書き方の問題ですね。
一旦今回はそのままでいきましょう。

２．いざ！改善！-⑥

GatewayとCloudFrontの関係
APIリクエストと動画配信は別経路です。API Gatewayは動画ファイルの配信には関与しません。

・・・んん？？
既に構成図内の②APIリクエスト、と③動画配信、で経路は分けているはずですが・・・。
AIの誤認識っぽい気もしますが、一応調べてみましょう。

結論から言えば合っていましたね。
しかし、嬉しい誤算というか、想定していた要件以外のものも現状の構成で満たせているようです。
構成図としてはこれで完了！
と言いたいところですが、今回は勉強のためですので、分かりやすいように追記していきましょう。

３．今回の要件を満たせるように追記しよう！

まずは最初を振り返って、今回のシナリオを思い出してみます。
今回は

【シナリオ】
『グローバル向け動画配信プラットフォームの設計』

【要件】
・世界中のユーザーに対して、動画を低遅延、高品質で配信する。
・コンテンツの著作権保護、アクセス制御、キャッシュ戦略、トラフィック急増時のスケーラビリティも考慮する。

でした。
シナリオ自体は構成図で満たせているので、注目すべきは要件の方ですね。

世界中のユーザーに対して、動画を低遅延、高品質で配信する
↓
これはCloudFlontで要件を満たしています。
CloudFlontは世界中にエッジロケーションがあり、ユーザーから近いところから配信をします。
つまり低遅延になるということです。
また、CloudFlontには自動スケーリング機能があり、アクセス数の急増にも自動で対応してくれます。
結果、トラフィックが集中しても配信品質を維持＝高品質で配信、という要件が満たせるわけですね。

コンテンツの著作権保護、アクセス制御、キャッシュ戦略、トラフィック急増時のスケーラビリティも考慮する。
↓
ここは分解して考えていきましょう。

【著作権保護】
CloudFlontの署名付きURL、S3のバケットポリシー（CloudFlontからのアクセスに限定する）ことで満たせます。

【アクセス制御】
WAFによって満たせます。
CloudFrontにアタッチし、IP制限・不正リクエスト遮断などを実施します。

【キャッシュ戦略】
CloudFlontにはキャッシュ機能があり、一度配信した動画はS3まで取りに行かずとも、エッジロケーションに保存されたキャッシュを利用できます。
これで、ユーザーへ低遅延で配信できますね。

【トラフィック急増時のスケーラビリティ】
CloudFlont、S3で満たせます。
どちらも自動でスケーリングしてくれるので、急激なアクセス増加にも自動で対応できるというわけですね。

４．まとめ

さて、すべての要件を満たした構成図が完成しました。
改めてこちらです。
どんっ！

うん、それっぽいのができたんじゃないでしょうか！
今回はこれで終了になりますが、いかがだったでしょうか？
少しでも参考になったものがあれば幸いです。
これからも初心者エンジニアとして、挑戦したことを記事化していこうと思うので、また私の記事に巡り合えた際はぜひよろしくお願いします！