AWS_Solutions-Architect-Associate 試験対策：Domain2 弾力性に優れたアーキテクチャの設計

Last updated at 2026-01-18Posted at 2026-01-18

自主学習用のまとめノートです

試験配点：26%（採点対象コンテンツ）
AWS における高可用性、耐障害性、災害対策の設計から、疎結合アーキテクチャ、スケーラビリティまで幅広くカバーします。

Domain 2 の構成

試験ガイドによると、Domain 2 は以下の 2 つのタスクステートメントで構成されています。

タスク	内容	主なトピック
タスク 1	スケーラブルで疎結合なアーキテクチャを設計する	Auto Scaling、SQS、Lambda、API Gateway、マイクロサービス
タスク 2	高可用性、フォールトトレラントなアーキテクチャを設計する	マルチAZ、DR戦略、Route 53、Aurora Global Database

学習のポイント

「なぜ疎結合が重要か」 を理解することが鍵
スケーリングの方向性（垂直 vs 水平）の使い分けを押さえる
DR 戦略の選択基準（RTO/RPO とコスト）を理解する
試験では「最も高可用性」「最もコスト効率」などの条件に注意

第1章: 弾力性の基礎概念

この章で学ぶこと

弾力性（Resilience）の定義と重要性
高可用性、耐障害性、災害対策の違い
疎結合と密結合の設計思想
スケーリング戦略の基本

1.1 弾力性（Resilience）とは

弾力性とは、システムが障害から回復し、需要の変化に適応する能力のことです。AWS Well-Architected Framework では、信頼性の柱（Reliability Pillar）として重要視されています。

弾力性を実現するための主要な要素：

要素	説明	AWS での実現例
冗長性	複数のリソースで同じ機能を提供	マルチAZ、マルチリージョン
自動回復	障害発生時に自動で復旧	Auto Scaling、ヘルスチェック
疎結合	コンポーネント間の依存性を最小化	SQS、SNS、API Gateway
スケーラビリティ	需要に応じてリソースを拡縮	EC2 Auto Scaling、Lambda

1.2 高可用性（HA）、耐障害性（FT）、災害対策（DR）の違い

これらの用語は混同されがちですが、それぞれ異なる目的と実装方法があります。

高可用性（High Availability）

目的: システムのダウンタイムを最小限に抑える

高可用性とは、システムが長期間にわたって継続的に運用可能な状態を維持することです。一般的に、可用性は「稼働時間の割合」で表されます。

可用性レベル	年間ダウンタイム	実現に必要な設計
99%（Two 9s）	約 3.65 日	単一サーバー + バックアップ
99.9%（Three 9s）	約 8.76 時間	複数サーバー + ロードバランサー
99.99%（Four 9s）	約 52 分	マルチAZ + 自動フェイルオーバー
99.999%（Five 9s）	約 5 分	マルチリージョン + リアルタイムレプリケーション

AWS での実装例:

Elastic Load Balancing（ELB）で複数のインスタンスに分散
RDS マルチAZ でデータベースを冗長化
Route 53 ヘルスチェックでフェイルオーバー

耐障害性（Fault Tolerance）

目的: 障害が発生してもサービスを中断しない

耐障害性は、システムの一部に障害が発生しても、全体としての機能を維持する能力です。高可用性がダウンタイムの「最小化」を目指すのに対し、耐障害性は「ゼロダウンタイム」を目指します。

上図のように、1つのインスタンスに障害が発生しても、他のインスタンスがトラフィックを処理し続けます。

災害対策（Disaster Recovery）

目的: 大規模障害からの復旧

災害対策は、自然災害やリージョン全体の障害など、大規模な問題からシステムを復旧させる戦略です。詳細は第5章で解説します。

主要指標:

RPO（Recovery Point Objective）: 許容できるデータ損失量（時間で表現）
RTO（Recovery Time Objective）: 許容できるダウンタイム

1.3 疎結合と密結合

アーキテクチャの設計において、コンポーネント間の結合度は非常に重要です。

密結合（Tight Coupling）

特徴:

コンポーネント間の直接的な依存関係
一方の障害が全体に波及
スケーリングが困難

問題点:

例: ECサイトの注文処理
1. ユーザーが注文ボタンをクリック
2. Web サーバーがバックエンドを同期呼び出し
3. バックエンドが応答するまでユーザーは待機
4. バックエンドがダウンすると、Web サーバーもエラー

疎結合（Loose Coupling）

特徴:

中間層（キュー、イベントバス）を介した通信
コンポーネント間の独立性が高い
個別にスケーリング可能

メリット:

例: ECサイトの注文処理（疎結合版）
1. ユーザーが注文ボタンをクリック
2. Web サーバーがキューにメッセージを送信
3. ユーザーには即座に「注文を受け付けました」と表示
4. ワーカーが非同期でメッセージを処理
5. ワーカーがダウンしても、メッセージはキューに保持される

疎結合 vs 密結合の比較

観点	密結合	疎結合
依存関係	強い（直接呼び出し）	弱い（中間層経由）
障害の影響	連鎖的に波及	局所化される
スケーリング	全体を同時にスケール	個別にスケール可能
変更の容易さ	影響範囲が広い	独立して変更可能
複雑さ	シンプル	やや複雑
レイテンシー	低い（同期）	やや高い（非同期）

試験でのポイント:

「疎結合」「スケーラブル」というキーワードが出たら → SQS、SNS、EventBridge を検討
「即座に応答」「非同期処理」という要件 → キューイングが有効

1.4 垂直スケーリングと水平スケーリング

システムの処理能力を向上させる方法として、2つのスケーリング手法があります。

垂直スケーリング（Scale Up / Scale Down）

個々のリソースの性能を上げる（または下げる）方法です。

例: EC2 インスタンスタイプを t3.small → t3.xlarge に変更

