はじめに — CLFから2週間で832点
実務未経験の新卒ですが、先日AWS認定SAA (Solutions Architect Associate) に832点で合格しました。4月上旬に取得したCLFのあとはゆったり学習していましたが、OJT期間に入ってからの2週間は集中して詰め込みました。
振り返って一番効いたと感じるのは、個々のサービス知識の暗記量よりも、「この問題は結局、コスト・可用性・運用オーバーヘッド・開発の手間のどれを最優先しているのか」を読み取る力 でした。
SAAの問題はほとんどが「状況設定 → 複数の要件列挙 → 最後に評価軸を絞る決め台詞」という型で作られていて、誤答の選択肢は要件の一部を満たしつつ、どこかの軸で劣るように作られています。単純暗記では消しきれず、要件との照合が必要な作りです。
この記事は、部門内の新卒向けAWS SAA勉強会(第1回)の資料を、この「軸で読む」視点を意識しながらまとめ直したものです。テーマは「高可用性な3層アーキテクチャを作る」。CloudFront・WAF・ALB・EC2 (Auto Scaling)・RDS (Multi-AZ) の組み合わせを、構成図を見ながら解説します。
SAAの学習を始めた方、CLF取得済みでこれからSAAという方を想定しています。
本記事の流れは以下の4つです。
- 構成図で見る全体像
- なぜこの構成が必要なのか
- 登場するサービスのおさらい
- 試験に出やすいポイントと演習問題
1. 構成図で見る全体像
まず、今回作る構成の全体像です。
1件のリクエストの流れを追うと、こうなります。
- ユーザーからのアクセスは、まず CloudFront に届き、キャッシュされて高速に配信される
- 次に WAF が不正なリクエストでないかを検査する
- 問題なければ ALB に転送され、両方のAZにあるEC2にリクエストを振り分ける
- EC2 が RDS に対して読み書きを行う
ポイントは、アプリケーションは RDSエンドポイントという1つのDNS名にだけ接続すればよい という点です。フェイルオーバーが発生すると、AWSがこのエンドポイントの向き先を自動でスタンバイに切り替えてくれます。プライマリRDSの内容は常にスタンバイRDSへ同期レプリケーションされているため、片方のAZで障害が起きても、もう片方のAZだけで処理を継続できます。
なお、パブリックサブネット とは、ルートテーブルにインターネットゲートウェイ(IGW)への経路(0.0.0.0/0)が設定されているサブネットのことです。ALBはここに置くことでインターネットから直接アクセスできるようにし、EC2はその経路を持たない プライベートサブネット に置くことで、外部から直接アクセスされないようにしています。
2. なぜこの構成なのか
サーバーを1台だけで構成していると、以下のような問題が起こります。
-
単一障害点(SPOF: Single Point of Failure)になる
1台が落ちるとサービス全体が止まる -
急なアクセスに追従できない
増強は手動対応が前提になる -
メンテナンスのたびに止まる
作業中はサービスを提供できない
今回の構成は、これらの問題を1つずつ解消するために組まれています。以降で紹介する各サービスの説明は、単なる機能紹介ではなく、実際のSAA試験でどう問われるか という観点とセットで書いていきます。
設計判断で意識している軸
SAAの学習を通じて感じたのは、同じ要件でも「何を優先するか」によって正解が変わるということです。
- コストを最優先するなら、スポットインスタンスやSavings Plansの活用を検討する
- 運用上のオーバーヘッドを減らしたいなら、マネージドサービス(RDSのMulti-AZなど)を積極的に使う
- 開発の手間を減らしたいなら、自前で仕組みを作るのではなく、既存のマネージドサービスの組み合わせで実現できないかをまず検討する
今回の構成も、自前でクラスタを組んで冗長化するのではなく、CloudFront・ALB・Auto Scaling・RDS Multi-AZという、AWSが用意しているマネージドな仕組みを組み合わせることで、運用の手間を抑えながら高可用性を実現しています。
3. 登場するサービスのおさらい
構成図に出てきた6つのサービスを、リクエストが通る順番におさらいします。基本的な説明は簡潔にし、今回の構成での役割と試験で問われやすいポイントに絞ります。
Amazon CloudFront — 世界中からのアクセスを高速化する
世界中のエッジロケーションでコンテンツをキャッシュするCDNです。
- ユーザーに近いエッジ拠点からコンテンツを配信し高速化する
- オリジン(ALB)への直接アクセスを減らし、負荷を肩代わりする
- WAFやDDoS対策と組み合わせて使う「入り口」になる
試験ポイント: S3を配信元にする場合、S3への直接アクセスは禁止し、OAC (オリジンアクセスコントロール) を設定して、CloudFront経由のアクセスだけを許可するのが定番の正解パターンです。以前は OAI (オリジンアクセスアイデンティティ) が使われていましたが、OACがその後継として推奨されています。
AWS WAF — 不正なリクエストを入り口で止める
SQLインジェクションなどの攻撃パターンを検知・ブロックするWebアプリケーションファイアウォールです。
- CloudFront(またはALB)に関連付けて、リクエストを検査する
- SQLインジェクションやXSSなど既知の攻撃パターンをブロックする
- 地域制限やレート制限などのルールも設定できる
試験ポイント: WAFは代表的に ALB・CloudFront・API Gateway に関連付けられます。NLBには直接付けられない ので、HTTPアプリでWAFが必要なら、NLBをALBに置き換えるのが定番の正解パターンです。
個人的な振り返り: ここは学習中に一番「あ、そういうことか」と繋がった論点でした。「WAFはNLBに直接付けられない」という制約を単体で覚えているだけでは応用が利かず、「HTTPを扱うなら素直にALBに寄せる」という設計判断まで踏み込んで初めて、表現を変えた問題にも対応できるようになった感覚があります。
Application Load Balancer (ALB) — 通信を振り分ける
複数のEC2インスタンスにリクエストを自動で分配します。
- 1台に負荷が集中しないよう、複数インスタンスに振り分ける
- HTTPレベルのヘルスチェックができる(NLBはL4止まり)
- 複数のアベイラビリティーゾーンにまたがって動作する
試験ポイント: ALBはHTTPの中身まで見るヘルスチェックができますが、NLBはL4(宛先IP/ポート)止まりでHTTPエラーを検知できません。ちなみに、ALBが異常を検知しても、Auto Scaling側で 「ELBヘルスチェック」を有効にしないと、そのインスタンスは自動的には置き換わりません。この2つはセットで問われがちです。
Amazon EC2 — コンピューティングの土台
仮想サーバーを必要なときに必要なだけ起動できるサービスです。
- アプリケーションを動かす仮想マシン(インスタンス)
- インスタンスタイプを選んでCPU/メモリを柔軟に変更可能
- 用途に応じて購入オプション(オンデマンド/リザーブド/スポット)を使い分ける
試験ポイント: 購入オプションの使い分けが頻出です。常時稼働で予測できる負荷には リザーブドインスタンス や Savings Plans、中断されても再試行できるバッチ処理には スポットインスタンス が定番の正解です。今回の常時稼働するWebサーバーは前者の考え方に近くなります。
個人的な振り返り: ここは最初「暗記もの」だと思っていましたが、「どのくらいの期間、どのくらいの確度で使い続けるか」という軸で捉え直したら急に腹落ちしました。常時稼働ならリザーブド/Savings Plans、中断可なバッチならスポット、という判断軸は今回の設計判断(前述の「コスト・運用オーバーヘッド・開発の手間」)にもそのまま繋がっています。
Amazon EC2 Auto Scaling — 台数を自動で増減する
負荷に応じてEC2の台数を自動で増減させます。
- 最小・最大・希望のインスタンス数をルールとして設定する
- CPU使用率だけでなく、SQSの滞留メッセージ数なども指標にできる
- 落ちたインスタンスを自動的に置き換える
試験ポイント: スケーリング指標の選び方が頻出です。CPU使用率ベースが基本ですが、キュー処理のようなワークロードでは SQSキューに滞留しているメッセージ数 を指標にするのが正解パターンです。ネットワーク使用率やメッセージ発行数を指標にするのは、誤りの選択肢としてよく登場します。
Amazon RDS (Multi-AZ) — データベースを止めない
プライマリとスタンバイを別のAZに配置し、自動フェイルオーバーする構成です。
- プライマリDBの内容をスタンバイDBへ同期レプリケーション
- 障害発生時は自動でスタンバイに切り替わる(フェイルオーバー)
- バックアップもスタンバイ側で取得でき、性能への影響が少ない
試験ポイント: 複雑な結合やトランザクションが必要ならRDS、超低レイテンシで大量のシンプルなキーバリューアクセスが必要ならDynamoDB、という使い分けが問われます。要件に「リレーショナル」と明記されていれば、DynamoDBは選択肢から外れます。
Multi-AZ と リードレプリカ、目的が全く違う
RDSには、名前は似ていても目的が全く違う2つの機能があります。試験で 繰り返し問われる頻出の対比 なので、表で整理します。
| Multi-AZ | リードレプリカ | |
|---|---|---|
| レプリケーション方式 | 同期 | 非同期 |
| 目的 | 高可用性(自動フェイルオーバー) | 読み取り性能のスケーリング |
| 読み取り利用 | スタンバイは通常読み取りに使えない | レポート処理などの読み取り負荷を分離できる |
| 可用性向上 | ○(本番環境で推奨される構成) | ×(可用性を高める目的では使えない) |
実務ではこの2つを併用することも多いですが、「Multi-AZ = 高可用性」「リードレプリカ = 読み取り性能」 という対比を混同しないことが重要です。
個人的な振り返り: ここは学習中に時間をかけて「言語化」した論点です。最初は表をそのまま暗記しているだけでしたが、「目的が違うのだから、片方がもう片方の代わりにはならない」というところまで理解して初めて、応用問題(演習①のRDS Proxyのような組み合わせ問題)にも対応できるようになりました。
4. 試験に出やすいポイントまとめ
ここまでの内容を試験対策として整理します。以下は、手元の問題集の頻出論点を分析した結果に基づくポイントです。
ロードバランサ・DB編
- ALBはHTTPレベルのヘルスチェックができる(NLBはL4止まり)。Auto ScalingのELBヘルスチェックを有効にしないと異常時に自動置換されない
- Multi-AZとリードレプリカは目的が違う(頻出の対比)。Multi-AZ = 高可用性 / リードレプリカ = 読み取り性能
- 自動バックアップ・スナップショットはプライマリへの性能影響が小さい。Multi-AZならスタンバイ側から取得される
スケーリング・配信・防御編
- Auto Scalingは指標選びが重要。CPU使用率が基本、キュー処理はSQSの滞留数を使うのが定番
- WAFは主にALB・CloudFront・API Gatewayに関連付ける。HTTPワークロードならNLBをALBに置き換えるのが定番
- CloudFrontは署名付きURL/Cookieで配信を制限できる。特定ユーザーだけにコンテンツを公開する仕組み
逆に、NLBが本当に必要な場合(TCPの生トラフィックを扱う場合など)は、WAFという選択肢自体が出てこず、セキュリティグループでIPを制限する という対処が正解になるパターンが多い点も覚えておくとよいです。
5. 演習問題
理解度確認として、5問の演習問題を用意しました。
以下はいずれも理解度確認用に作成したオリジナル問題です(AWS公式試験や特定の問題集からの引用ではありません)。
答えは <details> で畳んであるので、まず自分で考えてみてください。
演習問題① フェイルオーバー時の接続断
ある動画配信サービスは、視聴ログをMulti-AZ構成のAmazon RDSに書き込んでいます。深夜のメンテナンスウィンドウ中にフェイルオーバーが発生した際、バックエンドで一時的にDB接続エラーが多発し、ログ登録が数十秒間詰まってしまいました。この接続断をさらに短くするには、どうするのが効果的でしょうか?
A. リードレプリカを新たに作成し、書き込み処理の一部をそちらに逃がす
B. RDSのストレージタイプをgp3からio2に変更し、IOPSを引き上げる
C. Amazon RDS Proxyを導入し、アプリケーションからの接続をプールする
D. Multi-AZ配置をやめてSingle-AZ構成に変更し、コストを削減する
解答・解説
正解: C
Multi-AZ構成でも、フェイルオーバーの際にはDB接続の切り替えで数十秒程度のタイムアウトが発生することがあります。これは異常ではなく、Multi-AZの仕組み上ある程度避けられないものです。この接続断をさらに短くしたい場合は、RDS Proxy をかませるのが定番の対処です。RDS Proxyが接続をプールしておいてくれるので、フェイルオーバー時の接続切り替えが速くなり、アプリ側のタイムアウトを減らせます。
- A: リードレプリカは読み取り性能のスケーリング用で、書き込み処理やフェイルオーバー時間の短縮には関係ない
- B: IOPS不足が原因なら効果があるが、今回はフェイルオーバー時の接続切り替えが原因なので的外れ
- D: Single-AZ化はむしろ可用性が下がり、要件と逆行する
「接続断をさらに詰めるなら、まずRDS Proxyでプール」 が定番パターンです。
演習問題② WAFとロードバランサの組み合わせ
決済APIを提供するBtoBサービスで、当初はNetwork Load Balancer(NLB)経由でHTTPSトラフィックを受ける予定でした。ここにAWS WAFを使ってSQLインジェクション対策を入れたい場合、どう実装するのが適切でしょうか?
A. 予定どおりNLBを使い、WAFのIPセットをNLBのリスナーに直接アタッチする
B. NLBの代わりにApplication Load Balancer(ALB)を使用し、ALBにWAFのWeb ACLを関連付ける
C. NLBの前段にAmazon API Gatewayを配置し、API GatewayでWAFを有効にしてNLBはそのまま使う
D. NLBを2系統に増やし、それぞれにセキュリティグループでIP制限をかける
解答・解説
正解: B
AWS WAFは主にALB・CloudFront・API Gatewayに関連付けるサービスで、NLBには直接アタッチできません。対象がHTTPSベースのAPIであれば、NLBの前に何かを追加するのではなく、NLB自体をALBに置き換えてしまう のが実務でも試験でも定番の正解です。
- A: そもそも実装できない
- C: API Gatewayを前段に追加すること自体は技術的に可能だが、VPC Linkの追加設定など構成が複雑になり、最小限の変更でHTTPS+WAFを実現したい今回の要件には合わない
- D: 構成が複雑になるだけで、そもそもWAFによる保護が実現できていない
なお、NLBが本当に必要なケース(非HTTPのTCPトラフィックを扱う場合など)は、そもそもWAFという選択肢は出てこず、セキュリティグループでIPアドレスを制限するのが正解になります。
「HTTP(S)にWAFを効かせたいなら、素直にALBへ寄せる」 が定番パターンです。
演習問題③ S3への直接アクセス制限
社内向けの資料共有ポータルで、Amazon S3に格納したPDFファイルをCloudFront経由でのみ配信したいと考えています。S3の直接URLからのアクセスはブロックしたい場合、現在AWSが推奨する実装方法はどれでしょうか?
A. アプリケーション側でRefererヘッダーをチェックし、CloudFront経由のリクエストだけを通す
B. IAMロールを作成してCloudFrontに割り当て、そのロールにS3の読み取り権限を付与する
C. CloudFrontにOAC(オリジンアクセスコントロール)を設定し、S3バケットポリシーでOACからのアクセスのみを許可する
D. S3バケットをパブリック公開にした上で、CloudFrontのキャッシュ動作でアクセス経路を制御する
解答・解説
正解: C
OAC(オリジンアクセスコントロール) をCloudFrontディストリビューションに割り当て、S3バケット側はそのOACからのアクセスだけを許可するように設定します。これがS3を直接公開せずCloudFront経由だけにする、現在推奨されている定番の方法です。以前はOAI(オリジンアクセスアイデンティティ)が使われていましたが、OACがその後継として推奨されています。
- A: Refererヘッダーはリクエスト側で自由に偽装できるため、アクセス制御としては機能しない
- B: CloudFrontにIAMロールを割り当てる、という仕組み自体が存在せず実装できない
- D: パブリック公開してしまっており、直接アクセスを防ぐという要件を満たせない
「S3を直接見せたくないなら、CloudFront×OACが今の定石」 です。
演習問題④ コスト効率の良い購入オプション
ある研究チームは、週末(土曜の深夜1時〜4時)だけ実行される大規模シミュレーションジョブを持っています。ジョブが途中で中断されても、別のノードが最初からやり直せる設計になっています。このワークロードに最もコスト効率が良いEC2の購入オプションはどれでしょうか?
A. 3年契約(All Upfront)のリザーブドインスタンス
B. Compute Savings Plans
C. スポットインスタンス
D. Dedicated Host
解答・解説
正解: C
このワークロードは中断されても他のノードがやり直してくれるため、スポットインスタンスの「中断されることがある」というデメリットを許容できます。しかも週1回・3時間しか稼働しないため、契約期間ずっと課金されるリザーブドインスタンスやSavings Plansは、常時稼働しない用途には向きません。Dedicated Hostは物理ホスト専有のためライセンス要件がある場合向けの選択肢で、コスト効率の観点では今回の要件に合いません。
「中断可・短時間・不定期」が揃ったら、まずスポットインスタンスを検討する という定番パターンです。
演習問題⑤ Auto Scalingのスケーリング指標
画像変換ジョブをSQSキュー経由で受け取り処理する、ステートレスなワーカー群があります。溜まったジョブの量に応じてワーカーのEC2台数を増減させたい場合、Auto Scalingのスケーリング指標として最も適切なのはどれでしょうか?
A. ワーカーインスタンスのメモリ使用率
B. ワーカーインスタンスのディスクI/O
C. SQSキューの近似メッセージ数(ApproximateNumberOfMessagesVisible)
D. SNSトピックへのパブリッシュ数
解答・解説
正解: C
キュー処理型のワークロードでは、処理すべきジョブがどれだけ溜まっているかが、本当にスケールさせるべきタイミングを最も正確に表します。メモリ使用率やディスクI/Oは画像変換処理の負荷傾向に左右され、ジョブの滞留状況を必ずしも正確に反映しないため、スケールが遅れたり過剰になったりすることがあります。またSNSはメッセージを保持しない配信専用のサービスなので、「パブリッシュ数」を見てもキューの滞留状況(処理の遅れ具合)は分かりません。
「キュー処理系のAuto Scaling = キューの滞留数を指標にする」 は、類題でも繰り返し登場するパターンです。
まとめ — SAAの問題を「型」で読む
最後に、アーキテクチャの話ではなく試験対策の話として、今回一番伝えたかったことを整理します。
- SAAの問題はほぼ全問が「状況設定 → 複数の要件列挙(可用性・コスト・運用負荷など) → 最後に評価軸を絞る決め台詞」という型で作られている
- 誤答の選択肢は、要件の一部は満たしつつ、決め台詞が指定する軸のどこかで劣るように作られていることが多い。単純暗記では消しきれず、要件との照合が必要
- 今回扱った「Multi-AZ vs リードレプリカ」「WAFのアタッチ対象」「EC2購入オプション」も、突き詰めれば「どの評価軸で選ぶか」という同じ型に沿った論点
- この型を意識するようになってから、初見の組み合わせ問題にも一段抽象化して対応できるようになった、というのが今回の学習で得た一番の武器です