導入
ここまでの技術（スケーリング・キャッシュ・非同期化）を正しく使っても、そもそもの土台となるサービス選びを間違えていては性能は出ません。最後に、レイヤーごとに「どういう要件ならどのサービスを選ぶか」を整理します。
説明
コンピュート層
| 要件 | 選ぶサービス |
|---|---|
| 細かく制御したい・特殊なOS/ミドルウェア構成 | EC2 |
| インフラ管理をなくしたい・イベント駆動の短時間処理 | Lambda |
| コンテナ化されたアプリを運用したい | ECS / EKS（Fargateならサーバー管理も不要） |
| 予測不能なバッチ・機械学習の演算負荷 | Lambda（短時間）/ Batch（長時間バッチ） |
| 要件 | 選ぶサービス |
|---|---|
| オブジェクト（画像・動画・ログなど）を大量に保存 | S3 |
| 複数EC2から同時マウントする共有ファイルシステム | EFS |
| 高IOPSが必要なDBのブロックストレージ | EBS（プロビジョンドIOPS SSD） |
| 超高速な機械学習・HPC向けの並列ファイルシステム | FSx for Lustre |
| 要件 | 選ぶサービス |
|---|---|
| 一般的なリレーショナルDB | RDS |
| リレーショナルDBで極めて高い性能・自動スケール | Aurora（Aurora Serverlessなら自動でキャパシティ調整） |
| キー・バリューで超低レイテンシー・大規模スケール | DynamoDB |
| インメモリの超高速キャッシュ/セッションストア | ElastiCache |
ネットワーク層
| 要件 | 選ぶサービス |
|---|---|
| 静的コンテンツを世界中に低レイテンシーで配信 | CloudFront |
| TCP/UDPレベルでグローバルなユーザーを最寄りの健全なエンドポイントへ振り分けたい | Global Accelerator |
| リージョン内でのトラフィック分散 | Elastic Load Balancing |
flowchart TD
Global["グローバルユーザー向け"] --> CF["CloudFront<br/>（静的コンテンツ配信）"]
Global --> GA["Global Accelerator<br/>（TCP/UDPをAWSグローバルネットワーク経由で高速中継）"]
CF --> Origin["オリジン（S3/ALBなど）"]
GA --> Origin
特にグローバル展開するシステムでは、CloudFront（コンテンツ配信の高速化）と Global Accelerator（TCP/UDPトラフィック自体をAWSのバックボーンネットワーク経由で運び、ユーザーを最も健全でレイテンシーの低いエンドポイントへ振り向ける）の使い分けが問われます。CloudFrontはキャッシュ可能なコンテンツ配信に強く、Global Acceleratorはキャッシュできない動的トラフィックやゲーム・IoTのようなノンHTTPプロトコルにも対応できる点が違いです。
読んでみよう
SAAの性能問題は「要件（レイテンシー・スループット・データの性質）」→「対応するAWSサービス」の対応表を頭に持っているかどうかで決まります。第2〜9章で登場したサービスを、この章の4つの表に立ち返って整理しておくと、本番の選択肢を素早く絞り込めるようになります。