メリット	デメリット
シンプルな実装	上限がある（最大インスタンスサイズ）
アプリケーション変更不要	ダウンタイムが発生する場合がある
単一障害点のまま	コスト効率が悪いことがある

水平スケーリング（Scale Out / Scale In）

リソースの数を増やす（または減らす）方法です。

例: EC2 インスタンスを 2 台 → 4 台に増加

メリット	デメリット
理論上無限にスケール可能	アプリケーションがステートレスである必要
高可用性を同時に実現	ロードバランサーが必要
コスト効率が良い	セッション管理の考慮が必要

ステートレスとステートフル

水平スケーリングを実現するには、アプリケーションをステートレスに設計することが重要です。

ステートレス化のポイント:

セッション情報を ElastiCache や DynamoDB に外部化
ファイルは S3 に保存
データベースは RDS や DynamoDB を使用

試験でのポイント:

「スケーラブル」「Auto Scaling」が要件 → ステートレス設計が前提
「セッション維持」が必要 → ElastiCache またはスティッキーセッション

第2章: スケーラブルなコンピューティング

この章で学ぶこと

EC2 Auto Scaling の仕組みと設定
Elastic Load Balancing の種類と使い分け
サーバーレスコンピューティング（Lambda、Fargate）

2.1 EC2 Auto Scaling

EC2 Auto Scaling は、EC2 インスタンスの数を需要に応じて自動的に調整するサービスです。

Auto Scaling グループ（ASG）の設定

設定項目	説明	例
最小キャパシティ	常に維持するインスタンス数	2
希望キャパシティ	通常時のインスタンス数	2
最大キャパシティ	スケールアウト時の上限	10

起動テンプレート vs 起動設定

項目	起動テンプレート	起動設定
推奨度	推奨（新しい方式）	レガシー
バージョン管理	あり	なし
スポットインスタンス	対応	限定的
複数インスタンスタイプ	対応	非対応

スケーリングポリシーの種類

Auto Scaling がいつ、どのようにスケールするかを定義します。

1. ターゲット追跡スケーリング（推奨）

特定のメトリクスを目標値に維持するように自動調整します。

例: CPU 使用率を 50% に維持
- CPU が 60% に上昇 → インスタンスを追加
- CPU が 40% に低下 → インスタンスを削減

事前定義メトリクス	説明
ASGAverageCPUUtilization	平均 CPU 使用率
ASGAverageNetworkIn	平均ネットワーク受信量
ASGAverageNetworkOut	平均ネットワーク送信量
ALBRequestCountPerTarget	ALB のターゲットあたりリクエスト数

2. ステップスケーリング

アラームの閾値を超えた量に応じて、段階的にスケールします。

例: CPU 使用率に基づくステップスケーリング
- 50-60%: 1 インスタンス追加
- 60-70%: 2 インスタンス追加
- 70% 以上: 3 インスタンス追加

3. シンプルスケーリング

単一のアラームに基づいてスケールします。クールダウン期間中は追加のスケーリングが発生しません。

4. スケジュールスケーリング

特定の日時にスケーリングアクションを実行します。

例: 毎日 9:00 にキャパシティを 10 に増加、18:00 に 2 に減少

5. 予測スケーリング

機械学習を使用して需要を予測し、事前にスケールします。

終了ポリシー（重要）

スケールイン時にどのインスタンスを終了するかを決定します。

デフォルト終了ポリシーの動作:

AZ 間のバランスを確認（インスタンスが多い AZ を優先）
最も古い起動設定/テンプレートのインスタンスを選択
次の課金時間に最も近いインスタンスを選択
ランダムに選択

試験でのポイント:
サンプル問題で「AZ-a に 4 インスタンス、AZ-b に 3 インスタンスある場合、スケールインではどうなるか？」という問題が出ています。
→ 正解: まず AZ-a（インスタンスが多い方）を選択してから終了ポリシーを適用

登録解除遅延（Deregistration Delay）

ターゲットグループからインスタンスを削除する際、処理中のリクエストを完了させるための待機時間です。

設定のポイント:

デフォルト: 300 秒（5 分）
最大: 3600 秒（1 時間）
処理時間が長いアプリケーションでは、登録解除遅延を増やす

試験でのポイント:
「スケールイン時にユーザーリクエストが完了しない」→ 登録解除遅延を増やす

クールダウン期間

スケーリングアクション後、次のアクションまでの待機時間です。

設定	デフォルト値	説明
デフォルトクールダウン	300 秒	すべてのスケーリングアクションに適用
スケールアウトクールダウン	指定可能	スケールアウト後の待機時間
スケールインクールダウン	指定可能	スケールイン後の待機時間

ライフサイクルフック

インスタンスの起動/終了時にカスタムアクションを実行できます。

ユースケース:

起動時: ソフトウェアのインストール、設定の適用
終了時: ログの退避、セッションのドレイン

2.2 Elastic Load Balancing（ELB）

ELB は、トラフィックを複数のターゲットに分散するマネージドサービスです。

ロードバランサーの種類

ALB vs NLB vs GLB 比較表

項目	ALB	NLB	GLB
OSI レイヤー	7（アプリケーション層）	4（トランスポート層）	3（ネットワーク層）
プロトコル	HTTP, HTTPS, gRPC	TCP, UDP, TLS	IP プロトコル
パフォーマンス	高い	非常に高い	高い
固定 IP	なし	あり（Elastic IP）	なし
URL ベースルーティング	対応	なし	なし
WebSocket	対応	対応	なし
SSL 終端	対応	対応	なし
主なユースケース	Web アプリ、マイクロサービス	高パフォーマンス、固定 IP 必要	サードパーティアプライアンス

Application Load Balancer（ALB）詳細

ALB は HTTP/HTTPS トラフィックの高度なルーティングに最適です。

ルーティング条件:

