概要
CLF までの学習で、自作の VPC と EC2、RDS、ELB と Auto Scaling、CloudFront、Lambda・API Gateway・SQS、CloudWatch、CloudFormation と、AWS の主要なサービスを一通り触ってきました。次の目標になる AWS Certified Solutions Architect – Associate（SAA-C03）は、これらを「どう組み合わせれば要件を満たすか」を問う試験です。
試験ガイドでは、SAA-C03 は AWS Well-Architected フレームワークに基づいてソリューションを設計する能力 を検証すると説明されており、出題分野は「セキュア」「レジリエント」「高パフォーマンス」「コスト最適化」の 4 つの設計観点に分かれています。サービスを 1 つずつ覚えるより、この 4 つの観点で「どちらの設計を選ぶか」を判断できることが求められます。
この記事では、SAA-C03 の 4 つの出題分野と配点を確認し、観点ごとによく問われる設計の判断（マルチ AZ とリードレプリカ、疎結合、キャッシュ、ストレージクラス、購入オプションなど）を比較表で整理します。最後に AWS Well-Architected Tool で、4 つの観点に対応する質問に 1 問ずつ回答し、自分の構成のリスクを観点別に確認します。
クラウドおさるここまでの旅で、弊猿の雲の上にもずいぶん道具がそろったでござる。今度はそれを「守り・倒れにくさ・速さ・バナナの節約」の 4 つの目で見直す番でござるな。
—
この記事のメリット
- SAA-C03 の 4 つの出題分野・配点・タスクステートメントを、Well-Architected Framework の柱と対応づけて把握できます
- マルチ AZ とリードレプリカ、セキュリティグループとネットワーク ACL など、取り違えやすい設計の選択肢を比較表で区別できるようになります
- 疎結合・キャッシュ・Auto Scaling が、どの観点の課題を解決するものかを説明できるようになります
- S3 のストレージクラスと EC2 の購入オプションを、コスト最適化の観点で選び分けられるようになります
- Well-Architected Tool で、自分の構成を SAA の観点別にセルフチェックする方法がわかります
—
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
SAA-C03 の 4 つの出題分野と Well-Architected の柱
クラウドおさるとひさん、CLF の次は SAA を目指したいでござる。SAA はどんな試験でござるか？
土肥SAA-C03 は、要件に合わせて AWS のサービスを組み合わせて設計できるかを見る試験だよ。試験ガイドには「AWS Well-Architected フレームワークに基づいてソリューションを設計する能力」を検証するって書いてあるんだ。出題は 4 つの分野に分かれていて、配点はこうなっているよ。
| 分野 | 配点 | タスクステートメント |
|---|---|---|
| 1. セキュアなアーキテクチャの設計 | 30% | 1.1 AWS リソースへのセキュアなアクセスを設計する / 1.2 セキュアなワークロードとアプリケーションを設計する / 1.3 適切なデータセキュリティ管理を判断する |
| 2. レジリエントなアーキテクチャの設計 | 26% | 2.1 スケーラブルな疎結合アーキテクチャを設計する / 2.2 高可用性および/または耐障害性のあるアーキテクチャを設計する |
| 3. 高パフォーマンスなアーキテクチャの設計 | 24% | 3.1 ストレージ / 3.2 コンピューティング / 3.3 データベース / 3.4 ネットワーク / 3.5 データ取り込みと変換 の各ソリューションを選択・設計する |
| 4. コストを最適化したアーキテクチャの設計 | 20% | 4.1 ストレージ / 4.2 コンピューティング / 4.3 データベース / 4.4 ネットワーク の各ソリューションをコスト最適化の観点で設計する |
クラウドおさる分野の名前が、どこかで聞いた言葉に似ているでござる……。Well-Architected Framework の柱でござるか？
土肥いいところに気づいたね！ Well-Architected Framework には 6 つの柱があって、SAA の 4 分野はそのうち 4 つとほぼ対応しているんだ。
| SAA-C03 の分野 | 対応する Well-Architected の柱 | 主に問われる判断 |
|---|---|---|
| セキュア | セキュリティ | 誰に何を許可するか、どこからの通信を通すか、データをどう暗号化するか |
| レジリエント | 信頼性 | 1 か所が壊れても止まらないか、負荷の増減に耐えられるか |
| 高パフォーマンス | パフォーマンス効率 | 用途に合ったストレージ・コンピューティング・データベース・ネットワークを選べているか |
| コスト最適化 | コスト最適化 | 同じ要件をより安い選択肢で満たせないか |
土肥「運用上の優秀性」と「持続可能性」は分野の名前としては出てこないけど、たとえば分野 2 のスキルに「インフラストラクチャの整合性を確保するオートメーション戦略を決定する」っていうのがあって、CloudFormation でやったテンプレートからの構築はここにつながってくるよ。
クラウドおさるなるほど！ 猿山の長老会が新しい見張り小屋を建てるときに見る「守り・倒れにくさ・速さ・バナナの出費」の 4 項目と同じでござるな。しかも守りの配点がいちばん大きいのでござる。
土肥そうそう、配点はセキュアが 30% でいちばん多いね。ここからは観点ごとに、よく比べられる選択肢を整理していこう。
観点 1: セキュア ── 誰に、どこから、何を許すか
クラウドおさるセキュアの分野では、どんなことを判断するのでござるか？
土肥タスクは 3 つあって、「誰がアクセスできるか（IAM）」「ネットワークのどこを通すか（VPC）」「データをどう守るか（暗号化）」に分かれているよ。試験ガイドの知識・スキルから抜き出すとこんな感じだね。
| タスク | 押さえる設計の判断 |
|---|---|
| 1.1 リソースへのアクセス | 最小権限の原則、ルートユーザーと IAM ユーザーへの MFA、ロールと STS によるクロスアカウントアクセス |
| 1.2 ワークロードとアプリケーション | セキュリティグループ・ルートテーブル・ネットワーク ACL・NAT ゲートウェイを使った VPC 設計、パブリックサブネットとプライベートサブネットの使い分け |
| 1.3 データセキュリティ | 保管中のデータの暗号化（AWS KMS など）、暗号化キーへのアクセスポリシー |
クラウドおさるVPC の記事でサブネットを作ったでござるが、セキュリティグループとネットワーク ACL はどちらも通信を絞るもので、弊猿にはいまだに見分けがつかぬでござる。
土肥そこはよく比べられるところだね。違いはこの表のとおりだよ。
| 項目 | セキュリティグループ | ネットワーク ACL |
|---|---|---|
| 適用レベル | インスタンスレベル | サブネットレベル |
| ルールの種類 | 許可ルールのみ | 許可ルールと拒否ルール |
| 戻りのトラフィック | 自動で許可される（ステートフル） | 明示的に許可が必要（ステートレス） |
| ルールの評価 | すべてのルールを評価してから判断 | 番号の小さい順に評価し、最初に一致したルールを適用 |
土肥「特定の IP アドレスからの通信だけを拒否したい」なら拒否ルールが書けるネットワーク ACL、「このインスタンスにはこのポートだけ通したい」ならセキュリティグループ、という具合に、要件の言葉から選ぶんだ。
クラウドおさる猿山でいえば、セキュリティグループは小屋ごとの門番で、一度通した客は帰りも顔パスでござる。ネットワーク ACL は村の入口の関所で、行きも帰りも毎回手形を確かめるのでござるな。
土肥うまい！ 関所は「この猿は通さない」という拒否のリストも持てる、っていうところまで覚えておくとばっちりだね。
観点 2: レジリエント ── 疎結合とマルチ AZ
クラウドおさるレジリエントは「倒れにくさ」でござったな。具体的には何を考えるのでござるか？
土肥タスク 2.1 の「疎結合」と、タスク 2.2 の「高可用性・耐障害性」の 2 本立てだよ。まずは疎結合から。Web サーバーが受けた注文を、そのまま後ろの処理サーバーに直接渡していたらどうなると思う？
クラウドおさる処理サーバーが止まったら、Web サーバーも注文を受けられなくなるでござる……。
土肥そうなんだ。そこで間に Amazon SQS のキューを挟むと、Web サーバーはキューにメッセージを置くだけで済むし、処理側は自分のペースで取り出せる。SQS は「分散されたソフトウェアシステムとコンポーネントを統合・分離する」ためのキューを提供するサービスなんだ。Lambda や API Gateway と組み合わせたイベント駆動の構成も、試験ガイドの知識にそのまま挙がっているよ。
クラウドおさるバナナ倉庫に受付の箱を置いて、運び手の猿が休んでいても注文の紙は箱にたまっていく、というしくみでござるな！
土肥そのとおり！ 次は高可用性。基本は「単一障害点をなくす」ことで、ここまで作ってきたものだとこう対応するよ。
| 仕組み | 何を守るか |
|---|---|
| ELB + Auto Scaling（複数 AZ） | Auto Scaling は異常なインスタンスを置き換えて希望するキャパシティを維持し、複数の AZ にインスタンスを均等に分散する。1 つの AZ に障害があってもアプリケーションを継続できる |
| RDS マルチ AZ 配置 | 別の AZ にスタンバイを置き、障害時にフェイルオーバーする |
| AZ ごとの NAT ゲートウェイ | 1 つの NAT ゲートウェイを複数 AZ で共有していると、その AZ がダウンしたときに他の AZ のリソースもインターネットにアクセスできなくなる。耐障害性を高めるには AZ ごとに作る |
| CloudFormation | 同じ構成を何度でも同じように作り直せる（インフラストラクチャの整合性） |
クラウドおさるRDS といえば「リードレプリカ」というのも聞いたでござる。マルチ AZ と何が違うのでござるか？ どちらも DB のコピーでござろう？
土肥ここがいちばん取り違えやすいところだね。目的がまったく違うんだ。
| 項目 | マルチ AZ DB インスタンス | マルチ AZ DB クラスター | リードレプリカ |
|---|---|---|---|
| 主な目的 | 可用性（フェイルオーバー） | 可用性 + 読み取りの処理 | 読み取り性能のスケールアウト |
| コピーの数 | スタンバイ 1 つ | 読み取り可能なスタンバイ 2 つ | 必要に応じて作成 |
| 読み取りトラフィック | スタンバイは処理しない | 処理できる | 処理できる |
土肥もう 1 つの違いはコピーの仕方で、マルチ AZ のスタンバイには同期でレプリケーションされるのに対して、リードレプリカは非同期で更新されるんだ。「AZ 障害でも DB を止めたくない」ならマルチ AZ、「読み取りが多くてプライマリが重い」ならリードレプリカ。要件の言葉が「可用性」なのか「読み取り性能」なのかで選ぶんだ。
クラウドおさるマルチ AZ は留守番の控え猿、リードレプリカは問い合わせ窓口を増やす猿でござるな。控え猿は窓口には立たない、と覚えておくでござる。
観点 3: 高パフォーマンス ── キャッシュと伸縮
クラウドおさる高パフォーマンスの分野はタスクが 5 つもあるでござる。何から押さえればよいのでござるか？
土肥ストレージ・コンピューティング・データベース・ネットワーク・データ取り込みと、レイヤーごとに「用途に合った選択」を問う作りなんだ。共通するキーワードは キャッシュ と 伸縮 だよ。
| 課題 | 打ち手 | 試験ガイドでの位置 |
|---|---|---|
| 遠方のユーザーへの配信が遅い | CloudFront でエッジロケーションから配信する | 3.4 エッジネットワークサービス |
| 同じ読み取りクエリで DB が重い | ElastiCache でインメモリにキャッシュする | 3.3 キャッシュ戦略とサービス |
| 読み取りが多くてプライマリが重い | リードレプリカに読み取りを分散する | 3.3 データベースレプリケーション |
| アクセス量が時間帯で大きく変わる | Auto Scaling で台数を増減する | 3.2 スケーラビリティ機能 |
土肥CloudFront は、ユーザーのリクエストを最も速く配信できるエッジロケーションへ AWS のネットワーク経由で振り分けて、コンテンツがキャッシュにあればそこから返す。オリジンまで行かなくて済むぶん、レイテンシーが下がるんだ。
クラウドおさる山頂の倉庫まで毎回登らずに、ふもとの出店にバナナを置いておくということでござるな！
土肥そうそう。それから、伸縮を判断するには「いま本当に重いのか」を測る必要があるよね。CloudWatch のメトリクスとアラームがここで効いてくるんだ。
クラウドおさるキャッシュもリードレプリカも「読み取り」を軽くするものでござるが、書き込みが重いときには効かぬのでござるな。
土肥よく気づいたね。どちらも読み取りの負荷を逃がす仕組みだから、課題が読み取りなのか書き込みなのかを最初に見極めるのが大事なんだ。
観点 4: コスト最適化 ── ストレージクラスと購入オプション
クラウドおさる最後はバナナの節約でござる！ どこで差がつくのでござるか？
土肥代表的なのがストレージと EC2 の買い方だよ。まず S3 のストレージクラス。アクセス頻度と、取り出しにどれだけ待てるかで選ぶんだ。
| ストレージクラス | 向いているデータ | 最小ストレージ期間 | 保存先の AZ |
|---|---|---|---|
| S3 Standard | 頻繁にアクセスする | なし | 3 つ以上 |
| S3 Intelligent-Tiering | アクセスパターンが不明・変化する | なし | 3 つ以上 |
| S3 Standard-IA | アクセス頻度は低いが、すぐに取り出したい | 30 日 | 3 つ以上 |
| S3 One Zone-IA | アクセス頻度が低く、再作成できる | 30 日 | 1 つ |
| S3 Glacier Instant Retrieval | めったにアクセスしないが、すぐに取り出したいアーカイブ | 90 日 | 3 つ以上 |
| S3 Glacier Flexible Retrieval | 取り出しに数分〜数時間かかってよいアーカイブ | 90 日 | 3 つ以上 |
| S3 Glacier Deep Archive | ほとんど取り出さない長期アーカイブ | 180 日 | 3 つ以上 |
クラウドおさるStandard-IA と One Zone-IA は名前がそっくりでござる。
土肥違いは保存先の AZ の数だね。One Zone-IA は 1 つの AZ にしか保存しないから、その AZ が失われるとデータも失われる。だから「再作成できるデータ」向けなんだ。コストと耐障害性のどちらを優先するか、という判断になるよ。
土肥次に EC2 の購入オプション。使い方の見通しで選ぶよ。
| 購入オプション | 仕組み | 向いている使い方 |
|---|---|---|
| オンデマンド | 起動している分だけ支払う | 短期・予測できない使い方、検証 |
| Savings Plans | 1〜3 年の期間、1 時間あたりの使用量（USD）を契約して割引を受ける | 長期で一定量使い続ける。インスタンスの構成ではなく使用額で契約したい |
| リザーブドインスタンス | 1〜3 年の期間、インスタンスタイプやリージョンなどの構成を契約して割引を受ける | 長期で同じ構成を使い続ける |
| スポットインスタンス | 未使用の EC2 キャパシティを大幅な割引で使う。AWS がキャパシティを必要とすると中断される（2 分前に通知） | 中断されても再実行できるバッチ・データ分析 |
クラウドおさるスポットは安いけれど、いつ返せと言われるかわからぬのでござるな。止まると困る見張り当番には使えぬでござる。
土肥そのとおり。それからネットワークのコストも分野 4 に入っているよ。NAT ゲートウェイは使用可能な時間と処理したデータ量で課金されるし、AZ をまたぐ通信が多いならリソースと同じ AZ に NAT ゲートウェイを置くことが推奨されている。観点 2 で出てきた「AZ ごとの NAT ゲートウェイ」は、可用性とコストの両方に効く判断なんだ。
クラウドおさる1 つの判断が、倒れにくさとバナナの両方に効くこともあるのでござるな。日々のコストの見張りは Budgets と Cost Explorer で覚えたでござる。
取り違えやすい組み合わせのまとめ
土肥最後に、ここまでで出てきた「似ているけど違う」組み合わせを並べておくね。
| 組み合わせ | 見分けるポイント | 観点 |
|---|---|---|
| セキュリティグループ / ネットワーク ACL | ステートフル・インスタンス単位・許可のみ / ステートレス・サブネット単位・拒否も書ける | セキュア |
| マルチ AZ / リードレプリカ | 可用性のための同期コピー / 読み取り性能のための非同期コピー | レジリエント・高パフォーマンス |
| NAT ゲートウェイ 1 つを共有 / AZ ごとに配置 | 数が少ないぶん安い / AZ 障害に強く、AZ 間の通信も減らせる | レジリエント・コスト |
| S3 Standard-IA / S3 One Zone-IA | 3 つ以上の AZ に保存 / 1 つの AZ に保存（再作成できるデータ向け） | コスト |
| リザーブドインスタンス / Savings Plans | インスタンスの構成を契約 / 1 時間あたりの使用額を契約 | コスト |
クラウドおさるどれも「要件の言葉がどの観点を指しているか」を読めば選べるのでござるな。弊猿、ようやく 4 つの目がそろったでござる。
—
実践
AWS Well-Architected Tool で、ここまでのハンズオンで作ってきた Web アプリケーション構成をワークロードとして定義し、SAA の 4 つの観点に対応する質問に 1 問ずつ回答します。そのうえで、改善計画を柱で絞り込み、観点ごとのリスクを確認します。Well-Architected Tool の基本的な使い方（マイルストーンの保存など）は AWS Well-Architected Tool でワークロードをレビューする で扱っているので、ここでは「観点別に見る」ことに絞ります。
前提条件
- リージョン:
ap-northeast-1（東京） - AWS Well-Architected Tool を操作できる権限を持つ IAM ユーザーまたはロールでログイン済みであること
- AWS Well-Architected Tool はワークロードをレビューする無料のサービスで、ワークロードの定義や質問への回答では AWS リソースは作成されません
この実践では、次のような構成をレビューする想定で回答します。
| 観点 | 想定する構成 |
|---|---|
| セキュア | パブリックサブネットとプライベートサブネットに分け、セキュリティグループで通信を絞っている |
| レジリエント | ELB と Auto Scaling で EC2 を 2 つの AZ に配置している |
| 高パフォーマンス | 用途に合わせて RDS を選んでいるが、キャッシュはまだ入れていない |
| コスト最適化 | EC2 はすべてオンデマンドで動かしている |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| Well-Architected Tool のワークロード | saa-review-webapp | SAA の 4 つの観点で回答するレビュー対象 |
手順 1: ワークロードを定義する
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
Well-Architectedと入力し、表示された「AWS Well-Architected Tool」を選択します - 左側ナビゲーションの「ワークロード」を選択し、「ワークロードの定義」→「ワークロードの定義」をクリックします
- 「ワークロードのプロパティ」で以下を入力します
- 名前:
saa-review-webapp - 説明:
SAA の 4 つの設計観点でのセルフチェック - レビューの所有者: 自分の名前またはチーム名
- 環境:
本番稼働前 - リージョン: 「AWS リージョン」をオンにし、
アジアパシフィック (東京)を選択 - その他の項目はデフォルトのままにし、「次へ」をクリックします
- 「プロファイル」は何も選ばずに「次へ」をクリックします
- 「レンズ」で「AWS Well-Architected Framework」にチェックが入っていることを確認し、「ワークロードの定義」をクリックします
手順 2: 4 つの観点に対応する質問に回答する
- ワークロードの概要画面で「レビューを開始」をクリックし、表示されたメニューから「AWS Well-Architected Framework」を選択します
- 最初の質問（OPS 1）が表示され、左側に 6 つの柱が折りたたまれた状態で並びます。ここでは SAA の 4 分野に対応する柱から 1 問ずつ選んで回答します
| SAA の観点 | 柱 | 回答する質問 |
|---|---|---|
| セキュア | セキュリティ | SEC 5. ネットワークリソースをどのように保護しますか? |
| レジリエント | 信頼性 | REL 10. ワークロードを保護するために障害分離をどのように使用しますか? |
| 高パフォーマンス | パフォーマンス効率 | PERF 3. ワークロード内のデータはどのように保存、管理、アクセスすればよいでしょうか? |
| コスト最適化 | コスト最適化 | COST 7. コストを削減するには、料金モデルをどのように使用したらよいでしょうか? |
- 左側の「セキュリティ」を展開して「SEC 5」を選択し、想定する構成に当てはまる以下の 2 つにチェックを入れます
ネットワークレイヤーを作成するネットワークレイヤー内のトラフィックを制御する- 「次へ」をクリックして回答を保存します
- 左側の「信頼性」を展開して「REL 10」を選択し、以下の 1 つにチェックを入れます
複数の場所にワークロードをデプロイする
- 右側の「便利なリソース」には、各ベストプラクティスの解説へのリンクが並びます。チェックを入れなかった項目が、技術解説で整理したどの判断に当たるかを見ておきます
- 「次へ」をクリックして回答を保存します
- 左側の「パフォーマンス効率」を展開して「PERF 3」を選択し、以下の 1 つにチェックを入れます。キャッシュはまだ入れていない想定なので、
キャッシュを利用するデータアクセスパターンを実装するにはチェックを入れません データアクセスとストレージ要件に最適な専用データストアを使用する- 「次へ」をクリックして回答を保存します
- 左側の「コスト最適化」を展開して「COST 7」を選択します。すべてオンデマンドで動かしている想定なので、料金モデルに関するベストプラクティスのどれにも当てはまらないことを確認します。ここではチェックを入れずに画面を見るだけにします
- 「保存して終了」をクリックします
クラウドおさる4 つの柱から 1 問ずつ選ぶと、SAA の 4 つの観点がそのまま質問の形で並ぶのでござるな。チェックできなかった項目が、そのまま弊猿の伸びしろでござる。
手順 3: 観点ごとのリスクを確認する
- ワークロードの概要画面に戻り、「回答済みの全体的な質問」が
3/57になっていること、「全体的なリスク」に高リスク・中リスクの件数が表示されていることを確認します - チェックしなかったベストプラクティスに応じて、回答した質問にリスクが付きます。この想定では、REL 10 と PERF 3 が高リスク、SEC 5 が中リスクになります
- 何もチェックしなかった COST 7 は「未回答」として扱われ、回答済みの件数にもリスクにも数えられません。実際のレビューで「どれにも取り組んでいない」と記録するには、選択肢の最後にある「いずれも該当しません」を選びます
手順 4: 改善計画を柱で絞り込む
- 左側ナビゲーションの
saa-review-webapp配下にある「AWS Well-Architected Framework」を選択し、「改善計画」タブを選択します（ワークロードの概要画面ではなく、レンズの画面にあるタブです） - 「改善項目」に、リスクが付いた質問が一覧表示されます
- 「柱でフィルターする」で
信頼性を選択し、レジリエントの観点に当たる REL 10 の改善項目だけが表示されることを確認します - 「推奨される改善項目」を展開すると、チェックしなかった
バルクヘッドアーキテクチャを使用して影響範囲を制限すると単一のロケーションに制約されるコンポーネントのリカバリを自動化するが、解説へのリンクとして表示されます
- 同じように「柱でフィルターする」を
パフォーマンス効率に切り替え、PERF 3 の改善項目にキャッシュの利用が並ぶことを確認します。コスト最適化に切り替えると、未回答の COST 7 は改善項目に出てこないことも分かります
クラウドおさる柱で絞り込むと、観点ごとに「次に何を学べばよいか」の地図になるのでござる。技術解説の比較表と見比べながら、リンク先の解説を読んでいくでござる。
—
まとめ
| SAA-C03 の分野（配点） | 対応する柱 | よく問われる設計の判断 |
|---|---|---|
| セキュア（30%） | セキュリティ | 最小権限と MFA、セキュリティグループとネットワーク ACL、パブリック / プライベートサブネット、KMS による暗号化 |
| レジリエント（26%） | 信頼性 | SQS などによる疎結合、複数 AZ への配置、マルチ AZ 配置、AZ ごとの NAT ゲートウェイ |
| 高パフォーマンス（24%） | パフォーマンス効率 | CloudFront・ElastiCache によるキャッシュ、リードレプリカ、Auto Scaling |
| コスト最適化（20%） | コスト最適化 | S3 のストレージクラス、EC2 の購入オプション、NAT ゲートウェイとデータ転送のコスト |
- SAA-C03 は Well-Architected Framework に基づく設計力を問う試験で、4 分野は 4 つの柱にほぼ対応する
- マルチ AZ は可用性のための同期コピー、リードレプリカは読み取り性能のための非同期コピーで、目的が違う
- キャッシュとリードレプリカは読み取りの負荷を逃がす仕組みで、課題が読み取りか書き込みかを先に見極める
- コストは「アクセス頻度」「中断を許容できるか」「長期で使い続けるか」で選択肢が決まる
- Well-Architected Tool で柱ごとに質問へ回答し、改善計画を柱で絞り込むと、観点別のセルフチェックができる
—
参照先
- AWS Certified Solutions Architect – Associate (SAA-C03)
- コンテンツ分野 1: セキュアなアーキテクチャの設計
- コンテンツ分野 2: レジリエントなアーキテクチャの設計
- コンテンツ分野 3: 高パフォーマンスなアーキテクチャの設計
- コンテンツ分野 4: コストを最適化したアーキテクチャの設計
- AWS Well-Architected フレームワーク
- フレームワークの柱
- AWS Well-Architected Tool とは
- AWS Well-Architected Tool 用語集
- AWS WA Tool でのワークロードの定義
- AWS Well-Architected フレームワークを使用したワークロードのレビュー
- AWS WA Tool でのワークロードのレンズに関する詳細の表示
- Amazon VPC のインフラストラクチャセキュリティ
- Amazon RDS でのマルチ AZ 配置の設定と管理
- DB インスタンスのリードレプリカの操作
- Amazon Simple Queue Service とは?
- Amazon EC2 Auto Scaling とは
- NAT ゲートウェイの基本
- NAT ゲートウェイの料金
- Amazon CloudFront とは何ですか?
- Amazon ElastiCache とは
- Amazon S3 ストレージクラスの理解と管理
- Amazon EC2 の請求および購入オプション
- スポットインスタンス
- REL 10. ワークロードを保護するために障害分離をどのように使用しますか?
- COST 7. コストを削減するには、料金モデルをどのように使用したらよいでしょうか?
