なぜSAA-C03で「言い換え」を潰すと強くなるのか
SAA-C03の設問を解いていて、こんな経験はありませんか。
- 文章は読めているのに、選択肢が全部それっぽく見える
- 日本語に直した瞬間、意味がズレて判断が揺れる
- “この単語、どこかで見た”のに、設計としての意図がつながらない
この手のミスは、英語が苦手だからというより 「同じ意味の言い方が複数ある」 ことが原因になりやすいです。SAA-C03は、AWSのサービス暗記だけではなく、AWS Well-Architected Frameworkに沿った設計判断を問う試験として説明されています。
つまり、設問の英語表現が多少変わっても「設計として何を要求しているか」を読み取れる状態が強い、ということです。
この記事では、覚え方ではなく 判断を安定させるための“言い換え辞典” を作ります。
断定はしませんが、理解が浅いと混乱しやすい言葉を中心に、和訳の罠もセットで整理します。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
設計の軸になる言葉：可用性・耐久性・スケール系の言い換え整理
可用性と耐久性は「守る対象」が違う
まずここがズレると、S3・EBS・RDSあたりの判断が全部ブレます。
- Availability（可用性）：サービスが利用できる状態の度合い
- Durability（耐久性）：データが失われにくい度合い
たとえばS3は、耐久性と可用性を分けて説明しています。S3 Standard は 耐久性 99.999999999%（11 nines） と 可用性 99.99% を目標に設計されている、という書き方です。
ここで「可用性が高い＝データが消えない」と一体化して覚えると、設問で転びます。
よくある言い換え（可用性・耐久性）
| 設問に出がちな表現 | だいたい同じ方向の意味 | 和訳の罠・見落としポイント |
|---|---|---|
| highly available / high availability | 可用性が高い | “壊れない”ではなく“止まりにくい” |
| durable / eleven nines | 耐久性が高い | “稼働”ではなく“データ保持”寄り |
| data loss | データ喪失 | 可用性低下とは別問題 |
| service disruption / outage | サービス停止 | データ消失とは別の軸 |
フォールトトレラントとレジリエントは似ているが同じではない
言い方が増えたせいで、設問の雰囲気だけで選びがちです。
- fault tolerant：一部が壊れても動き続ける性質
- resilient：障害を前提に、復旧も含めて持ちこたえる性質（設計全体の強さ）
SAA-C03は “Design Resilient Architectures” が試験範囲に含まれる、と試験ガイドで整理されています。
だからこそ、設問で “resilient” と書かれていたら「Multi-AZ」「自動復旧」「単一障害点の排除」など、設計パターンを連想できると安定します。
スケーラビリティとエラスティシティは「増える理由」が違う
ここも和訳で混ざりやすい代表格です。
- scalability（拡張性）：成長に合わせて拡張できる（設計として伸びる）
- elasticity（伸縮性）：負荷に合わせて自動で増減する（運用として伸び縮みする）
設問では次のように言い換えられます。
| 設問の表現 | 方向性 | 連想する設計要素 |
|---|---|---|
| handle traffic spikes | 急な増加に耐える | Auto Scaling、キャッシュ、疎結合 |
| accommodate growth | 継続的な成長 | 水平分割、シャーディング、スケールアウト |
| right-size / avoid over-provisioning | 過剰準備を避ける | オートスケール、サーバレス |
Well-Architectedの“柱”は、設問の別名として出てくる
Well-Architected Framework は6つの柱として説明されます。
設問では「柱の名前」がそのまま出ない代わりに、別の言い回しで要求が書かれることがあります。
| 柱に近い要求 | 設問での言い換え例 |
|---|---|
| Security | least privilege / encrypt / audit / prevent public access |
| Reliability | eliminate single point of failure / multi-AZ / automatic recovery |
| Performance efficiency | low latency / high throughput / optimize performance |
| Cost optimization | minimize cost / pay only for what you use / avoid idle resources |
セキュリティと運用：IAM・暗号化・監査ログの言い換え整理
IAMは “allow/deny” だけでなく “評価順序” が言い換えで揺さぶられる
IAMの設問で多い混乱は、「許可される条件」を読み違えることです。AWS公式ドキュメントでは、デフォルトは拒否（implicit deny）、そして explicit deny は allow より優先 といった評価ロジックが説明されています。
IAMまわりの言い換え辞典
| 設問の表現 | だいたいの意味 | つまずきポイント |
|---|---|---|
| least privilege | 最小権限 | “必要最小限に絞る”が主語。便利さ優先ではない |
| implicit deny / default deny | 何も許可されていない状態 | “拒否が書かれていない＝許可”ではない |
| explicit deny | 明示的な拒否 | allowがあってもdenyが勝つ |
| resource-based policy | リソース側のポリシー | S3/KMS/SNSなど、主体が変わると見落とす |
暗号化は “at rest / in transit / envelope” の3点セットで来る
暗号化の設問は、言い換えが多いです。
- encryption at rest：保存時の暗号化
- encryption in transit：通信時の暗号化（TLSなど）
- envelope encryption：データ鍵とマスター鍵を分ける方式（KMSでよく見る）
AWS KMSのドキュメントでは envelope encryption の基本構造を説明しています。
「KMS＝暗号化してくれるサービス」とだけ覚えると、設問の要求（どこで暗号化するか、誰が鍵を管理するか）が読み取れません。
| 設問の表現 | 意味 | ありがちな誤解 |
|---|---|---|
| customer managed key | 顧客管理のKMSキー | “AWSが管理してくれるから同じ”ではない |
| rotate keys / key rotation | 鍵のローテーション | データの再暗号化と混同しがち |
| encrypt data in transit | 通信経路を暗号化 | 保存時暗号化で満足してしまう |
監査とモニタリングは “CloudTrail と CloudWatch” の役割がズレやすい
AWSの公式ガイドでは、CloudTrailはユーザーやAPIのアクティビティ監査、CloudWatchは性能や運用状態の監視という整理です。
さらにCloudTrailのイベント履歴は過去90日分の管理イベントが見られる、と明記されています。
| 設問の表現 | 近いサービス | 迷うポイント |
|---|---|---|
| audit / track API activity | CloudTrail | “ログ＝CloudWatch”で固定しない |
| operational health / metrics | CloudWatch | 監査証跡とは別軸 |
| immutable record | CloudTrail event history | “消せないログが必要”系の文脈 |
サービス別：ネットワーク・ストレージ・データベース・疎結合の言い換え整理
ネットワークは “stateful / stateless” の言い換えで崩れる
VPCのセキュリティは、用語の言い換えでひっかけやすいところです。AWS公式ドキュメントでは、
- Security Group は stateful
- Network ACL は stateless
と説明されています。
| 設問の表現 | 近い概念 | 見落としポイント |
|---|---|---|
| return traffic is automatically allowed | stateful | “戻り通信の許可を書かなくていい” |
| must allow inbound and outbound explicitly | stateless | インバウンド許可してもアウトバウンドが必要 |
| subnet-level control | NACL | SGと適用範囲が違う |
ストレージは “durable / ephemeral / persistent” が入れ替わる
EC2のストレージは言い換えが多いです。EBSは インスタンスのライフサイクルと独立して永続化（persist） し、スナップショットを作れる、と公式ドキュメントにあります。
一方、Instance Store はインスタンスに紐づく一時的なブロックストレージとして整理されています。
| 設問の表現 | 近いサービス | 和訳の罠 |
|---|---|---|
| persistent / survives instance stop | EBS | “EC2のディスク”と雑にまとめない |
| ephemeral / temporary | Instance Store | “速いから安全”ではない |
| backup / snapshot | EBS snapshot | バックアップの粒度と復旧方法まで意識 |
そしてS3は “耐久性が高いオブジェクトストレージ” として、耐久性と可用性が明確に別軸で書かれます。
データベースは “consistency” の言い換えが勝負どころ
DynamoDBの読み取り整合性は、公式ドキュメントで eventually consistent（結果整合性） と strongly consistent（強い整合性） の違いを説明しています。
| 設問の表現 | 意味 | 迷うポイント |
|---|---|---|
| might not reflect a recent write | eventual consistency | “すぐ反映されるはず”という思い込みを捨てる |
| most up-to-date data | strong consistency | GSIでは強整合が使えない文脈がある |
| half the cost | eventual consistency | コスト言及がヒントになる場合がある |
ここは暗記で殴るより、「何を優先している設計か」を読み取る方が強いです。
低レイテンシが最優先なのか、最新性が必要なのか、コストが厳しいのか。文章の要求を“設計の言葉”に戻す感覚が大事です。
負荷分散は “health check / healthy targets” の言い換えに注意
ELB系の設問は「分散する」だけではなく、「死んだ先に流さない」がセットです。ALBのターゲットグループのヘルスチェックは、AWS公式ドキュメントに挙動が整理されています。
| 設問の表現 | 近い要素 | 迷うポイント |
|---|---|---|
| route only to healthy targets | ヘルスチェック | Auto Scalingだけでは足りない |
| deregistration delay | ターゲットの切り離し | 切り替えの“揺れ”の話に見える |
解き方と学び方：辞典の作り方、復習手順、教材の使い分け
解くときのミニ手順
設問で言い換えに遭遇したら、次の順で頭を整理するとブレが減ります。
- 要求は「可用性」「耐久性」「セキュリティ」「コスト」のどれが主語か
- “守りたいもの”は、サービス稼働か、データか、権限か
- その要求を満たす代表パターンを1つだけ思い出す（複数は後で比較）
この順にすると、英語の単語が多少変わっても、設計の要求に戻れます。
自分専用の“言い換え辞典”を作るコツ
この記事の表を、丸ごと暗記する必要はありません。おすすめは「自分が揺れた単語だけ」を増やすやり方です。
- 模試や演習で迷った選択肢のキーワードをメモ
- それを 英語のまま 辞典に追加（日本語だけにしない）
- 1行で「設計判断に直す」と強い（例：handle spikes → 自動で増減させたい）
“言葉→設計判断” に変換できるようになると、得点が安定していきます。
体系化の例としてUdemy講座を使う
独学だと、言い換え表現を拾っても「どの章の話か」が散らばって復習が面倒になります。
その点、UdemyのSAA-C03対策講座（講義＋ハンズオン＋小テストなど）を 体系的に学べる教材の一例 として使うと、言い換え辞典が章ごとに整理しやすくなります。
- VPC章で：stateful/stateless、route、ingress/egress をまとめる
- ストレージ章で：durability/availability、ephemeral/persistent をまとめる
- セキュリティ章で：least privilege、explicit/implicit deny、encryption をまとめる
“講座に頼り切る” ではなく、辞典を作るための骨組みとして使うイメージが合います。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
SAA-C03は、単語の丸暗記よりも「設計として何を要求しているか」を読み取れるかで安定感が変わります。試験ガイドでもWell-Architectedに基づく設計力を検証すると説明されています。
この記事で整理したポイントはシンプルです。
- 可用性と耐久性は、似ているけど守る対象が違う（S3の説明が分かりやすい）
- IAMはデフォルト拒否とexplicit deny優先を、言い換えで見失わない
- VPCはstateful/statelessの言い換えで崩れやすい
- DynamoDBはconsistencyの言い換えで要求が変わる
最後に。言い換え辞典は、完成品を暗記するものではなく、あなたが迷った単語のログ です。
模試や演習で揺れた表現を1つずつ足していけば、英語表現が変わっても設計判断に戻れるようになります。結果として、焦りが減って、選択肢の比較が速くなります。