ルール	説明	例
パスベース	URL パスで振り分け	`/api/*` → API サーバー
ホストベース	ホスト名で振り分け	`api.example.com` → API
HTTP ヘッダー	ヘッダー値で振り分け	`User-Agent` による分岐
HTTP メソッド	メソッドで振り分け	`POST` → 書き込みサーバー
クエリ文字列	パラメータで振り分け	`?version=2` → v2 サーバー
ソース IP	送信元 IP で振り分け	特定 IP → 管理画面

Network Load Balancer（NLB）詳細

NLB は超低レイテンシーと高スループットが必要な場合に使用します。

特徴:

極めて高いパフォーマンス: 毎秒数百万リクエストを処理
固定 IP アドレス: AZ ごとに Elastic IP を割り当て可能
ソース IP の保持: クライアントの IP アドレスがそのまま渡される
TCP/UDP 対応: 非 HTTP プロトコルにも対応

ユースケース:

ゲームサーバー
IoT デバイスとの通信
金融取引システム
VoIP アプリケーション

Gateway Load Balancer（GLB）

サードパーティの仮想アプライアンス（ファイアウォール、IDS/IPS など）を透過的に挿入するためのロードバランサーです。

ヘルスチェック

ロードバランサーは定期的にターゲットの健全性を確認します。

設定項目	説明	デフォルト
プロトコル	チェックに使用するプロトコル	HTTP
パス	チェック対象のパス	/
ポート	チェック対象のポート	トラフィックポート
正常しきい値	正常と判定するまでの連続成功回数	5
異常しきい値	異常と判定するまでの連続失敗回数	2
タイムアウト	レスポンス待機時間	5 秒
間隔	チェック間隔	30 秒

スティッキーセッション（セッションアフィニティ）

同じクライアントからのリクエストを同じターゲットに送り続ける機能です。

種類:

種類	説明	持続時間
Duration-based	ALB が生成する Cookie	1 秒〜7 日
Application-based	アプリケーションが生成する Cookie	アプリ依存

注意点:

スティッキーセッションは負荷分散を不均等にする可能性がある
スケールイン時、スティッキーセッションがあってもインスタンスは終了される
推奨: セッション情報を ElastiCache に外部化

クロスゾーンロードバランシング

複数の AZ にまたがってトラフィックを均等に分散する機能です。

上図の場合、AZ-1 の各インスタンスは 25%、AZ-2 のインスタンスは 50% のトラフィックを受けます（不均等）。

クロスゾーンを有効にすると、すべてのインスタンスに均等に分散されます。

ロードバランサー	デフォルト	料金
ALB	有効	無料
NLB	無効	AZ 間転送料金がかかる
GLB	無効	AZ 間転送料金がかかる

2.3 サーバーレスコンピューティング

サーバーレスでは、インフラストラクチャの管理なしにコードを実行できます。

AWS Lambda

Lambda は、イベントに応じてコードを実行するサーバーレスコンピューティングサービスです。

Lambda の特徴と制限:

項目	制限/特徴
最大実行時間	15 分
メモリ	128 MB 〜 10,240 MB
一時ストレージ	/tmp に最大 10 GB
デプロイパッケージ	50 MB（zip）、250 MB（解凍後）
同時実行数	デフォルト 1,000（引き上げ可能）
コールドスタート	初回実行時に遅延が発生

ユースケース:

ユースケース	説明
API バックエンド	API Gateway と組み合わせて REST API を構築
データ処理	S3 にアップロードされたファイルの処理
スケジュール実行	CloudWatch Events で定期実行
ストリーム処理	Kinesis や DynamoDB Streams の処理

試験でのポイント:

実行時間が 15 分を超える処理 → Lambda は不適切
ステートフルな処理 → Lambda は不適切（ステートレス設計が前提）

AWS Fargate

Fargate は、コンテナ用のサーバーレスコンピューティングエンジンです。

EC2 vs Fargate 比較:

項目	EC2 起動タイプ	Fargate
インフラ管理	必要（EC2 の管理）	不要
スケーリング	EC2 + タスクのスケーリング	タスクのスケーリングのみ
料金	EC2 インスタンス料金	vCPU とメモリの使用量
GPU 対応	対応	対応（制限あり）
大規模ワークロード	コスト効率が良い場合あり	シンプルだがコスト高の場合あり

Fargate を選ぶ場面:

インフラ管理を最小化したい
予測不可能なワークロード
バッチ処理やマイクロサービス

第3章: 疎結合アーキテクチャ

この章で学ぶこと

Amazon SQS によるメッセージキューイング
Amazon SNS による Pub/Sub メッセージング
Amazon EventBridge によるイベント駆動型アーキテクチャ
AWS Step Functions によるワークフロー管理
Amazon API Gateway による API 管理

3.1 Amazon SQS（Simple Queue Service）

SQS は、フルマネージドなメッセージキューイングサービスです。

標準キュー vs FIFO キュー

SQS には 2 種類のキューがあります。

項目	標準キュー	FIFO キュー
スループット	無制限	最大 70,000 TPS（2025年時点）
配信順序	ベストエフォート	厳密に順序保証
重複配信	少なくとも 1 回（重複あり）	正確に 1 回
キュー名	任意	`.fifo` で終わる必要あり
料金	安い	やや高い

試験でのポイント:

「順序を保証」「重複を防ぐ」→ FIFO キュー
「最大スループット」「コスト重視」→ 標準キュー

可視性タイムアウト

メッセージが処理中に他のコンシューマーから見えなくなる時間です。

設定	値
デフォルト	30 秒
最小	0 秒
最大	12 時間

注意: 可視性タイムアウト内に処理が完了しないと、メッセージが再度可視になり、重複処理される可能性があります。

デッドレターキュー（DLQ）

処理に失敗したメッセージを隔離するためのキューです。

設定のポイント:

