第 0 章 前提
AWS の地図
この章に出てくる用語
- リージョン
- 地理的に離れた独立した領域。 東京、大阪、バージニア北部といった単位で、それぞれが独立して動く。リージョンをまたぐと通信は有料になり、遅延も大きくなる。多くのサービスはリージョン単位で作るので、作る前にどのリージョンかを決めることになる。
- アベイラビリティーゾーン（AZ）
- 1 つのリージョンの中にある、電源・空調・ネットワークが独立した設備群。 ほとんどのリージョンは 3 つ以上の AZ を持つ。AZ 同士は高帯域・低遅延の専用線でつながっており、通信はすべて暗号化される。片方の AZ が落ちてももう片方は動くので、「可用性を上げる」の第一歩は複数の AZ に置くことになる。
- マネージドサービス
- 運用の一部を AWS が代わりにやってくれるサービス。 RDS、Lambda、DynamoDB などが該当する。OS の管理やパッチ適用、バックアップの仕組みを AWS 側が持つので、利用者は設定と使い方だけを考えればよい。そのぶん細かい制御はできなくなる（OS にログインできない、など）。試験では「運用の手間を減らしたい」と書かれていたらマネージド寄りが答えになる。
- VPC（Virtual Private Cloud）
- AWS の中に作る、自分専用の隔離されたネットワーク。 作るときに IP アドレスの範囲（CIDR ブロック。10.0.0.0/16 など）を決める。VPC はリージョンの中に作られ、他の利用者のネットワークとは完全に分かれている。
- サブネット
- VPC の中をさらに区切った単位で、1 つの AZ に属する。 VPC は AZ をまたげるが、サブネットはまたげない。だから「複数の AZ に置く」とは、実際には「AZ ごとにサブネットを作って置く」ことになる。
AWS の設備は世界中に散っているが、利用者から見た区切りは 3 段しかない。リージョン、アベイラビリティーゾーン、エッジロケーションだ。どの段で考えるかで、可用性もコストも変わる。
エッジロケーションは、この 2 つとは役割が違う。リージョンよりはるかに多い数が世界中に置かれていて、配信（CloudFront）と DNS（Route 53）のために使う。ここで計算やデータの保管はしない。利用者の近くで応答を返すための場所だ。
試験では
設問で「どこに置くか」を問われたときの反応のしかた。「同じリージョンの別の AZ」は可用性の話、「別のリージョン」は災害対策の話、「エッジ」は配信と遅延の話。 この 3 つを混ぜた選択肢が並ぶので、要件が可用性なのか災害対策なのか遅延なのかを先に読み分ける。
補足
AZ の名前（ap-northeast-1a など）はアカウントごとに実際の設備との対応が違う。 ある人の 1a と別の人の 1a は同じ設備ではない。AWS が負荷を散らすためにわざとそうしている。アカウント間で同じ設備を指したいときは、名前ではなく AZ ID（apne1-az1 など）を使う。
AWS は責任共有モデルという言い方で、自分の責任範囲と利用者の責任範囲を線引きしている。ひとことで言うと、AWS は「クラウドそのもの」を守り、利用者は「クラウドの中身」を守る。
| AWS がやること | 利用者がやること | |
|---|---|---|
| 設備 | 建物・電源・空調・物理的な入退室 | ― |
| ハードウェア | サーバー・ストレージ・ネットワーク機器 | ― |
| 仮想化の基盤 | ハイパーバイザーとその更新 | ― |
| OS とミドルウェア | マネージドサービスでは AWS | EC2 では利用者（パッチ適用も） |
| ネットワークの設定 | ― | セキュリティグループ・ルートテーブル・ACL |
| 認証と認可 | 仕組みの提供（IAM） | 誰に何を許すかの設計 |
| データ | ― | 中身・分類・暗号化するかどうか |
この表の 4 行目が設問になりやすい。EC2 のゲスト OS にパッチを当てるのは利用者で、RDS のデータベースエンジンにパッチを当てるのは AWS だ。同じ「パッチ」でも、使っているサービスがマネージドかどうかで答えが入れ替わる。
試験では
「最も運用負荷が低い構成はどれか（least operational overhead）」はSAA で最も多い問い方のひとつ。EC2 に自分で入れる案は、動くとしてもこの問い方では落ちる。マネージドサービス、さらにサーバーレスへ寄せた選択肢を疑う。
公式は「この試験は AWS Well-Architected Framework に基づいて設計する能力を問う」と明言している。4 つの分野名がそれぞれセキュア・弾力性・高パフォーマンス・コスト最適化なのは、このフレームワークの柱と対応させているからだ。
| 柱 | 問うこと | 試験の分野 |
|---|---|---|
| 運用上の優秀性 | 運用して改善し続けられるか | 直接の分野は無い（設問には混ざる） |
| セキュリティ | 守れているか | 第 1 分野（30%） |
| 信頼性 | 壊れても続くか・回復できるか | 第 2 分野（26%） |
| パフォーマンス効率 | 要件に合う速さを出せているか | 第 3 分野（24%） |
| コスト最適化 | 払いすぎていないか | 第 4 分野（20%） |
| 持続可能性 | 資源の使い方が無駄でないか | 直接の分野は無い |
6 本のうち 4 本が分野になっている。残る 2 本（運用上の優秀性・持続可能性）に独立した分野は無いが、設問の中には出てくる。6 本のうちどれを立てるかで答えが変わるのがこの試験の性格で、「速いが高い案」と「安いが遅い案」のどちらが正解かは、問題文の要件で決まる。
補足
持続可能性の柱は 2021 年 12 月に追加された 6 本目で、それまでは 5 本だった。古い教材は 5 本と書いてあるが、現行は 6 本。数を問われることは少ないが、柱の名前が選択肢に並ぶことはある。
AWS で何かを触るには、必ず「誰として触るか」が要る。第 1 章で詳しくやるが、ここでは 3 つだけ区別しておく。ルートユーザー、IAM ユーザー、IAM ロールだ。
- ルートユーザー ―― アカウントを作ったときのメールアドレスそのもの。すべてを無制限にでき、権限を削ることもできない。だから普段は使わない。 MFA を付けて金庫にしまい、請求設定などルートでしかできない操作のときだけ出す。
- IAM ユーザー ―― 人やアプリに割り当てる長期的な身分。パスワードやアクセスキーを持つ。
- IAM ロール ―― 身分そのものではなく「一時的に借りる権限の入れ物」。パスワードも固定のキーも持たず、使うときに一時的な資格情報が発行される。EC2 やLambda に権限を渡すときも、別のアカウントの人に作業させるときもこれを使う。
試験では
EC2 の中にアクセスキーを置く構成は、選択肢に出てきたら誤り。正解は「EC2 にロールを付ける（インスタンスプロファイル）」。キーは漏れる・期限が無い・ローテーションが手間、の 3 つで必ず負ける。この型は分野をまたいで何度も出る。
AWS を触る方法は 3 つある。AWS マネジメントコンソール（ブラウザの画面）、AWS CLI（コマンド）、SDK（プログラムから）だ。どれを使っても、裏では同じ API を呼んでいる。試験では操作手順そのものは問われないが、「手でコンソールを触る」案と「コードから作る」案が選択肢に並ぶことはある。繰り返し同じ構成を作るなら後者（第 5 章）が答えになる。
AWS で自分のサーバーを動かす場所が VPC だ。第 2 章と第 9 章で深く扱うので、ここでは「図を読めるようにする」ぶんだけ置く。
サブネットがパブリックかプライベートかは、設定項目ではなく経路で決まる。 インターネットゲートウェイ（IGW）へ向かう経路がルートテーブルに書かれていればパブリックサブネット、無ければプライベートサブネットだ。「パブリックにする」というチェックボックスがあるわけではない。
| やりたいこと | 使うもの | 置く場所 |
|---|---|---|
| VPC からインターネットへ出る／入る | インターネットゲートウェイ（IGW） | VPC に 1 つアタッチ |
| プライベートサブネットから外へ出るだけ | NAT ゲートウェイ | パブリックサブネットに置く |
| 外から中へは入れない | （NAT は片方向） | ― |
| AWS のサービスへ VPC の中から直接 | VPC エンドポイント | VPC の中 |
試験では
NAT ゲートウェイはパブリックサブネットに置く。守りたいサーバーはプライベートサブネットにあるので、つい NAT も同じ側に描きたくなるが逆だ。NAT 自身が外へ出られないと、中継できない。
第 4 部で詳しくやるが、課金の向きだけは最初に入れておく。第 1 部〜第 3 部の設問にも「コストを増やさずに」という条件が混ざるからだ。
- AWS に入ってくる通信は無料。 外からアップロードするぶんは取られない。
- 同じ AZ の中のプライベート IP どうしの通信は無料。
- AZ をまたぐと有料。 可用性のために AZ を分けると、そのぶん転送料がかかる。
- リージョンから外（インターネット）へ出るのが最も高い。 設問が「転送コストを下げたい」と言ったら、まず出口を減らす方向を探す。
もうひとつ、止めても取られるものがある。EC2 を停止しても EBS ボリュームは残るので課金は続く。使っていない Elastic IP（アタッチしていないもの）にも課金がある。「止めたのに請求が減らない」という設問はこの型だ。
| 問題数 | 65 問（うち採点されるのは 50 問。15 問は採点対象外で、どれかは分からない） |
| 時間 | 130 分 |
| 形式 | 単一選択（4 択で正解 1 つ）と複数選択（5 択以上で正解 2 つ以上） |
| 合格 | 100〜1000 点のスケールで 720 点以上 |
| 分野ごとの合格ライン | 無い。 全体で合格すればよい（補償型の採点） |
| 無回答 | 不正解として扱われる。空欄で出すより当てずっぽうでも埋める |
問題文は長い。だが読むところは決まっている。要件を表す語に反応するのが最短だ。
| 問題文の語 | 効いてくる方向 |
|---|---|
| 運用負荷を最小限に（least operational overhead） | マネージド／サーバーレス寄り |
| 最もコスト効率が高い（most cost-effective） | 安い側。性能は要件を満たす最低限で足りる |
| 高可用性（highly available） | 複数 AZ。単一障害点を消す |
| 耐障害性（fault tolerant） | 落ちても処理が失われない。キューや再試行 |
| 災害対策（disaster recovery）／RPO・RTO | 複数リージョン。4 つの DR 戦略から選ぶ |
| 最小権限（least privilege） | 広い権限を与える選択肢は落とす |
| リアルタイム／ニアリアルタイム | ストリーミング（Kinesis）。バッチは落ちる |
| 数ミリ秒（single-digit millisecond） | DynamoDB、ElastiCache、DAX |
| コードを変更できない（without changing the application） | アプリ側の改修を含む案は落ちる |
試験では
複数選択（2 つ以上選ぶ）の問題は部分点が無い。全部合っていて初めて得点になる。2 つ選ぶ問題で確信があるのが 1 つだけのときは、残りを「要件に書かれていないことを足していない選択肢」から選ぶ。SAA の誤答はやりすぎ（要件以上の構成）か足りない（要件を満たさない）のどちらかが多い。
補足
本書は公式の試験ガイド（SAA-C03 v1.1）の 14 タスクステートメントを章にしている。付録 A に試験範囲のサービス 130 個を一覧にして、それぞれ本書のどこで扱ったかを書いた。読み終わったあとの抜け確認に使える。
シナリオ演習
ある社内システムを AWS へ移す。要件は「東京リージョンで、1 つのデータセンターの障害でも止まらないこと」。設計として最初に満たすべきことは何か。
補足
答え：複数のアベイラビリティーゾーンに分けて配置する。
「1 つのデータセンターの障害」は AZ 障害の言い換え。別リージョンを持ち出す案は、要件に無いものを足している（やりすぎ）ので落ちる。単一 AZ のまま台数だけ増やす案は要件を満たさない（足りない）。
シナリオ演習
EC2 上のアプリから S3 を読む必要がある。開発者は「アクセスキーを環境変数に置く」という案を出した。レビューでどう指摘するか。
補足
答え：IAM ロール（インスタンスプロファイル）を EC2 に付け、キーは置かない。
長期のアクセスキーは漏れたときに期限が無く、ローテーションの手間もかかる。ロールなら一時的な資格情報が自動で配られ、更新も AWS 側が行う。この型は分野をまたいで繰り返し出る。
この章のまとめ
- リージョンの中にあり、電源とネットワークが独立した設備群
- ほとんどのリージョンが持つ AZ の数
- AZ 名（1a など）がアカウントごとに違うとき、同じ設備を指す方法
- EC2 のゲスト OS のパッチを当てるのは誰か
- RDS のデータベースエンジンのパッチを当てるのは誰か
- Well-Architected Framework の柱の数
この章の根拠
最終確認 2026-10-04 ／ 対応バージョン DEA 2026-05-04 改訂版