変更要約: in-scope サービス網羅: 自動スケーリング(EC2 Auto Scaling)・アプリ統合(MQ/Step Functions/AppSync/AppFlow)・移行/転送(Application Migration Service/DMS/DataSync/Transfer Family/Snow Family)・ハイブリッド接続(Direct Connect/Site-to-Site VPN/Client VPN/Transit Gateway/PrivateLink)を各節に追加
2.1高可用性とスケーリング
複数のアベイラビリティゾーン（マルチ AZ）、Elastic Load Balancing、Auto Scaling を組み合わせて、障害に強く需要に応じて伸縮するアーキテクチャを設計する考え方を理解します。
回復性の高い設計の基本は、単一障害点をなくすことです。複数の アベイラビリティゾーン（AZ） にまたがって配置し、ELB で負荷を分散、Auto Scaling で台数を自動調整します。
2.1.1高可用性の基本パターン
- リージョンと AZ：リージョンは地理的な大区分、その中に物理的に分離された複数の アベイラビリティゾーン（AZ） がある。複数 AZ に分散すれば 1 AZ 障害でも継続。
- Elastic Load Balancing（ELB）：受信トラフィックを健全なターゲットへ分散。ALB（L7・HTTP/S）/NLB（L4・超高速）/GWLB がある。
- Auto Scaling：需要や障害に応じてインスタンス数を自動で増減（スケールアウト/イン）。ヘルスチェックで異常インスタンスを置き換え。
回復性の高い設計の鉄則は「単一障害点（SPOF）をなくす」ことです。定番は ELB ＋ Auto Scaling グループを複数 AZ にまたがって配置するパターン。ELB が健全なインスタンスにだけトラフィックを流し、Auto Scaling が負荷増や障害に応じて台数を自動調整します。混同しやすいのが「スケールアウト/イン（水平：台数を増減）」と「スケールアップ/ダウン（垂直：1 台を大きく/小さく）」で、クラウドでは水平スケールが基本です。また 高可用性（ダウンタイムを最小化） と 耐障害性（障害が起きても機能を維持） は近いが別概念です。データ層では RDS マルチ AZ が同期スタンバイへ自動フェイルオーバー（可用性）し、リードレプリカは読み取りをスケール（性能）します。
| 仕組み | 役割 | 補足 |
|---|---|---|
| マルチ AZ | AZ 障害に耐える | SPOF を排除 |
| ELB | 健全なターゲットへ分散 | ALB(L7)/NLB(L4) |
| Auto Scaling | 台数を自動増減 | 水平スケール |
| RDS マルチ AZ | 自動フェイルオーバー | 可用性（性能ではない） |
| リードレプリカ | 読み取りをスケール | 性能（可用性ではない） |
シナリオ：可用性とスケールの設計。 Web 層は ALB ＋ Auto Scaling グループを 2 つの AZ にまたがって配置し、アクセス急増時は自動でスケールアウト。DB は RDS マルチ AZ で AZ 障害時に自動フェイルオーバー、読み取りが重いならリードレプリカを追加。これで単一の AZ・インスタンス障害でもサービスを継続できます。
混同に注意：
①スケールアウト/イン（水平＝台数）とスケールアップ/ダウン（垂直＝サイズ）。
②RDS マルチ AZ＝可用性（自動フェイルオーバー）／リードレプリカ＝読み取り性能——目的が逆。
③ELB は健全なターゲットのみに流す（ヘルスチェック）。
④高可用性（ダウンタイム最小）と耐障害性（障害下でも機能維持）は別概念。
Q. RDS マルチ AZ とリードレプリカの違いは？ マルチ AZ は可用性（同期スタンバイへ自動フェイルオーバー）、リードレプリカは読み取りスケール（非同期コピー）。Q. スケールアウトとスケールアップは？ アウト＝台数を増やす（水平）、アップ＝1台を大きく（垂直）。Q. ALB と NLB は？ ALB は L7（HTTP/S・パスベースルーティング）、NLB は L4（超低遅延・高スループット）。
「マルチ AZ ＋ ELB ＋ Auto Scaling」が高可用性の定番として頻出です。RDS マルチ AZ＝可用性／リードレプリカ＝読み取り性能、水平（アウト）と垂直（アップ）スケールの区別も押さえましょう。
2.1.2その他の主要 in-scope サービス（自動スケーリング）
水平スケールの中核が Amazon EC2 Auto Scaling です。需要や障害に応じて EC2 の台数を自動で増減させ、目標とする台数（希望/最小/最大）を維持し、不健全なインスタンスを置き換えます。複数 AZ にまたがって配置することで、AZ 障害時にも別 AZ で容量を保てます。負荷の変動が大きいワークロードでコストと可用性の両立が要るときに選び、ELB のヘルスチェックと組み合わせて使います。
2.1.3この節のまとめ
- 単一障害点を排除：複数 AZ ＋ ELB ＋ Auto Scaling（水平スケール）
- RDS マルチ AZ＝自動フェイルオーバー（可用性）／リードレプリカ＝読み取りスケール（性能）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 1 つのアベイラビリティゾーンに障害が起きてもサービスを継続できる設計はどれですか？
Q2. 需要や障害に応じて EC2 の台数を自動で増減する仕組みはどれですか？
Q3. RDS で高可用性を実現し、プライマリ障害時に自動フェイルオーバーする構成はどれですか？