maxReceiveCount: 何回受信失敗したら DLQ に移動するか（デフォルト 10 回）
DLQ のタイプはソースキューと同じである必要がある（FIFO → FIFO）
メッセージ保持期間は DLQ でリセットされる

試験でのポイント:
サンプル問題で「4 回の再試行後に失敗したメッセージを保存する」という要件がありました。
→ 正解: SQS デッドレターキューを作成し、maxReceiveCount を 4 に設定

ロングポーリング vs ショートポーリング

方式	説明	設定
ショートポーリング	すぐに応答を返す（メッセージがなくても）	`WaitTimeSeconds = 0`
ロングポーリング	メッセージが来るまで待機（最大 20 秒）	`WaitTimeSeconds = 1-20`

ロングポーリングのメリット:

API コールの削減（コスト削減）
CPU 使用率の低減
メッセージの即時取得

3.2 Amazon SNS（Simple Notification Service）

SNS は、Pub/Sub（発行/購読）モデルのメッセージングサービスです。

SQS vs SNS の違い

項目	SQS	SNS
モデル	キュー（プル型）	Pub/Sub（プッシュ型）
コンシューマー数	通常 1 つ	複数
メッセージ保持	最大 14 日間	保持しない
再処理	可能	不可能
順序	FIFO キューで保証	標準トピックでは保証なし

ファンアウトパターン

SNS と SQS を組み合わせて、1 つのメッセージを複数のシステムに配信します。

メリット:

各処理システムが独立して動作
一方の障害が他に影響しない
それぞれ異なる速度で処理可能

3.3 Amazon EventBridge

EventBridge は、イベント駆動型アーキテクチャを構築するためのサーバーレスイベントバスです。

SNS との違い:

項目	SNS	EventBridge
イベントフィルタリング	基本的	高度なルールベース
スキーマ検出	なし	あり
SaaS 統合	なし	あり
スケジュール	なし	あり
アーカイブ/リプレイ	なし	あり

3.4 AWS Step Functions

Step Functions は、視覚的なワークフローを使用してサーバーレスアプリケーションを構築するサービスです。

主要な状態タイプ:

状態タイプ	説明
Task	作業を実行（Lambda、ECS など）
Choice	条件分岐
Parallel	並列実行
Wait	指定時間待機
Map	配列の各要素に対して処理
Succeed/Fail	実行の終了

ワークフロータイプ:

タイプ	特徴	料金
Standard	最大 1 年実行、履歴保持	状態遷移ごとに課金
Express	最大 5 分実行、高スループット	実行回数と時間で課金

ユースケース:

複雑な注文処理ワークフロー
ETL パイプライン
機械学習のトレーニングパイプライン
マイクロサービスのオーケストレーション

3.5 Amazon API Gateway

API Gateway は、API の作成、公開、管理を行うフルマネージドサービスです。

API タイプの比較

項目	REST API	HTTP API	WebSocket API
プロトコル	REST	HTTP	WebSocket
機能	フル機能	基本機能	双方向通信
料金	高い	安い（〜70% OFF）	接続時間ベース
認証	IAM, Cognito, Lambda	IAM, Cognito, OAuth 2.0	IAM, Cognito, Lambda
使用量プラン	あり	なし	なし
キャッシュ	あり	なし	なし

試験でのポイント:

「コスト重視」「シンプルな API」→ HTTP API
「使用量プラン」「API キー」「キャッシュ」→ REST API
「リアルタイム通信」「チャット」→ WebSocket API

スロットリングとクォータ

API Gateway には、API を保護するための制限があります。

制限	デフォルト
リージョンあたりの同時実行数	10,000 リクエスト/秒
アカウントあたりのバースト	5,000 リクエスト

使用量プラン:

API キーごとにリクエスト数を制限
バーストとレートの設定
クォータ（日/週/月単位）

第3.5章: 追加の重要トピック

3.6 キャッシュ戦略

キャッシュは、頻繁にアクセスされるデータを高速なストレージに保存することで、パフォーマンスを向上させます。

AWS のキャッシュサービス

サービス	レイヤー	ユースケース
Amazon CloudFront	エッジ（CDN）	静的コンテンツ、API レスポンス
Amazon ElastiCache	アプリケーション	セッション、DB クエリ結果
DAX（DynamoDB Accelerator）	データベース	DynamoDB の読み取り高速化
API Gateway キャッシュ	API	API レスポンスのキャッシュ

Amazon ElastiCache

インメモリデータストアのマネージドサービスです。

エンジン	特徴	ユースケース
Redis	高機能、永続化対応、レプリケーション	セッション管理、リーダーボード、Pub/Sub
Memcached	シンプル、マルチスレッド	シンプルなキャッシュ、大規模分散

Amazon CloudFront（CDN）

グローバルなコンテンツ配信ネットワークです。

CloudFront の主要機能:

機能	説明
エッジキャッシュ	世界中のエッジロケーションでコンテンツをキャッシュ
HTTPS	SSL/TLS 終端、ACM 証明書の統合
Lambda@Edge	エッジでのカスタム処理
オリジンアクセスコントロール	S3 への直接アクセスを制限

3.7 ストレージの種類と特性

AWS では、用途に応じた 3 種類のストレージを提供しています。

種類	サービス	特性	ユースケース
オブジェクトストレージ	S3	無制限、高耐久性、HTTP アクセス	静的ファイル、バックアップ、データレイク
ファイルストレージ	EFS, FSx	共有アクセス、POSIX 互換	複数 EC2 からの共有、CMS
ブロックストレージ	EBS	低レイテンシー、高 IOPS	OS、データベース、トランザクション処理

3.8 リードレプリカ

データベースの読み取り負荷を分散するための仕組みです。

リードレプリカ vs マルチ AZ の違い:

項目	リードレプリカ	マルチ AZ
目的	読み取りスケーリング	高可用性
レプリケーション	非同期	同期
読み取りクエリ	可能	不可
フェイルオーバー	手動昇格	自動
リージョン	同一/クロスリージョン	同一リージョン

リードレプリカを使用するタイミング:

読み取りが多いワークロード
レポート・分析クエリの分離
地理的に分散したユーザーへの読み取り

3.9 AWS マネージドサービス（その他）

AWS Transfer Family

SFTP、FTPS、FTP プロトコルでファイルを S3 または EFS に転送するマネージドサービスです。

ユースケース:

レガシーシステムとの連携
パートナーとのファイル交換
既存のファイル転送ワークフローの移行

AWS Secrets Manager

機密情報（データベースの認証情報、API キーなど）を安全に保存・管理するサービスです。

特徴:

自動ローテーション
RDS、Redshift、DocumentDB との統合
Lambda 関数でのシークレット取得

第4章: 高可用性アーキテクチャ

この章で学ぶこと

マルチ AZ 設計の基本
Amazon Route 53 のルーティングポリシー
データベースの高可用性オプション

4.1 マルチ AZ 設計

高可用性を実現するための基本は、複数のアベイラビリティーゾーン（AZ）にリソースを分散することです。

VPC サブネット設計のベストプラクティス

サブネットタイプ	配置するリソース	特徴
パブリック	ALB、NAT Gateway、踏み台サーバー	インターネットからアクセス可能
プライベート	EC2（アプリ）、Lambda	NAT 経由でインターネットにアクセス
データベース	RDS、ElastiCache	インターネットへのルートなし

ルートテーブルの基本

ルートテーブルは、サブネット内のトラフィックがどこに送信されるかを決定します。

パブリックサブネットのルートテーブル例:

送信先	ターゲット
10.0.0.0/16	local
0.0.0.0/0	igw-xxxx（インターネットゲートウェイ）

プライベートサブネットのルートテーブル例:

送信先	ターゲット
10.0.0.0/16	local
0.0.0.0/0	nat-xxxx（NAT Gateway）

ルートテーブルのポイント:

各サブネットは 1 つのルートテーブルに関連付け
より具体的なルート（longer prefix）が優先される
local ルートは VPC 内通信に必須（削除不可）

4.2 Amazon Route 53

Route 53 は、高可用性を備えた DNS サービスです。

ルーティングポリシーの一覧

ルーティングポリシー比較表

ポリシー	主な用途	ヘルスチェック	特徴
シンプル	単一リソース	不可	1 つのリソースを指す
加重	A/B テスト、段階的移行	可	重みに応じて分散
レイテンシー	グローバルアプリ	可	最も低遅延なリージョンへ
フェイルオーバー	災害対策	必須	プライマリ → セカンダリ
位置情報	地域別コンテンツ	可	大陸/国/州単位
地理的近接性	細かい制御	可	バイアス値で調整
複数値	シンプルな冗長化	可	最大 8 つの正常な IP
IP ベース	ISP 別ルーティング	可	CIDR ブロック指定

フェイルオーバールーティングの詳細

災害対策で最も重要なルーティングポリシーです。

試験でのポイント:
サンプル問題で「プライマリサイトがダウンした場合にバックアップサイトを表示する」という要件がありました。
→ 正解: Amazon S3 の静的ウェブサイトホスティング + Route 53 フェイルオーバールーティング

ヘルスチェック

Route 53 は定期的にエンドポイントの健全性を確認します。

設定項目	説明
プロトコル	HTTP、HTTPS、TCP
リクエスト間隔	10 秒または 30 秒
失敗しきい値	1〜10 回
リージョン	複数リージョンからチェック
文字列マッチング	レスポンス本文に特定の文字列が含まれるか

4.3 データベースの高可用性

RDS マルチ AZ

特徴:

項目	説明
レプリケーション	同期（データ損失なし）
フェイルオーバー	自動（60〜120 秒）
スタンバイへの読み取り	不可（フェイルオーバー専用）
料金	約 2 倍

フェイルオーバーのトリガー:

プライマリ AZ の障害
プライマリ DB インスタンスの障害
インスタンスタイプの変更
DB インスタンスのソフトウェアパッチ

RDS マルチ AZ クラスター（新機能）

従来のマルチ AZ とは異なり、読み取りスケーリングも可能な構成です。

Amazon Aurora

Aurora は、MySQL/PostgreSQL 互換の高性能データベースです。

Aurora の特徴:

項目	説明
ストレージ	自動で最大 128 TB まで拡張
レプリカ	最大 15 個
フェイルオーバー	通常 30 秒以内
可用性	3 AZ に 6 コピー
読み取りスケーリング	Aurora レプリカで対応

Aurora Global Database

複数リージョンにまたがる Aurora クラスターです。

Aurora Global Database の特徴:

項目	値
RPO（目標復旧時点）	通常 1 秒
RTO（目標復旧時間）	1 分未満
レプリケーション遅延	通常 1 秒未満
セカンダリリージョン数	最大 5 つ
セカンダリあたりのレプリカ	最大 16 個

フェイルオーバーオプション:

オプション	用途	RPO
スイッチオーバー	計画的な切り替え	0（データ損失なし）
フェイルオーバー	障害からの復旧	秒単位（レプリケーション遅延による）

試験でのポイント:
サンプル問題で「RPO 1 秒、RTO 1 分のマルチリージョン DR」という要件がありました。
→ 正解: Aurora Global Database

DynamoDB グローバルテーブル

DynamoDB でマルチリージョン、マルチマスター構成を実現します。

特徴:

各リージョンで読み書き可能
通常 1 秒以内でレプリケーション
最終的一貫性モデル

第5章: 災害対策（DR）戦略

この章で学ぶこと

RPO と RTO の概念
4 つの DR 戦略の詳細と比較
各戦略の選択基準

5.1 RPO と RTO

DR 戦略を選択する上で最も重要な 2 つの指標です。

指標	定義	ビジネスへの影響
RPO	障害時に失っても許容できるデータ量（時間で表現）	データ損失のコスト
RTO	障害発生から復旧までの許容時間	ダウンタイムのコスト

例:

RPO = 1 時間 → 最大 1 時間分のデータを失う可能性がある
RTO = 4 時間 → 障害発生から 4 時間以内に復旧する必要がある

5.2 4 つの DR 戦略

AWS では、RTO/RPO とコストのバランスに応じて 4 つの DR 戦略が推奨されています。

5.2.1 バックアップと復元（Backup and Restore）

最もシンプルで低コストな戦略です。

特徴:

項目	値
RTO	数時間（リソース作成が必要）
RPO	バックアップ頻度に依存（数時間）
コスト	最も低い
複雑さ	低い

適用シーン:

非クリティカルなシステム
長いダウンタイムを許容できる
予算が限られている

5.2.2 パイロットライト（Pilot Light）

最小限のコアシステムを DR リージョンで常時稼働させます。

特徴:

項目	値
RTO	数十分（EC2 起動、設定）
RPO	数分（レプリケーション遅延）
コスト	低〜中（DB のみ稼働）
複雑さ	中程度

適用シーン:

中程度の RTO/RPO 要件
一定のコスト制約がある
データベースが最重要

試験でのポイント:
サンプル問題で「パイロットライトの実装方法」が問われました。
→ 正解: EC2 インスタンスを AWS に作成して停止状態で保持し、障害時に起動

5.2.3 ウォームスタンバイ（Warm Standby）

縮小版のシステムを DR リージョンで常時稼働させます。

特徴:

項目	値
RTO	数分（スケールアップのみ）
RPO	秒単位
コスト	中〜高
複雑さ	中程度

パイロットライトとの違い:

項目	パイロットライト	ウォームスタンバイ
コンピューティング	停止	縮小版で稼働
トラフィック処理	不可	一部処理可能
RTO	数十分	数分

試験でのポイント:
サンプル問題で「最小限の実行インスタンスで RTO 5 分」という要件がありました。
→ 正解: ウォームスタンバイ

5.2.4 マルチサイト / Active-Active

両リージョンでフルキャパシティのシステムを稼働させます。

特徴:

項目	値
RTO	ゼロに近い
RPO	ゼロに近い
コスト	最も高い（2 倍以上）
複雑さ	高い

適用シーン:

ミッションクリティカルなシステム
ダウンタイムが許容できない
グローバルユーザーへの低レイテンシー提供

5.3 DR 戦略の比較表

戦略	RTO	RPO	コスト	運用複雑さ	適用シーン
バックアップと復元	数時間	数時間	$	低	非クリティカル
パイロットライト	数十分	数分	$$	中	中程度の要件
ウォームスタンバイ	数分	秒	$$$	中	重要システム
マルチサイト	ゼロ近い	ゼロ近い	$$$$	高	ミッションクリティカル

5.4 DR 戦略選択のフローチャート

第6章: ネットワーク接続

この章で学ぶこと

AWS Site-to-Site VPN の構成
AWS Direct Connect の特徴
Transit Gateway による接続の統合

6.1 AWS Site-to-Site VPN

オンプレミス環境と AWS VPC を暗号化された VPN トンネルで接続します。

必要なコンポーネント

コンポーネント	説明	設置場所
カスタマーゲートウェイ（CGW）	オンプレミスの VPN 機器を表すリソース	オンプレミス
仮想プライベートゲートウェイ（VGW）	VPC 側の VPN エンドポイント	AWS（VPC にアタッチ）
VPN 接続	CGW と VGW を結ぶトンネル	-

試験でのポイント:
サンプル問題で「Site-to-Site VPN に必要なコンポーネントは？」という問題がありました。
→ 正解: カスタマーゲートウェイと仮想プライベートゲートウェイ
→ 不正解の選択肢: インターネットゲートウェイ、NAT ゲートウェイ、API Gateway

VPN の特徴

項目	説明
帯域幅	最大 1.25 Gbps（トンネルあたり）
レイテンシー	インターネット経由のため変動
暗号化	IPsec
冗長性	2 本のトンネル（異なる AZ）
料金	接続料金 + データ転送料金

6.2 AWS Direct Connect

専用線で AWS とオンプレミスを接続します。

VPN vs Direct Connect 比較

項目	Site-to-Site VPN	Direct Connect
接続方式	インターネット経由	専用線
帯域幅	最大 1.25 Gbps	1 Gbps、10 Gbps、100 Gbps
レイテンシー	変動あり	安定・低レイテンシー
暗号化	IPsec（標準）	なし（MACsec オプション）
セットアップ	即日〜数日	数週間〜数ヶ月
コスト	低い	高い

使い分け:

VPN: 迅速なセットアップ、暗号化必須、コスト重視
Direct Connect: 高帯域幅、安定したレイテンシー、大量データ転送

6.3 AWS Transit Gateway

複数の VPC と VPN/Direct Connect を一元管理するハブです。

メリット:

VPC ピアリングの複雑なメッシュ構成を解消
集中管理が可能
ルーティングの一元化

Transit Gateway なしの場合:

第7章: コンテナとオーケストレーション

この章で学ぶこと

Amazon ECS の基本概念
Amazon EKS の特徴
起動タイプの選択（EC2 vs Fargate）

7.1 Amazon ECS（Elastic Container Service）

ECS は AWS ネイティブのコンテナオーケストレーションサービスです。

ECS の主要コンポーネント

コンポーネント	説明
クラスター	タスクを実行するリソースの論理グループ
タスク定義	コンテナの設定（イメージ、CPU、メモリなど）
タスク	タスク定義に基づいて実行されるコンテナのインスタンス
サービス	タスクの希望数を維持し、ロードバランサーと統合

7.2 Amazon EKS（Elastic Kubernetes Service）

EKS は Kubernetes のマネージドサービスです。

ECS vs EKS 比較

項目	ECS	EKS
オーケストレーター	AWS 独自	Kubernetes
学習曲線	低い	高い
AWS 統合	深い	標準的
ポータビリティ	AWS 限定	マルチクラウド可能
コミュニティ	AWS	大規模な OSS
料金（コントロールプレーン）	無料	$0.10/時間

選択の指針:

ECS を選ぶ場合: AWS に特化、シンプルさ重視、コスト重視
EKS を選ぶ場合: Kubernetes の経験あり、マルチクラウド、高度なカスタマイズ

7.3 アプリケーションのコンテナ移行

既存のアプリケーションをコンテナに移行する方法です。

AWS App2Container

既存の .NET および Java アプリケーションをコンテナ化するツールです。

移行手順:

分析: App2Container がアプリケーションを分析
コンテナ化: Dockerfile と必要なアーティファクトを生成
デプロイ: ECS または EKS にデプロイ

AWS Migration Hub

移行プロジェクト全体を追跡・管理するサービスです。

関連サービス:

サービス	用途
AWS Application Discovery Service	オンプレミス環境の検出
AWS Migration Hub	移行の進捗管理
AWS App2Container	コンテナ化
AWS DMS	データベース移行

7.4 起動タイプ: EC2 vs Fargate

コンテナを実行する基盤の選択です。

EC2 vs Fargate 比較表

項目	EC2 起動タイプ	Fargate
インフラ管理	必要（パッチ、スケーリング）	不要
料金モデル	EC2 インスタンス料金	vCPU + メモリ使用量
スポットインスタンス	対応	Fargate Spot 対応
GPU	対応	非対応
Windows コンテナ	対応	対応
大規模ワークロード	コスト効率が良い場合あり	シンプルだがコスト高の場合あり

選択の指針:

Fargate: 運用負荷を最小化、小〜中規模、バッチ処理
EC2: GPU が必要、大規模でコスト最適化、細かい制御が必要

第7.5章: 追加の高可用性トピック

7.4 Amazon RDS Proxy

RDS Proxy は、データベース接続をプーリングして管理するフルマネージドサービスです。

RDS Proxy のメリット:

メリット	説明
接続プーリング	多数のクライアントからの接続を効率的に管理
フェイルオーバー高速化	66% 高速なフェイルオーバー
IAM 認証	データベース認証に IAM を使用可能
Lambda との相性	接続の再利用でコールドスタート改善

ユースケース:

多数の Lambda 関数からの DB アクセス
予測不可能なワークロード
フェイルオーバー時間の短縮

7.5 AWS X-Ray（ワークロードの可視性）

X-Ray は、分散アプリケーションの分析とデバッグを行うサービスです。

X-Ray の機能:

機能	説明
サービスマップ	マイクロサービス間の依存関係を可視化
トレース分析	リクエストのエンドツーエンド追跡
パフォーマンス分析	レイテンシーのボトルネックを特定
エラー分析	エラーの発生箇所を特定

7.6 イミュータブルインフラストラクチャ

一度デプロイしたインフラを変更せず、新しいバージョンに置き換える設計思想です。

メリット:

環境の一貫性が保たれる
ロールバックが容易
設定ドリフトの防止

AWS での実現方法:

AMI の新バージョン作成 → Auto Scaling グループの更新
コンテナイメージの新バージョン → ECS/EKS でデプロイ
AWS CloudFormation / Terraform でインフラを管理

7.7 Service Quotas とスロットリング

AWS サービスには、アカウントやリージョンごとに制限（クォータ）があります。

主要なサービスクォータの例:

サービス	クォータ	デフォルト値
EC2	オンデマンドインスタンス（vCPU）	リージョンごとに異なる
Lambda	同時実行数	1,000
API Gateway	リクエストレート	10,000/秒
RDS	DB インスタンス数	40

スロットリング対策:

Service Quotas コンソールで引き上げリクエスト
指数バックオフによるリトライ
SQS でリクエストをバッファリング

試験でのポイント:

DR 環境でも本番と同じクォータが必要
Lambda の同時実行制限に注意（突然のスパイクで制限される可能性）

第8章: データの耐久性と可用性

この章で学ぶこと

S3 のストレージクラスと耐久性
EBS スナップショットによるバックアップ
AWS Backup による一元管理
クロスリージョンレプリケーション

8.1 Amazon S3 のストレージクラス

S3 は用途に応じた複数のストレージクラスを提供しています。

ストレージクラス	耐久性	可用性	最小保存期間	ユースケース
S3 Standard	99.999999999%	99.99%	なし	頻繁にアクセス
S3 Intelligent-Tiering	99.999999999%	99.9%	なし	アクセスパターン不明
S3 Standard-IA	99.999999999%	99.9%	30 日	低頻度アクセス
S3 One Zone-IA	99.999999999%	99.5%	30 日	再作成可能なデータ
S3 Glacier Instant	99.999999999%	99.9%	90 日	即時アクセスのアーカイブ
S3 Glacier Flexible	99.999999999%	99.99%	90 日	数分〜数時間で取得
S3 Glacier Deep Archive	99.999999999%	99.99%	180 日	年 1〜2 回のアクセス

S3 レプリケーション

レプリケーションのタイプ:

タイプ	説明
SRR（同一リージョン）	同じリージョン内の別バケット
CRR（クロスリージョン）	異なるリージョンのバケット

8.2 EBS スナップショット

EBS ボリュームのポイントインタイムバックアップです。

特徴:

増分バックアップ（変更部分のみ）
S3 に保存（自動で複数 AZ に分散）
別リージョンにコピー可能
ボリューム使用中でも取得可能

8.3 AWS Backup

複数の AWS サービスのバックアップを一元管理します。

主要機能:

機能	説明
バックアッププラン	スケジュールと保持期間の定義
バックアップボールト	バックアップの保存先（暗号化）
クロスリージョン	別リージョンへのコピー
クロスアカウント	別アカウントへのコピー

8.4 マルチリージョンでの可用性設計

8.5 AWS AI/ML サービス（高可用性と弾力性の観点）

試験では、特定のユースケースに対する AI/ML サービスの選択が問われることがあります。

AI/ML サービスの概要

サービス	用途	特徴
Amazon Comprehend	自然言語処理（NLP）	感情分析、エンティティ認識、言語検出
Amazon Polly	テキスト読み上げ（TTS）	多言語対応、リアルタイム変換
Amazon Transcribe	音声をテキストに変換	文字起こし、リアルタイム対応
Amazon Translate	機械翻訳	多言語対応、リアルタイム変換
Amazon Rekognition	画像・動画分析	顔認識、物体検出、コンテンツモデレーション
Amazon Textract	ドキュメントからテキスト抽出	フォーム、テーブルの解析
Amazon SageMaker	ML モデルの構築・トレーニング・デプロイ	フルマネージド ML プラットフォーム

弾力性の観点

これらの AI/ML サービスは フルマネージド であり、以下の特徴があります：

自動スケーリング: 負荷に応じて自動的にスケール
高可用性: マルチ AZ で冗長化されている
サーバーレス: インフラ管理不要

ユースケース例:

コールセンターの音声分析 → Amazon Transcribe + Amazon Comprehend
ドキュメント処理の自動化 → Amazon Textract
多言語対応アプリケーション → Amazon Translate

第9章: 試験対策とサンプル問題解説

9.1 よく出るシナリオと解法パターン

パターン 1: スケールイン時のリクエスト保護

シナリオ: スケールインイベント中にユーザーリクエストがエラーになる

解法: 登録解除遅延（Deregistration Delay）を増やす

処理時間が最長 15 分なら、登録解除遅延を 900 秒（15 分）以上に設定

不正解の選択肢:

スティッキーセッション → スケールインには対応できない
インスタンスサイズ増加 → 問題の解決にならない
クールダウン期間 → スケーリングの頻度制御であり、リクエスト保護ではない

パターン 2: DR 戦略の選択

シナリオ: RTO 5 分、最小限のコストで DR を実現したい

解法: ウォームスタンバイ

最小限のインスタンスが稼働
数分でスケールアップ可能

比較:

戦略	RTO	適否
バックアップと復元	数時間	NG
パイロットライト	数十分	NG
ウォームスタンバイ	数分	OK
マルチサイト	ゼロ近い	コスト過剰

パターン 3: 疎結合アーキテクチャの設計

シナリオ: 静的フロントエンド + スケーラブルなバックエンド

解法: S3 + API Gateway + SQS + Auto Scaling

不正解の選択肢:

EC2 でフロントエンド → 単一障害点
SNS でバックエンド連携 → メッセージが保持されない
EC2 直接呼び出し → 密結合

パターン 4: Site-to-Site VPN の構成

シナリオ: オンプレミスと AWS を VPN で接続

必要なコンポーネント:

カスタマーゲートウェイ → オンプレミス側
仮想プライベートゲートウェイ → VPC にアタッチ

不要なコンポーネント:

インターネットゲートウェイ → パブリックインターネット用
NAT ゲートウェイ → アウトバウンド接続用
API Gateway → API 管理用

パターン 5: メッセージの順序保証と重複防止

シナリオ: 待機リストで順序を保持したい

解法: SQS FIFO キュー

厳密な順序保証
正確に 1 回の配信

標準キューとの違い:

項目	標準	FIFO
順序	ベストエフォート	保証
重複	あり得る	なし
スループット	無制限	最大 70,000 TPS

パターン 6: 高可用性データベース

シナリオ: RDS の高可用性を確保

解法: RDS マルチ AZ を有効化

同期レプリケーション
自動フェイルオーバー

注意:

Lambda → デフォルトで高可用性
DynamoDB → デフォルトで高可用性
S3 → デフォルトで高耐久性

9.2 試験のコツ

キーワードに注目
- 「疎結合」→ SQS、SNS、EventBridge
- 「スケーラブル」→ Auto Scaling、Lambda
- 「高可用性」→ マルチ AZ、複数リージョン
- 「災害対策」→ DR 戦略（RTO/RPO で判断）
要件の優先順位を確認
- コスト重視か、性能重視か
- 最も○○なソリューション
消去法を活用
- 明らかに不正解な選択肢を除外
- 残りから最適解を選択
AWS のベストプラクティスを意識
- マネージドサービスの活用
- マルチ AZ 配置
- 最小権限の原則

まとめ

Domain 2 の重要ポイント

弾力性の基礎
- 疎結合 > 密結合
- 水平スケーリング > 垂直スケーリング
- ステートレス設計がスケーラビリティの鍵
スケーラブルなコンピューティング
- Auto Scaling の終了ポリシー（AZ バランス優先）
- 登録解除遅延でリクエストを保護
- ALB vs NLB の使い分け
疎結合アーキテクチャ
- SQS: 標準 vs FIFO の選択
- デッドレターキューで失敗メッセージを管理
- SNS + SQS でファンアウトパターン
高可用性
- マルチ AZ 配置が基本
- Route 53 フェイルオーバー
- RDS マルチ AZ、Aurora レプリカ
災害対策
- RPO/RTO で戦略を選択
- パイロットライト vs ウォームスタンバイの違い
- Aurora Global Database（RPO 1 秒、RTO 1 分）
ネットワーク接続
- Site-to-Site VPN のコンポーネント
- VPN vs Direct Connect の使い分け

このノートは AWS SAA-C03 試験対策のために作成されました。最新の情報は AWS 公式ドキュメントを参照してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up