仮の宿 学習室 資格 クラウド・AI・Python 合格ラボ クラウドの考え方と責任分界 クラウド・AI・Python CLOUD / AI / PYTHON
クラウドの考え方と責任分界
講義 4 本・確認問題 40 問 ｜ 本試験では「AWS認定」（0問）の一部 ｜ 最終更新 2026-09-24
この章で学ぶこと オンプレミスとの違い、従量課金という考え方、そして AWS 認定が4つのレベルにどう並んでいるかが分かります。 AWS が守る範囲と利用者が守る範囲の境目が、選んだサービスによってどう動くのかが分かります。 設計の良し悪しを言葉で議論するための、AWS 公式の6つの観点が分かります。 AWS のインフラが世界にどう配置されているかと、マルチAZという可用性設計の基本が分かります。 1. クラウドとは何か、AWS認定の全体像
オンプレミスとの違い、従量課金という考え方、そして AWS 認定が4つのレベルにどう並んでいるかが分かります。
クラウドコンピューティングとは、サーバーやストレージ、データベースといったITの資源を自分で買って持つのではなく、必要なときに必要な分だけ借りて使い、使った分だけ支払う形態です。AWS はその資源を提供する事業者の一つで、利用者はマネジメントコンソールやAPI、コマンドラインから資源を要求し、不要になったら返します。要求してから使えるようになるまでの時間は分単位で、返せばその時点から料金も止まります。ここが、機器を買って自社に置く従来のやり方といちばん大きく違うところです。
従来のやり方をオンプレミスと呼びます。自社の建物や借りたデータセンターに機器を設置し、電源・空調・ネットワーク・OSの面倒まで自分で見る形です。オンプレミスでいちばん難しいのは、どれだけの性能をいつ用意するかを買う前に決めなければならない点です。多めに買えば、使われないまま減価償却していく設備を抱えることになります。少なめに買えば、繁忙期に処理が追いつかず、追加の機器が届くまで何週間も待つことになります。前者を過剰プロビジョニング、後者をキャパシティ不足といい、どちらも「将来の需要は正確には読めない」という同じ原因から生じます。クラウドは、この見積もりを事前に当てにいく作業そのものを不要にします。実際の需要に合わせて後から増やし、要らなくなったら減らせばよいからです。
料金の考え方は、AWS 公式が4つの原則として整理しています。1つ目は従量課金（Pay-as-you-go）で、長期の契約をせず、使った分だけを支払います。予測ではなく実需に合わせて増減できるので、過剰プロビジョニングのリスクが小さくなります。2つ目はコミットして節約（Save when you commit）で、Savings Plans のように1年または3年の期間で一定の使用量にコミットする代わりに、単価が割り引かれます。3つ目は使うほど安くなる（Pay less by using more）で、S3 やデータ転送のように使用量が増えるほど1GBあたりの単価が下がる段階的な料金体系が適用されます。4つ目は定額（Flat rate）で、複数のサービスをまとめて月額固定にし、超過料金が出ないようにするプランです。この4つは目的が違うので、対立するものではなく組み合わせて使います。
AWS認定は、クラウドの知識と技能を第三者に示すための資格です。レベルはFoundational、Associate、Professional、Specialtyの4つに分かれます。Foundationalはクラウド全体の概念と用語を広く浅く問う入口、Associateは実際に設計・開発・運用する立場で必要になる判断を問う中核、Professionalは複数の要件が衝突する場面での設計判断を問う上位、Specialtyはネットワークやセキュリティといった特定領域を深く問うものです。すべての認定には試験コードが付いていて、たとえば AWS Certified Cloud Practitioner なら CLF-C02、AWS Certified Solutions Architect - Associate なら SAA-C03 です。末尾の数字は改訂の世代を表すので、教材や問題集を選ぶときはこのコードが現行のものかを必ず確かめます。
認定の名称と本数は、改称・新設・終了がひんぱんに起こります。2026年8月時点で押さえておきたい変更が4つあります。第一に、SysOps Administrator - Associate は CloudOps Engineer - Associate に改称され、試験コードも SOA-C02 から SOA-C03 になりました（新コードは2025年9月30日開始）。第二に、AWS Certified Machine Learning - Specialty（MLS-C01）は2026年3月31日で受験が終了し、後継は Machine Learning Engineer - Associate です。第三に、Security - Specialty は SCS-C03 に更新され、生成AIとMLのセキュリティが加わりました。第四に、Machine Learning Engineer - Associate は MLA-C01 から MLA-C02 への切り替えが進行中です。こうした事情があるので、「Specialtyは全部で何本か」のような数を覚える勉強は割に合いません。覚えるなら試験コード付きの正式名称です。
学習計画の土台になるのが、各認定の Exam Guide に書かれた出題ドメインとその比率です。CLF-C02 は Cloud Concepts が24パーセント、Security and Compliance が30パーセント、Cloud Technology and Services が34パーセント、Billing, Pricing, and Support が12パーセントの4ドメインで構成されます。サービスの知識を問う Cloud Technology and Services がいちばん厚く、次がセキュリティです。SAA-C03 は Design Secure Architectures が30パーセント、Design Resilient Architectures が26パーセント、Design High-Performing Architectures が24パーセント、Design Cost-Optimized Architectures が20パーセントの4ドメインです。こちらもセキュアな設計がいちばん厚く、4つのドメインは名前のとおり Well-Architected の柱と対応づけて理解できます。この比率は Exam Guide に明記されている安定した事実なので、そのまま学習時間の配分に使えます。
一方で、受験料・問題数・試験時間・合格スコアは改訂のたびに動きます。2026年8月時点の参考値を挙げると、CLF-C02 は65問（うち採点対象50問）・90分・合格スコア700、SAA-C03 は65問（うち採点対象50問）・130分・合格スコア720で、スコアはどちらも100から1,000のスケールです。採点は compensatory scoring model といって、ドメインごとに合格ラインがあるわけではなく総合スコアだけで合否が決まります。未回答は不正解として扱われ、当てずっぽうで答えることへの減点はありません。本ラボでは、これらの数字は問題にしません。試験を申し込む直前に公式ページで確認するのが正しい付き合い方です。
AWS認定の体系（2026年8月時点、公式の Exam Guide 一覧に掲載されているもの） レベル 正式名称 試験コード Foundational AWS Certified Cloud Practitioner CLF-C02 Foundational AWS Certified AI Practitioner AIF-C01 Associate AWS Certified Solutions Architect - Associate SAA-C03 Associate AWS Certified Developer - Associate DVA-C02 Associate AWS Certified CloudOps Engineer - Associate SOA-C03 Associate AWS Certified Data Engineer - Associate DEA-C01 Associate AWS Certified Machine Learning Engineer - Associate MLA-C01 Professional AWS Certified Solutions Architect - Professional SAP-C02 Professional AWS Certified DevOps Engineer - Professional DOP-C02 Professional AWS Certified Generative AI Developer - Professional AIP-C01 Specialty AWS Certified Advanced Networking - Specialty ANS-C01 Specialty AWS Certified Security - Specialty SCS-C03
用語 クラウドコンピューティング ITの資源を自分で保有せず、必要なときに必要な分だけ借りて使い、使った分だけ支払う利用形態。要求から利用開始までが短く、返却すれば課金も止まる。 オンプレミス 自社の建物や借りたデータセンターに機器を設置し、調達から運用まで自前で行う形態。使う量を買う前に見積もる必要がある。 過剰プロビジョニング 将来の需要を多めに見積もって設備を用意しすぎ、使われない資源のコストを抱えてしまう状態。クラウドでは後から増減できるため起こりにくい。 従量課金（Pay-as-you-go） AWS の料金原則の一つ。前払いも長期のコミットメントもなく、使った分だけ支払う。実需に応じてスケールできる。 コミットして節約（Save when you commit） AWS の料金原則の一つ。1年または3年の期間で一定の使用量にコミットする代わりに単価が割り引かれる。Savings Plans が代表例。 使うほど安くなる（Pay less by using more） AWS の料金原則の一つ。S3 やデータ転送などで、使用量が増えるほど単位あたりの単価が下がる段階的な料金体系が適用される。 定額（Flat rate） AWS の料金原則の一つ。複数のサービスを月額固定料金にまとめ、超過料金が発生しないようにするプラン。上位ティアへの変更ができる。 Foundational AWS認定のうち、クラウドの概念と用語を広く問う入口のレベル。CLF-C02 と AIF-C01 が該当する。 Associate AWS認定のうち、設計・開発・運用の実務判断を問う中核のレベル。SAA-C03、DVA-C02、SOA-C03、DEA-C01、MLA-C01 が該当する。 Professional AWS認定のうち、要件が衝突する場面での上位の設計判断を問うレベル。SAP-C02、DOP-C02、AIP-C01 が該当する。 Specialty AWS認定のうち、特定領域を深く問うレベル。2026年8月時点では ANS-C01 と SCS-C03 が該当するが、新設と終了が続く。 試験コード CLF-C02 や SAA-C03 のように認定ごとに付く識別子。末尾の数字が改訂の世代を表し、教材が現行版かを見分ける手がかりになる。 Exam Guide AWS が認定ごとに公開する公式の試験ガイド。出題ドメインとその比率、対象範囲のサービス一覧が書かれている。 ドメイン Exam Guide が定める出題分野の区分。CLF-C02 と SAA-C03 はいずれも4つのドメインで構成され、それぞれに比率が示されている。 CloudOps Engineer - Associate 旧 SysOps Administrator - Associate の新名称。試験コードは SOA-C03 で、2025年9月30日に開始された。 compensatory scoring model AWS認定の採点方式。ドメインごとの合格ラインはなく、総合スコアだけで合否が決まる。未回答は不正解として扱われる。 例題
例題：季節商品を扱う通販サイトが、年に一度の繁忙期にだけ通常の10倍のアクセスを受ける。オンプレミスで運用する場合とクラウドで運用する場合とで、設備の考え方はどう変わるか。
答えと考え方 オンプレミスでは、年に一度の10倍のピークに耐えられる台数を先に買って置いておくことになる。残りの11か月半はその設備の大半が遊んでいるが、費用は変わらず発生する。これが過剰プロビジョニングである。クラウドでは平常時の台数だけを動かしておき、繁忙期に台数を増やして、終わったら減らす。増やした期間の分だけ支払えばよいので、遊んでいる設備を抱えずに済む。ここで押さえたいのは、クラウドが安いのは単価が安いからではなく、要らない時間に払わなくてよいからだという点である。逆にいえば、24時間365日ほぼ一定の負荷しかないワークロードでは、単純な従量課金だけでは有利にならないこともある。その場合は Savings Plans のように使用量にコミットして単価を下げる原則を組み合わせる。
例題：AWS Certified Advanced Networking - Specialty の試験コードは何で、どのレベルに位置づけられるか。また、認定を「何本あるか」で覚えるのが勧められないのはなぜか。
答えと考え方 試験コードは ANS-C01 で、レベルは Specialty である。本数で覚えるのが勧められないのは、認定の新設と終了が続いているからである。2024年4月には Data Analytics、Database、SAP on AWS の3つの Specialty が終了し、2026年3月31日には Machine Learning - Specialty（MLS-C01）も受験が終了した。一方で AI Practitioner（AIF-C01）や Generative AI Developer - Professional（AIP-C01）のように新設されたものもある。数は毎年変わるが、試験コード付きの正式名称は改訂されるまで変わらないので、こちらを手がかりに覚えるほうが長持ちする。
出典・根拠：Amazon Web Services, Inc.「AWS Certified Cloud Practitioner 試験ガイド (CLF-C02)」（2026年8月確認）／Amazon Web Services, Inc.「AWS Certified Solutions Architect - Associate 試験ガイド (SAA-C03)」（2026年8月確認）／Amazon Web Services, Inc.「AWS Certification Exam Guides」（2026年8月確認）
2. 責任共有モデル
AWS が守る範囲と利用者が守る範囲の境目が、選んだサービスによってどう動くのかが分かります。
クラウドを使うと、機器や施設の管理は事業者に任せられます。しかし、任せられるのはそこまでで、その上に載せたデータや設定まで安全になるわけではありません。どこまでが AWS の仕事で、どこからが利用者の仕事なのかを整理したものが責任共有モデル（Shared Responsibility Model）です。AWS認定では最頻出の考え方で、CLF-C02 でも SAA-C03 でもセキュリティ関連のドメインが最も大きな比率を占めています。
AWS 公式は、境目を2つの言い方で表現します。AWS の責任は「Security of the Cloud」、つまりクラウド「の」セキュリティです。AWS はAWSクラウドで提供されるすべてのサービスを実行するインフラストラクチャの保護に責任を持ち、そこには AWSクラウドサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設が含まれます。データセンターの建物、入退室管理、電源、物理サーバー、それらをつなぐネットワーク機器、そして仮想化の基盤までが AWS 側です。利用者はこの部分を自分で監査したり触ったりはできず、AWS の第三者認証や監査報告書を通じて確認します。
利用者の責任は「Security in the Cloud」、つまりクラウド「内」のセキュリティです。ここで最も大事なのは、利用者の責任範囲が固定ではないという点です。公式は「顧客の責任は、顧客が選択するAWSクラウドサービスによって決まる」と述べています。同じ AWS でも、どのサービスを選ぶかによって、利用者がやらなければならない設定作業の量が変わります。この一文を読み飛ばすと、責任共有モデルはただの図の暗記になってしまいます。
具体的に見ます。Amazon EC2 のような仮想サーバーを選んだ場合、利用者はゲストOSの管理（更新とセキュリティパッチの適用を含む）、インスタンスに導入したアプリケーションソフトウェアやユーティリティ、そして AWS が提供するファイアウォールであるセキュリティグループの設定を担います。OSの中は利用者の領域なので、Linux に重大な脆弱性が公表されても、AWS が勝手に修正プログラムを当ててはくれません。利用者側の設定作業がいちばん多くなるのがこのタイプです。
これに対し、Amazon S3 や Amazon DynamoDB のような抽象化された、あるいはマネージドなサービスでは、AWS がインフラストラクチャ層、OS、プラットフォームまでを運用します。利用者はエンドポイントにアクセスしてデータを保存・取得するだけで、OSにログインすることもパッチを当てることもありません。そのかわり利用者は、自分のデータの管理（暗号化オプションを含む）、資産の分類、そして IAM ツールによる適切な権限の適用に責任を持ちます。つまり「OSのパッチ適用は誰の責任か」という問いには一つの答えがなく、EC2 なら利用者、S3 なら AWS が正解になります。逆に、データの分類と暗号化の選択、IAM での権限付与は、どのサービスを選んでも常に利用者の責任です。
AWS はさらに、コントロール（統制）を3つに分類しています。継承されるコントロール（Inherited Controls）は、利用者が AWS から完全に受け継ぐもので、物理的・環境的なコントロールが該当します。共有コントロール（Shared Controls）は、インフラ層と利用者層の両方に、それぞれ別々に適用されるもので、パッチ管理、構成管理、意識向上とトレーニングが挙げられています。たとえばパッチ管理は、AWS が自分のインフラにパッチを当て、利用者がゲストOSとアプリケーションにパッチを当てる、というように同じ営みが両側で並行して行われます。顧客固有のコントロール（Customer Specific Controls）は完全に利用者の責任で、サービスとゾーンのセキュリティなどが該当します。
試験でも実務でも効くのは、次の3つの判断です。物理データセンターとハードウェアのセキュリティは、どんなサービスを使っていても常に AWS。IAM での権限付与とデータの暗号化オプションの選択は、どんなサービスを使っていても常に利用者。そしてその中間にあるOSやミドルウェアの面倒を誰が見るかは、選んだサービスによって動く。この3段で覚えると、初見のサービスが出てきても「これは EC2 寄りか、S3 寄りか」と考えるだけで境目を推測できます。
選んだサービスによって境目がどう動くか 場面 AWS が責任を持つ範囲 利用者が責任を持つ範囲 どのサービスでも共通 ハードウェア、ソフトウェア、ネットワーキング、施設の保護 データの分類、暗号化オプションの選択、IAM による権限付与 Amazon EC2 を選んだ場合 物理基盤と仮想化レイヤーまで ゲストOSの更新と修正プログラム、導入したアプリケーション、セキュリティグループの設定 Amazon S3 や DynamoDB を選んだ場合 インフラストラクチャ層、OS、プラットフォームの運用 エンドポイント経由で保存するデータの管理と権限設定
用語 責任共有モデル AWS と利用者のセキュリティ責任の境目を整理した公式の考え方。境目はサービスごとに動く。 Security of the Cloud AWS 側の責任。AWSクラウドのすべてのサービスを実行するインフラストラクチャ、すなわちハードウェア、ソフトウェア、ネットワーキング、施設の保護を指す。 Security in the Cloud 利用者側の責任。範囲は利用者が選択したAWSクラウドサービスによって決まり、選んだサービス次第で必要な設定作業の量が変わる。 Inherited Controls 継承されるコントロール。利用者が AWS から完全に受け継ぐもので、物理的・環境的なコントロールが該当する。 Shared Controls 共有コントロール。インフラ層と利用者層の両方にそれぞれ別々に適用されるもので、パッチ管理、構成管理、意識向上とトレーニングが該当する。 Customer Specific Controls 顧客固有のコントロール。完全に利用者の責任となるもので、サービスとゾーンのセキュリティなどが該当する。 ゲストOS EC2 インスタンスの中で動くOS。更新とセキュリティパッチの適用は利用者の責任範囲に含まれる。 セキュリティグループ AWS が提供するファイアウォール機能。EC2 を使う場合、その設定は利用者の責任になる。 抽象化されたサービス S3 や DynamoDB のように、AWS がインフラ層・OS・プラットフォームまで運用し、利用者はエンドポイント経由でデータを扱うだけのサービス。 資産の分類 自分が扱うデータの重要度や機微さを区分する作業。抽象化されたサービスを使う場合でも利用者の責任に残る。 例題
例題：EC2 インスタンス上で自社開発のWebアプリケーションを動かしていたところ、そのアプリの入力処理に SQL インジェクションの脆弱性があり、データを抜き取られた。AWS に責任を問えるか。
答えと考え方 問えない。インスタンスに導入したアプリケーションソフトウェアは Security in the Cloud、すなわち利用者の責任範囲に明記されている。AWS が保証しているのは、そのインスタンスを動かしている物理サーバーやネットワーク、施設が保護されていることまでである。同じ理屈で、ゲストOSに未適用の修正プログラムが残っていて侵入された場合も、EC2 を選んでいる以上は利用者の責任になる。逆に、AWS のデータセンターに物理的に侵入されて機器が持ち出されたのであれば、それは Security of the Cloud の側の話になる。責任共有モデルは責任逃れの仕組みではなく、どちらが手を動かすべきかを事前に決めておくための地図だと考えるとよい。
例題：責任共有モデルは、利用者にとってどんな利点があるのか。
答えと考え方 運用の負担が減ることである。物理施設の入退室管理、電源と空調の冗長化、ハードウェアの故障対応、ネットワーク機器の保守といった作業は、どんな組織でも必要だが、どこの組織がやってもだいたい同じ内容になる。これを AWS 側に寄せることで、利用者は自社にしか判断できない部分、つまりどのデータが重要で、誰にどこまでの権限を与え、どんな設定で暗号化するかに人手を集中できる。ただし、負担が減ることと責任がなくなることは別である。利用者側に残った範囲は、以前と変わらず自分で守らなければならない。
出典・根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
3. Well-Architected フレームワークの6本の柱
設計の良し悪しを言葉で議論するための、AWS 公式の6つの観点が分かります。
「この構成でいいのか」を議論しようとすると、話がすぐに散らかります。速さの話をしていたはずが費用の話になり、いつのまにか運用のしやすさの話になる。AWS Well-Architected フレームワークは、この議論をあらかじめ観点ごとに分けておくための枠組みです。観点は柱（Pillar）と呼ばれ、2026年8月時点では6本あります。
1本目は運用上の優秀性（Operational Excellence）です。システムの実行と監視、およびプロセスと手順の継続的な改善に焦点を当てます。デプロイを自動化する、障害のたびに振り返りを行って手順を直す、変更を小さく頻繁に行う、といった営みがここに入ります。動いているかどうかではなく、動かし続ける仕組みを良くしていくことを見る柱です。
2本目はセキュリティ（Security）です。情報とシステムの保護に焦点を当てます。データの完全性とアクセス制御が中心で、責任共有モデルで利用者側に残る範囲の大半はこの柱の関心事になります。SAA-C03 の出題ドメインでいちばん比率が大きいのが Design Secure Architectures であることからも、AWS がこの柱をどれだけ重く見ているかが分かります。
3本目は信頼性（Reliability）です。ワークロードが意図した機能を果たすこと、および障害からいかに迅速に復旧するかに焦点を当てます。複数のアベイラビリティゾーンへの分散、自動復旧、バックアップと復旧手順の検証がここに属します。「壊れないようにする」だけでなく「壊れたときに早く戻す」までを含むのが特徴です。
4本目はパフォーマンス効率（Performance Efficiency）です。ITリソースの割り当ての最適化と、ワークロードのニーズに合ったリソースタイプの選択に焦点を当てます。単に速くするのではなく、要求に見合った資源を選び、需要が変わったら選び直すという、割り当ての適切さを見る柱です。
5本目はコスト最適化（Cost Optimization）です。無駄な支出をなくし、ビジネス要件に対してリソースを適正化することに焦点を当てます。使っていない資源を止める、過大なインスタンスを適正なサイズに直す、料金モデルを使い分ける、といった判断がここに入ります。安くすること自体が目的ではなく、支払いに見合う価値が出ているかを問う柱です。
6本目は持続可能性（Sustainability）です。クラウドワークロードの実行による環境への影響を最小化することに焦点を当てます。2021年に追加された最も新しい柱で、ここが古い教材との分かれ目になります。「Well-Architected の柱は5本」と書かれた解説は、この柱が加わる前のものです。現行は6本なので、5本と覚えていたら上書きしてください。
柱どうしはしばしば衝突します。可用性を上げるために構成を二重化すれば費用は増え、費用を削れば信頼性が下がります。フレームワークが求めているのは、6つすべてを最大化することではなく、どの柱をどれだけ優先するかを意図して決め、その判断を記録しておくことです。だから設問でも「この取り組みは主にどの柱に属するか」という形で問われます。取り組みの内容そのものより、その取り組みが何を良くしようとしているのかを見るのがこつです。
Well-Architected フレームワークの6本の柱（2026年8月時点） 番号 英語の正式名 日本語 焦点 1 Operational Excellence 運用上の優秀性 システムの実行と監視、プロセスと手順の継続的な改善 2 Security セキュリティ 情報とシステムの保護、データの完全性とアクセス制御 3 Reliability 信頼性 意図した機能を果たすこと、障害からの迅速な復旧 4 Performance Efficiency パフォーマンス効率 リソース割り当ての最適化とリソースタイプの選択 5 Cost Optimization コスト最適化 無駄な支出の排除とリソースの適正化 6 Sustainability 持続可能性 ワークロード実行による環境への影響の最小化
用語 AWS Well-Architected フレームワーク クラウド上のワークロードの設計を6つの観点から点検するための AWS 公式の枠組み。観点は柱（Pillar）と呼ばれる。 運用上の優秀性 Operational Excellence。システムの実行と監視、およびプロセスと手順の継続的な改善に焦点を当てる柱。 セキュリティ Security。情報とシステムの保護に焦点を当てる柱。データの完全性とアクセス制御が中心になる。 信頼性 Reliability。ワークロードが意図した機能を果たすこと、および障害からいかに迅速に復旧するかに焦点を当てる柱。 パフォーマンス効率 Performance Efficiency。ITリソースの割り当ての最適化と、ワークロードのニーズに合ったリソースタイプの選択に焦点を当てる柱。 コスト最適化 Cost Optimization。無駄な支出をなくし、ビジネス要件に対してリソースを適正化することに焦点を当てる柱。 持続可能性 Sustainability。クラウドワークロードの実行による環境への影響を最小化することに焦点を当てる柱。2021年に6本目として追加された。 柱（Pillar） Well-Architected フレームワークにおける設計の観点。現行は6本で、互いに衝突することがあるため優先順位を意図して決める。 例題
例題：あるチームが、デプロイを手作業から自動化し、障害が起きるたびに振り返りの会を開いて手順書を更新する運用を始めた。この取り組みは主にどの柱に属するか。また、この取り組みが結果的に良くする別の柱はあるか。
答えと考え方 主に属するのは運用上の優秀性である。この柱はシステムの実行と監視、およびプロセスと手順の継続的な改善に焦点を当てており、デプロイの自動化も振り返りによる手順の更新もそのまま該当する。結果的に良くなる柱としては信頼性が挙げられる。手作業のデプロイは作業ミスによる障害の原因になりやすく、それを自動化すれば障害の発生自体が減り、振り返りで復旧手順が磨かれれば復旧も早くなるからである。このように、ある取り組みが複数の柱に効くことは珍しくない。設問で問われるのは「主にどれか」なので、その取り組みが直接何を良くしようとしているのかを見る。
例題：1つの取り組みが複数の柱に同時に効くことはあるか。あるとしたら、どの柱の話として整理すればよいか。
答えと考え方 あります。たとえば使っていないインスタンスを止める取り組みは、支出を減らすのでコスト最適化に属しますが、動いている資源が減るぶん環境への影響も小さくなるので持続可能性にも効きます。デプロイの自動化は運用上の優秀性の話ですが、手作業のミスによる障害が減るので信頼性も上がります。柱は互いに排他ではなく、同じ改善が複数にまたがるのがふつうです。整理するときは、その取り組みを始めた動機がどの柱の焦点に当たるかで主たる柱を決め、副次的に効く柱は別に書き添えます。動機で決めると、要件を満たすためにリソースの種類を選び直すのはパフォーマンス効率、払いすぎを直すために同じ作業をするのはコスト最適化、と迷わず分けられます。
出典・根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
4. リージョン、アベイラビリティゾーン、エッジロケーション
AWS のインフラが世界にどう配置されているかと、マルチAZという可用性設計の基本が分かります。
AWS のインフラは、大きさの違う3つの単位で語られます。リージョン、アベイラビリティゾーン、エッジロケーションです。この3つはよく並べて説明されますが、目的がまったく違います。混同したまま覚えると、可用性の設計でもコンテンツ配信の設計でも判断を誤るので、最初に切り分けておきます。
リージョン（Region）は、AWS が複数のアベイラビリティゾーンを持つ、世界の物理的な場所です。us-east-1 や ap-northeast-1 のような名前が付いています。公式の定義で押さえておきたいのは、各リージョンが「少なくとも3つの、独立して物理的に分離されたアベイラビリティゾーン」で構成されるという点です。リージョンの数そのものは増え続けていて覚える意味が薄いのですが、1リージョンが最低いくつのゾーンを持つかという構成の決まりは安定しています。リージョンを選ぶときの判断材料は、データをどの国に置くかという所在地と法規制、利用者からの距離すなわちレイテンシ、そして料金です。
アベイラビリティゾーン（Availability Zone、AZ）は、リージョンの中にある障害分離の単位です。公式の定義では、1つ以上の独立したデータセンターで構成され、それぞれが冗長化された電源、ネットワーク、接続性を備え、別々の施設に収容されているとされています。ここが肝心で、AZ は「データセンター1棟」ではなく「1つ以上のデータセンターのまとまり」であり、しかも他のAZとは別の建物に入っています。だから、ある建物が停電や火災で落ちても、同じリージョンの別のAZは動き続けます。単一のデータセンターでは実現できない水準の高可用性を、この分離によって作り出しているわけです。
この性質をそのまま設計に使うのがマルチAZ構成です。同じ役割のサーバーを2つ以上のAZに分けて置き、ロードバランサーで振り分けておけば、片方のAZがまるごと落ちても残りで処理を続けられます。データベースも、主系と待機系を別々のAZに置いて自動で切り替わるようにするのが定石です。逆にいえば、すべてを1つのAZに置いた構成は、そのAZの障害がそのままサービス全停止になります。可用性を上げたいという要件が出てきたら、まず「AZをまたいでいるか」を確認するのが出発点になります。なお、AWS のネットワークを設計するときに使うサブネットは、必ず単一のAZに属します。2つのAZにまたがる1つのサブネットは作れないので、マルチAZにしたければAZごとにサブネットを用意することになります。
エッジロケーション（Edge Location）は、まったく別の目的の単位です。Amazon CloudFront がコンテンツを配信する、世界規模のデータセンターネットワークを指します。利用者のリクエストは最も低レイテンシのエッジロケーションにルーティングされ、そこに目当てのコンテンツがキャッシュされていれば即座に配信されます。キャッシュされていなければ、オリジン（S3 バケットやHTTPサーバーなど）から取得して配信し、次回のためにキャッシュします。つまりエッジロケーションは、可用性を上げるための冗長化の単位ではなく、利用者に近いところから配りなおすためのキャッシュの拠点です。数はAZよりはるかに多く、リージョンとは独立して世界中に分散しています。Point of Presence、略してPOPとも呼ばれます。
関連する用語もいくつかあります。リージョナルエッジキャッシュ（Regional Edge Cache）は、エッジロケーションとオリジンの間に置かれるキャッシュ層で、エッジで見つからなかったときにオリジンまで取りに行く回数を減らします。Local Zones は、エンドユーザーやワークロードのより近くにあるAWSインフラでアプリケーションを実行できるようにするもので、リージョンからは離れた都市に置かれます。Wavelength Zones は、通信キャリアのネットワーク内に配置されるゾーンです。これらは「近いところで動かす」ための仕組みという点で共通しますが、Local Zones と Wavelength Zones はアプリケーションそのものを動かす場所であり、エッジロケーションはコンテンツを配るキャッシュだ、という違いがあります。
最後に数について。2026年8月時点でリージョンは39、AZは124、CloudFront のPOPは750以上、リージョナルエッジキャッシュは15、Local Zones は46、Wavelength Zones は33です。ただしこれらは毎年変わるので、本ラボでは問題にしません。覚えるべきは定義のほうです。リージョンは少なくとも3つの分離されたAZで構成される、AZは冗長化された電源とネットワークを持ち別々の施設に収容されている、エッジロケーションは最も低レイテンシの場所から配信する。この3つの文が言えれば十分です。
3つの単位の違い 単位 公式の位置づけ 主な目的 リージョン 複数のAZを持つ世界の物理的な場所。少なくとも3つの分離されたAZで構成される データの所在地、法規制、レイテンシ、料金を見て選ぶ広い単位 アベイラビリティゾーン 1つ以上の独立したデータセンター。冗長化された電源とネットワークを備え別々の施設に収容 リージョン内の障害分離。マルチAZ構成の土台 エッジロケーション CloudFront がコンテンツを配信する世界規模のデータセンターネットワーク 最も低レイテンシの拠点からのキャッシュ配信
用語 リージョン AWS が複数のアベイラビリティゾーンを持つ、世界の物理的な場所。各リージョンは少なくとも3つの、独立して物理的に分離されたAZで構成される。 アベイラビリティゾーン（AZ） 1つ以上の独立したデータセンターで構成され、冗長化された電源、ネットワーク、接続性を備え、別々の施設に収容されている、リージョン内の障害分離の単位。 エッジロケーション CloudFront がコンテンツを配信する世界規模のデータセンターネットワーク。最も低レイテンシの拠点から配信し、なければオリジンから取得する。POPとも呼ばれる。 マルチAZ 同じ役割のリソースを2つ以上のAZに分けて配置する可用性設計。片方のAZがまるごと停止しても処理を続けられる。 サブネット VPC 内のIPアドレス範囲。必ず単一のAZに属するため、マルチAZ構成にするにはAZごとにサブネットを用意する。 オリジン CloudFront がキャッシュを持っていないときにコンテンツを取りに行く元の場所。S3 バケットやHTTPサーバーなどが該当する。 リージョナルエッジキャッシュ エッジロケーションとオリジンの間に置かれるキャッシュ層。オリジンまで取りに行く回数を減らす。 Local Zones エンドユーザーやワークロードのより近くのAWSインフラでアプリケーションを実行できるようにする仕組み。リージョンから離れた都市に置かれる。 Wavelength Zones 通信キャリアのネットワーク内に配置されるゾーン。 例題
例題：東京リージョンで動かしているWebサイトについて、南米からのアクセスだけ画像の表示が遅いという苦情が来た。まず検討すべき手はどれか。リージョンを南米にも増やす案とどう違うか。
答えと考え方 まず検討すべきは CloudFront を前に置き、エッジロケーションから配信させることである。エッジロケーションは世界中に分散していて、リクエストは最も低レイテンシの拠点にルーティングされる。画像のような静的コンテンツは一度キャッシュされれば、以降は南米の拠点から直接返るので、東京まで取りに行く往復がなくなる。リージョンを増やす案との違いは規模である。リージョンを増やすとは、アプリケーションもデータベースも別の場所に構築し、データの同期と整合性まで面倒を見るということで、費用も運用の手間も桁が違う。配信の遅さがコンテンツの距離に由来するなら、キャッシュの拠点を増やすほうが先に効く。
例題：新しいシステムをどのリージョンに置くかを決めることになった。何を材料に判断するか。
答えと考え方 3つある。第一にデータの所在地と法規制である。扱うデータをどの国に置いてよいのかが決まっている場合、そこが最優先の制約になる。第二にレイテンシで、主な利用者がいる場所に近いリージョンほど応答が速くなる。第三に料金で、同じサービスでもリージョンによって単価が異なる。この3つが衝突するときは、法規制が動かせない制約なので最初に置き、残りの2つで比べることになる。なお、どのリージョンを選んでも「少なくとも3つの分離されたAZで構成される」という前提は変わらないので、AZの数で選ぶ必要はない。
出典・根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）／Amazon Web Services, Inc.「Amazon CloudFront デベロッパーガイド」（2026年8月確認）
確認問題（40問） 四肢択一。「正解と解説」を開くと、正解の理由と他の選択肢が違う理由を確認できます。
問1｜クラウドの特徴
オンプレミスと比べたときのクラウドコンピューティングの特徴として、最も適切なものはどれか。
利用する資源の量を導入前に確定させ、その量に合わせて機器を購入しておく 機器の設置と電源や空調の管理を、自社の担当者が直接行う必要がある 必要なときに必要な分だけ資源を借り、使った分だけ料金を支払う 契約した期間中は資源の量を変更できず、返却も期間の満了まで待つ 正解と解説 正解：C. 必要なときに必要な分だけ資源を借り、使った分だけ料金を支払う クラウドコンピューティングは、ITの資源を保有せずに必要なときに必要な分だけ借り、使った分だけ支払う利用形態である。要求から利用開始までが短く、返却すればその時点で課金も止まる。導入前に必要量を確定させて機器を購入するのも、電源や空調まで自社で管理するのもオンプレミスのやり方であり、量を先に決めなければならないために過剰プロビジョニングやキャパシティ不足が起こる。契約期間中に量を変更できないという説明は、後から増減できるというクラウドの前提と逆になっている。
根拠：Amazon Web Services, Inc.「AWS の料金」ページ（2026年8月確認）
問2｜従量課金
AWS の料金の原則のうち、従量課金（Pay-as-you-go）の説明として適切なものはどれか。
前払いも長期のコミットメントもなく、使った分だけを支払う 1年または3年の期間で一定の使用量にコミットして単価を下げる 使用量が増えるほど単位あたりの単価が下がる段階的な体系をとる 複数のサービスを月額固定にまとめ、超過料金が発生しないようにする 正解と解説 正解：A. 前払いも長期のコミットメントもなく、使った分だけを支払う 従量課金（Pay-as-you-go）は、前払いも長期のコミットメントもなく、実際に使った分だけを支払う原則である。予測ではなく実需に応じてスケールできるので、過剰プロビジョニングのリスクを減らせる。期間を決めて使用量にコミットする代わりに単価が下がるのはコミットして節約（Save when you commit）、使用量が増えるほど単価が下がるのは使うほど安くなる（Pay less by using more）、月額固定にまとめて超過料金を出さないのは定額（Flat rate）であり、いずれも別の原則を指している。
根拠：Amazon Web Services, Inc.「AWS の料金」ページ（2026年8月確認）
問3｜段階的料金
使うほど安くなる（Pay less by using more）という AWS の料金原則の内容はどれか。
1年または3年の期間で一定の使用量にコミットする代わりに単価が割り引かれる 前払いや長期の契約をせず、実際に使った分だけをそのつど支払う仕組みである 複数のサービスを月額固定料金にまとめ、超過料金が発生しないようにする 使用量が増えるほど単位あたりの単価が下がる段階的な料金体系が適用される 正解と解説 正解：D. 使用量が増えるほど単位あたりの単価が下がる段階的な料金体系が適用される 使うほど安くなる（Pay less by using more）は、S3 やデータ転送などで段階的な料金体系が適用され、使用量が増えるほどGBあたりの単価が下がるという原則である。期間を決めて使用量にコミットして単価を下げるのはコミットして節約（Save when you commit）で、Savings Plans がこれにあたる。実際に使った分だけをそのつど支払うのは従量課金（Pay-as-you-go）、月額固定にまとめて超過料金を出さないのは定額（Flat rate）である。4つの原則は目的が異なるので、対立するものではなく組み合わせて使う。
根拠：Amazon Web Services, Inc.「AWS の料金」ページ（2026年8月確認）
問4｜コミット割引
Savings Plans に代表される、コミットして節約（Save when you commit）の考え方として正しいものはどれか。
使用量にかかわらず月額が固定され、超過した分は翌月に繰り越される 1年または3年の期間で一定の使用量にコミットする代わりに単価が下がる 使用量が一定の水準を超えたときだけ、超えた分の単価が引き下げられる 前払いも長期のコミットメントもなく、いつでも自由に利用をやめられる 正解と解説 正解：B. 1年または3年の期間で一定の使用量にコミットする代わりに単価が下がる コミットして節約（Save when you commit）は、Savings Plans のように1年または3年という期間で特定の使用量レベルにコミットする代わりに、コンピューティングや機械学習のサービスの料金が割り引かれる原則である。月額を固定して超過料金を出さないのは定額（Flat rate）で、繰り越しの仕組みではない。使用量が増えるほど単価が下がる段階的な体系は使うほど安くなる（Pay less by using more）にあたる。コミットメントを伴わずいつでもやめられるのは従量課金（Pay-as-you-go）の性質であり、コミットを前提とするこの原則とは前提が逆になる。
根拠：Amazon Web Services, Inc.「AWS の料金」ページ（2026年8月確認）
問5｜基礎レベル
AWS認定のうち、Foundational レベルに位置づけられる認定の組合せはどれか。
Cloud Practitioner と AI Practitioner Cloud Practitioner と Developer - Associate AI Practitioner と Advanced Networking - Specialty Developer - Associate と Data Engineer - Associate 正解と解説 正解：A. Cloud Practitioner と AI Practitioner 2026年8月時点の公式の試験ガイド一覧で Foundational に置かれているのは、AWS Certified Cloud Practitioner（CLF-C02）と AWS Certified AI Practitioner（AIF-C01）の2つである。Developer - Associate（DVA-C02）と Data Engineer - Associate（DEA-C01）はいずれも Associate、Advanced Networking - Specialty（ANS-C01）は Specialty に置かれている。名称の末尾にレベル名が付く認定はそれが手がかりになるが、Cloud Practitioner と AI Practitioner にはレベル名が付かないので、この2つが Foundational だと覚えておく。
根拠：Amazon Web Services, Inc.「AWS Certification Exam Guides」（2026年8月確認）
問6｜CLF-C02
試験コード CLF-C02 が示す AWS認定の正式名称はどれか。
AWS Certified AI Practitioner AWS Certified Developer - Associate AWS Certified Cloud Practitioner AWS Certified Data Engineer - Associate 正解と解説 正解：C. AWS Certified Cloud Practitioner CLF-C02 は AWS Certified Cloud Practitioner の試験コードである。CLF は Cloud Practitioner を、末尾の C02 は改訂の世代を表す。AWS Certified AI Practitioner のコードは AIF-C01、AWS Certified Developer - Associate は DVA-C02、AWS Certified Data Engineer - Associate は DEA-C01 である。認定の名称は改称されることがあるが、試験コードは改訂されるまで変わらないので、教材が現行版かどうかはコードで確かめるのが確実である。
根拠：Amazon Web Services, Inc.「AWS Certification Exam Guides」（2026年8月確認）
問7｜試験コード
Solutions Architect の Professional レベルに対応する試験コードはどれか。
SAA-C03 SAP-C02 SOA-C03 SCS-C03 正解と解説 正解：B. SAP-C02 AWS Certified Solutions Architect - Professional の試験コードは SAP-C02 である。SAA-C03 は同じ Solutions Architect でも Associate レベルのもの、SOA-C03 は CloudOps Engineer - Associate、SCS-C03 は Security - Specialty のコードである。頭3文字が似ていて紛らわしいが、SAA が Associate、SAP が Professional と対応していると押さえるとよい。
根拠：Amazon Web Services, Inc.「AWS Certification Exam Guides」（2026年8月確認）
問8｜CLF比率
AWS Certified Cloud Practitioner（CLF-C02）の Exam Guide が定める4つのドメインについて、出題比率の大小関係として正しいものはどれか。
Security and Compliance が最も大きく、Cloud Concepts が最も小さい Cloud Concepts が最も大きく、Security and Compliance が最も小さい Billing, Pricing, and Support が最も大きく、Cloud Technology and Services が最も小さい Cloud Technology and Services が最も大きく、Billing, Pricing, and Support が最も小さい 正解と解説 正解：D. Cloud Technology and Services が最も大きく、Billing, Pricing, and Support が最も小さい CLF-C02 の Exam Guide は、Cloud Concepts が24パーセント、Security and Compliance が30パーセント、Cloud Technology and Services が34パーセント、Billing, Pricing, and Support が12パーセントと定めている。したがって最大は Cloud Technology and Services、最小は Billing, Pricing, and Support である。入門の認定なので概念が最も厚いと思われがちだが、実際にはサービスの知識を問うドメインが最大で、次がセキュリティである。学習時間の配分はこの比率にそのまま合わせるとよい。
根拠：Amazon Web Services, Inc.「AWS Certified Cloud Practitioner 試験ガイド (CLF-C02)」（2026年8月確認）
問9｜SAA比率
AWS Certified Solutions Architect - Associate（SAA-C03）の Exam Guide で、出題比率が最も大きいドメインはどれか。
Design Cost-Optimized Architectures Design High-Performing Architectures Design Secure Architectures Design Resilient Architectures 正解と解説 正解：C. Design Secure Architectures SAA-C03 の Exam Guide は、Design Secure Architectures が30パーセント、Design Resilient Architectures が26パーセント、Design High-Performing Architectures が24パーセント、Design Cost-Optimized Architectures が20パーセントと定めている。最大はセキュアなアーキテクチャの設計である。4つのドメイン名は Well-Architected の柱と対応づけて読むと覚えやすく、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の順に並んでいることが分かる。
根拠：Amazon Web Services, Inc.「AWS Certified Solutions Architect - Associate 試験ガイド (SAA-C03)」（2026年8月確認）
問10｜CloudOps
旧 SysOps Administrator - Associate（SOA-C02）の後継として2025年9月30日に開始された認定はどれか。
AWS Certified CloudOps Engineer - Associate（SOA-C03） AWS Certified Data Engineer - Associate（DEA-C01） AWS Certified DevOps Engineer - Professional（DOP-C02） AWS Certified Machine Learning Engineer - Associate（MLA-C01） 正解と解説 正解：A. AWS Certified CloudOps Engineer - Associate（SOA-C03） 運用系の Associate 認定は名称が SysOps Administrator から CloudOps Engineer に変わり、試験コードも SOA-C02 から SOA-C03 になった。旧コードの最終受験日は2025年9月29日、新コードの開始は2025年9月30日である。Data Engineer - Associate と Machine Learning Engineer - Associate は運用系の後継ではなく、それぞれデータとMLの領域で新設された別の認定である。DevOps Engineer - Professional は以前から存在する Professional レベルの認定で、レベルも異なる。
根拠：Amazon Web Services, Inc.「AWS Certification Exam Guides」（2026年8月確認）
問11｜AWSの責任
責任共有モデルにおける「Security of the Cloud」の範囲として、適切なものはどれか。
インスタンスに導入したアプリケーションソフトウェアの脆弱性への対応 保存するデータを暗号化するかどうかの選択と、その運用方針の決定 IAM を使って利用者やロールに与える権限を設計し、適用すること AWSのサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設の保護 正解と解説 正解：D. AWSのサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設の保護 AWS 公式は AWS 側の責任を「Security of the Cloud」と呼び、AWSクラウドで提供されるすべてのサービスを実行するインフラストラクチャの保護、すなわちハードウェア、ソフトウェア、ネットワーキング、施設の保護であると定めている。インスタンスに導入したアプリケーションの脆弱性対応は、EC2 を選んだ場合の利用者の責任である。データの暗号化オプションの選択と IAM による権限付与は、どのサービスを選んでも利用者側に残る作業であり、いずれも「Security in the Cloud」の側に属する。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問12｜利用者の責任
責任共有モデルにおいて、利用者の責任（Security in the Cloud）の広さは何によって決まるとされているか。
利用者が契約しているサポートプランの種類によって決まる 利用者が選択したAWSクラウドサービスによって決まる リソースを配置したリージョンとアベイラビリティゾーンによって決まる アカウントの利用開始からの経過期間と月間の利用金額によって決まる 正解と解説 正解：B. 利用者が選択したAWSクラウドサービスによって決まる 公式は「顧客の責任は、顧客が選択するAWSクラウドサービスによって決まる」と明記している。選んだサービスに応じて、セキュリティ責任の一部として利用者が行うべき設定作業の量が変わるという意味である。サポートプランは技術支援の受け方を決めるものであり、責任の境目を動かすものではない。リージョンやアベイラビリティゾーンは配置の話、利用期間や利用金額は課金の話であって、どれも責任範囲の広さを決める要因ではない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問13｜EC2のパッチ
Amazon EC2 でLinuxの仮想サーバーを運用している。ゲストOSへのセキュリティパッチの適用は誰の責任か。
利用者。ゲストOSの更新とパッチの適用は利用者の責任範囲に含まれる AWS。仮想サーバーのOSはAWSが運用するプラットフォームに含まれる AWS。ハードウェアの保護に付随する作業として自動で適用される 利用者。ただしサポートプランを契約した場合はAWSの責任に移る 正解と解説 正解：A. 利用者。ゲストOSの更新とパッチの適用は利用者の責任範囲に含まれる 公式は、EC2 のような構成が必要なサービスでは、利用者が「ゲストOSの管理（更新とセキュリティパッチを含む）、インスタンスにインストールしたアプリケーションソフトウェアやユーティリティ、セキュリティグループの設定」を担うとしている。したがってOSへのパッチ適用は利用者の責任である。EC2 で AWS が運用するのは物理基盤と仮想化レイヤーまでで、インスタンスの中のOSは含まれない。サポートプランは技術支援を受ける契約であって、責任の所在を移すものではない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問14｜S3の責任分担
Amazon S3 や Amazon DynamoDB のような抽象化されたサービスにおける責任の分担として、適切なものはどれか。
利用者がOSの更新を行い、AWSはデータの分類と暗号化の設定を担う AWSがデータの分類と権限設定まで行い、利用者は利用量の管理だけを担う AWSがインフラ層とOSとプラットフォームを運用し、利用者はデータと権限を担う 利用者がプラットフォームの運用を担い、AWSはネットワークの保護だけを担う 正解と解説 正解：C. AWSがインフラ層とOSとプラットフォームを運用し、利用者はデータと権限を担う 抽象化された、あるいはマネージドなサービスについて公式は「AWSがインフラストラクチャ層、OS、プラットフォームを運用し、顧客はエンドポイントにアクセスしてデータを保存・取得する」と述べている。利用者に残るのは、自分のデータの管理（暗号化オプションを含む）、資産の分類、IAM ツールによる適切な権限の適用である。OSの更新もプラットフォームの運用も利用者は行わないが、データの分類と権限設定はどのサービスでも利用者から離れない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問15｜境目は動く
「OSへの修正プログラムの適用は誰の責任か」という問いに対する、責任共有モデルの答えはどれか。
常にAWSの責任である。OSはインフラストラクチャの一部と定義されている 常に利用者の責任である。OSは利用者が動かすものと定義されている リージョンによって異なる。規制の厳しい地域ではAWSの責任になる 選んだサービスによって異なる。EC2 なら利用者、S3 なら AWS である 正解と解説 正解：D. 選んだサービスによって異なる。EC2 なら利用者、S3 なら AWS である 責任共有モデルの境目は固定ではなく、選んだサービスによって動く。EC2 のように利用者がゲストOSを管理するサービスではパッチ適用は利用者の責任だが、S3 や DynamoDB のように AWS がOSとプラットフォームまで運用するサービスでは AWS の責任になる。したがって「常にAWS」も「常に利用者」も誤りである。リージョンは配置場所の選択であって、責任の分担を変えるものではない。この一点を押さえておくと、初見のサービスでも EC2 寄りか S3 寄りかを考えるだけで境目を推測できる。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問16｜物理施設
AWS のデータセンターの建物や入退室管理といった物理的なセキュリティは、責任共有モデルでは誰の責任か。
利用者。自社が使うリージョンの施設については利用者が監査を行う AWS。施設の保護は Security of the Cloud に含まれ、常にAWSが負う 利用者とAWSの双方。利用者は施設に立ち入って点検する義務を負う 選んだサービスによる。EC2 を使う場合だけ利用者の責任に含まれる 正解と解説 正解：B. AWS。施設の保護は Security of the Cloud に含まれ、常にAWSが負う 施設はAWSクラウドサービスを実行するインフラストラクチャの一部として「Security of the Cloud」に明記されており、どのサービスを使っていても常に AWS の責任である。利用者はこの範囲を自分で監査したり立ち入って点検したりはできず、AWS が公開する第三者認証や監査報告書を通じて確認する。これは3つのコントロール分類でいう継承されるコントロール（Inherited Controls）にあたり、利用者が AWS から完全に受け継ぐ部分である。選んだサービスによって動くのはOSやミドルウェアの層であって、物理層ではない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問17｜常に利用者
利用するサービスの種類にかかわらず、常に利用者の責任に残る作業はどれか。
サービスを実行する物理サーバーの故障時の交換作業 リージョン間をつなぐバックボーンネットワークの保護 IAM による権限の付与と、データの暗号化オプションの選択 マネージドサービスの基盤となるOSへの修正プログラムの適用 正解と解説 正解：C. IAM による権限の付与と、データの暗号化オプションの選択 自分のデータの管理（暗号化オプションを含む）、資産の分類、IAM ツールによる適切な権限の適用は、抽象化されたサービスを使う場合でも利用者に残ると公式に明記されている。どのサービスを選んでも離れないので、境目を考えるときの固定点になる。物理サーバーの交換もバックボーンネットワークの保護も施設とハードウェアの話で、常に AWS の側である。マネージドサービスの基盤となるOSは AWS が運用するため、そのパッチ適用は利用者の作業ではない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問18｜継承の統制
3つのコントロール分類のうち、Inherited Controls（継承されるコントロール）の説明として適切なものはどれか。
利用者がAWSから完全に継承するもので、物理的・環境的なコントロールが該当する インフラ層と利用者層の両方に、それぞれ別々に適用されるコントロールである 完全に利用者の責任となるもので、サービスとゾーンのセキュリティが該当する AWSが利用者から継承するもので、利用者の設定内容を引き継いで運用する 正解と解説 正解：A. 利用者がAWSから完全に継承するもので、物理的・環境的なコントロールが該当する 継承されるコントロールは、利用者が AWS から完全に継承するもので、物理的・環境的なコントロールが該当すると公式に定義されている。インフラ層と利用者層の両方にそれぞれ別々に適用されるのは共有コントロール（Shared Controls）、完全に利用者の責任でサービスとゾーンのセキュリティが該当するのは顧客固有のコントロール（Customer Specific Controls）である。継承の向きは AWS から利用者への一方向であり、利用者の設定を AWS が引き継ぐという関係ではない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問19｜共有の統制
Shared Controls（共有コントロール）の例として AWS 公式が挙げているものはどれか。
データセンターの入退室管理、電源の冗長化、空調の維持 パッチ管理、構成管理、意識向上とトレーニング サービスとゾーンのセキュリティ、データの分類 ハードウェアの調達、物理サーバーの廃棄、回線の敷設 正解と解説 正解：B. パッチ管理、構成管理、意識向上とトレーニング 共有コントロールとして公式が挙げているのは、パッチ管理、構成管理、意識向上とトレーニングの3つである。いずれも同じ営みがインフラ層と利用者層の両方で並行して行われる点が特徴で、たとえばパッチ管理なら AWS が自分のインフラに、利用者がゲストOSとアプリケーションに、それぞれ別々に適用する。入退室管理や電源の冗長化、ハードウェアの調達と廃棄は物理的・環境的なコントロールで、利用者が AWS から継承する側にあたる。サービスとゾーンのセキュリティは顧客固有のコントロールの例である。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問20｜移行と責任
自社システムのデータ保存先を Amazon EC2 上の自前データベースから Amazon DynamoDB へ移した。責任共有モデルの観点で、移行によって変わる点と変わらない点の組合せとして適切なものはどれか。
ゲストOSのパッチ適用は引き続き利用者が担い、データの分類はAWSに移る 物理施設の保護が利用者に移り、IAM による権限付与もAWSに移る ゲストOSのパッチ適用も IAM による権限付与も、どちらもAWSに移る ゲストOSのパッチ適用はAWSに移り、IAM による権限付与は利用者に残る 正解と解説 正解：D. ゲストOSのパッチ適用はAWSに移り、IAM による権限付与は利用者に残る DynamoDB は抽象化されたサービスなので、AWS がインフラ層、OS、プラットフォームまで運用する。EC2 では利用者が担っていたゲストOSのパッチ適用は、移行によって AWS 側の作業になる。一方、データの分類と暗号化オプションの選択、IAM による権限付与は、どのサービスを選んでも利用者に残る。物理施設の保護はもともと常に AWS の責任なので、移行しても利用者に移ることはない。「動く部分はOSやプラットフォームの層、動かない部分はデータと権限」と整理して読むと迷わない。
根拠：Amazon Web Services, Inc.「責任共有モデル」ページ（2026年8月確認）
問21｜6本の柱
2026年8月時点で、AWS Well-Architected フレームワークの柱の構成として正しいものはどれか。
運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性 セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性、相互運用性 運用上の優秀性、セキュリティ、可搬性、パフォーマンス効率、コスト最適化、持続可能性 正解と解説 正解：B. 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性 現行の柱は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6本である。持続可能性は2021年に6本目として追加されたもので、これを欠いた5本の並びは追加前の古い情報にあたる。相互運用性と可搬性はフレームワークの柱として挙げられていない語であり、いずれも公式の一覧には存在しない。柱の本数が古い解説は、サービス名や試験コードも古い可能性が高いので、教材の鮮度を見分ける目印にもなる。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問22｜運用の優秀性
運用上の優秀性（Operational Excellence）の柱が焦点を当てているものはどれか。
情報とシステムの保護、およびデータの完全性とアクセス制御 ITリソースの割り当ての最適化と、要件に合ったリソースタイプの選択 無駄な支出をなくし、ビジネス要件に対してリソースを適正化すること システムの実行と監視、およびプロセスと手順の継続的な改善 正解と解説 正解：D. システムの実行と監視、およびプロセスと手順の継続的な改善 運用上の優秀性は、システムの実行と監視、およびプロセスと手順の継続的な改善に焦点を当てる柱である。デプロイの自動化、障害後の振り返りによる手順の更新、変更を小さく頻繁に行うことなどが該当する。情報とシステムの保護はセキュリティ、リソース割り当ての最適化とリソースタイプの選択はパフォーマンス効率、無駄な支出の排除とリソースの適正化はコスト最適化の焦点であり、いずれも別の柱を指している。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問23｜セキュリティ
次の取り組みのうち、セキュリティの柱の関心事として最も適切なものはどれか。
利用していないリソースを停止し、インスタンスのサイズを適正化する デプロイ手順を自動化し、障害の振り返りを行って手順書を更新する データを暗号化し、最小権限の原則にもとづいてアクセス制御を行う ワークロードの実行によって生じる環境への影響を測定し、削減する 正解と解説 正解：C. データを暗号化し、最小権限の原則にもとづいてアクセス制御を行う セキュリティの柱は情報とシステムの保護に焦点を当て、データの完全性とアクセス制御が中心になる。暗号化と最小権限にもとづくアクセス制御はそのまま該当する。使っていないリソースの停止とサイズの適正化はコスト最適化、デプロイの自動化と振り返りによる手順の更新は運用上の優秀性、環境への影響の測定と削減は持続可能性の関心事である。責任共有モデルで利用者側に残る範囲の大半は、このセキュリティの柱で扱うことになる。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問24｜信頼性
信頼性（Reliability）の柱が焦点を当てているものとして、適切なものはどれか。
ワークロードが意図した機能を果たすことと、障害からの迅速な復旧 ITリソースの割り当ての最適化と、ニーズに合ったリソースタイプの選択 システムの実行と監視、およびプロセスと手順の継続的な改善 クラウドワークロードの実行による環境への影響を最小化すること 正解と解説 正解：A. ワークロードが意図した機能を果たすことと、障害からの迅速な復旧 信頼性は、ワークロードが意図した機能を果たすこと、および障害からいかに迅速に復旧するかに焦点を当てる柱である。複数のアベイラビリティゾーンへの分散、自動復旧、バックアップと復旧手順の検証がここに属する。壊れないようにすることだけでなく、壊れたときに早く戻すところまでを含む点が特徴である。リソース割り当ての最適化はパフォーマンス効率、実行と監視および手順の改善は運用上の優秀性、環境への影響の最小化は持続可能性の焦点である。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問25｜性能効率
レイテンシの要件を満たすため、ワークロードのニーズに合ったリソースタイプを選び直し、割り当てを見直している。この取り組みは主にどの柱に属するか。
信頼性。意図した機能の遂行と障害からの復旧に焦点を当てる パフォーマンス効率。リソース割り当ての最適化と種類の選択に焦点を当てる コスト最適化。無駄な支出の排除とリソースの適正化に焦点を当てる 運用上の優秀性。実行と監視、手順の継続的な改善に焦点を当てる 正解と解説 正解：B. パフォーマンス効率。リソース割り当ての最適化と種類の選択に焦点を当てる パフォーマンス効率は、ITリソースの割り当ての最適化と、ワークロードのニーズに合ったリソースタイプの選択に焦点を当てる柱である。要件を満たすためにリソースタイプを選び直す営みはそのまま該当する。コスト最適化も似た作業に見えるが、そちらは支出の無駄をなくすことが目的であり、この場面ではレイテンシ要件を満たすことが動機なので焦点が異なる。信頼性は障害への強さ、運用上の優秀性は手順の改善を見る柱であり、いずれもここでの主眼ではない。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問26｜コスト最適化
コスト最適化（Cost Optimization）の柱の焦点として、適切なものはどれか。
情報とシステムの保護、およびデータの完全性とアクセス制御 ワークロードが意図した機能を果たすことと、障害からの迅速な復旧 クラウドワークロードの実行による環境への影響を最小化すること 無駄な支出をなくし、ビジネス要件に対してリソースを適正化すること 正解と解説 正解：D. 無駄な支出をなくし、ビジネス要件に対してリソースを適正化すること コスト最適化は、無駄な支出をなくし、ビジネス要件に対してリソースを適正化することに焦点を当てる柱である。使っていない資源を止める、過大なインスタンスを適正なサイズに直す、料金モデルを使い分けるといった判断が該当する。単に安くすることが目的ではなく、支払いに見合う価値が出ているかを問う点が要である。情報とシステムの保護はセキュリティ、意図した機能の遂行と復旧は信頼性、環境への影響の最小化は持続可能性の焦点である。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問27｜持続可能性
持続可能性（Sustainability）の柱が焦点を当てているものはどれか。
クラウドワークロードの実行による環境への影響を最小化すること ITリソースの割り当ての最適化と、ニーズに合ったリソースタイプの選択 システムの実行と監視、およびプロセスと手順の継続的な改善 ワークロードが意図した機能を果たすことと、障害からの迅速な復旧 正解と解説 正解：A. クラウドワークロードの実行による環境への影響を最小化すること 持続可能性は、クラウドワークロードの実行による環境への影響を最小化することに焦点を当てる柱である。2021年に6本目として追加された最も新しい柱で、この柱の有無が古い教材との分かれ目になる。リソース割り当ての最適化とリソースタイプの選択はパフォーマンス効率、実行と監視および手順の継続的な改善は運用上の優秀性、意図した機能の遂行と障害からの復旧は信頼性の焦点であり、いずれも別の柱を指している。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問28｜6本目の柱
「Well-Architected の柱は5本である」と書かれた古い解説記事では、どの柱が抜け落ちているか。
システムの実行と監視、およびプロセスと手順の継続的な改善を扱う柱 ITリソースの割り当ての最適化とリソースタイプの選択を扱う柱 クラウドワークロードの実行による環境への影響の最小化を扱う柱 ワークロードが意図した機能を果たすことと障害からの復旧を扱う柱 正解と解説 正解：C. クラウドワークロードの実行による環境への影響の最小化を扱う柱 抜けているのは持続可能性（Sustainability）で、クラウドワークロードの実行による環境への影響の最小化を扱う柱である。2021年に6本目として追加されたため、それ以前に書かれた解説は5本のままになっている。運用上の優秀性、パフォーマンス効率、信頼性は追加以前から存在する柱なので、5本と書かれた記事にも載っている。柱の本数のような基本の部分が古い記事は、ほかの記述も古い可能性が高いと考えたほうがよい。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問29｜柱でないもの
AWS Well-Architected フレームワークの柱として挙げられていないものはどれか。
コスト最適化（Cost Optimization） 運用上の優秀性（Operational Excellence） パフォーマンス効率（Performance Efficiency） 相互運用性（Interoperability） 正解と解説 正解：D. 相互運用性（Interoperability） 現行の柱は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6本であり、相互運用性はこの一覧に含まれない。異なるシステム同士がつながることは設計上の重要な関心事だが、Well-Architected フレームワークではそれ単独の柱を立てていない。コスト最適化、運用上の優秀性、パフォーマンス効率はいずれも6本のうちの正規の柱である。フレームワークにない語を柱として覚えてしまうと、選択肢の消し込みで迷う原因になる。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問30｜柱と焦点
Well-Architected フレームワークの柱と、その焦点との組合せとして適切でないものはどれか。
セキュリティ - 情報とシステムの保護、データの完全性とアクセス制御 信頼性 - 無駄な支出をなくし、ビジネス要件に対してリソースを適正化する 運用上の優秀性 - システムの実行と監視、プロセスと手順の継続的な改善 持続可能性 - クラウドワークロードの実行による環境への影響の最小化 正解と解説 正解：B. 信頼性 - 無駄な支出をなくし、ビジネス要件に対してリソースを適正化する 無駄な支出をなくし、ビジネス要件に対してリソースを適正化するのはコスト最適化の焦点であり、信頼性の焦点ではない。信頼性は、ワークロードが意図した機能を果たすことと、障害からいかに迅速に復旧するかに焦点を当てる柱である。ほかの3つは公式の記述どおりの組合せになっている。柱の名前は日常語に近いため、字面の印象で結びつけると取り違えやすい。焦点を表す一文とセットで覚えておくと、この形の設問でつまずかなくなる。
根拠：Amazon Web Services, Inc.「AWS Well-Architected フレームワーク」発行日 2024年11月6日（2026年8月確認）
問31｜リージョン
AWS のリージョン（Region）の説明として、適切なものはどれか。
複数のアベイラビリティゾーンを持つ、世界の物理的な場所を指す 1つ以上の独立したデータセンターで構成される、障害を分離するための単位を指す CloudFront がコンテンツをキャッシュして配信する拠点を指す 通信キャリアのネットワーク内に配置される専用のゾーンを指す 正解と解説 正解：A. 複数のアベイラビリティゾーンを持つ、世界の物理的な場所を指す リージョンは、AWS が複数のアベイラビリティゾーンを持つ、世界の物理的な場所である。us-east-1 や ap-northeast-1 のような名前が付いており、データの所在地と法規制、利用者からの距離、料金を見て選ぶ。1つ以上の独立したデータセンターで構成される障害分離の単位はアベイラビリティゾーンの説明にあたる。CloudFront がキャッシュして配信する拠点はエッジロケーション、通信キャリアのネットワーク内に置かれるのは Wavelength Zones である。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
問32｜AZの定義
アベイラビリティゾーン（AZ）の公式の定義として、適切なものはどれか。
複数のリージョンにまたがって配置される、論理的なネットワーク区画である エッジロケーションとオリジンの間に置かれる、中間のキャッシュ層である 1つ以上の独立したデータセンターで構成され、別々の施設に収容されている 利用者に近い都市に置かれ、アプリケーションを実行できる拠点である 正解と解説 正解：C. 1つ以上の独立したデータセンターで構成され、別々の施設に収容されている アベイラビリティゾーンは、1つ以上の独立したデータセンターで構成され、それぞれが冗長化された電源、ネットワーク、接続性を備え、別々の施設に収容されていると定義されている。データセンター1棟と同じではなく、まとまりを指す点と、他のゾーンとは別の建物にある点が要である。エッジロケーションとオリジンの間の層はリージョナルエッジキャッシュ、利用者に近い都市でアプリケーションを実行できるのは Local Zones の説明であり、いずれも別の仕組みを指している。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
問33｜最低3AZ
各リージョンを構成するアベイラビリティゾーンについて、AWS 公式が示している要件はどれか。
少なくとも2つの、同一の施設内に置かれたゾーンで構成される 少なくとも3つの、独立して物理的に分離されたゾーンで構成される 利用者が申請した数だけゾーンが割り当てられ、上限は設けられない ゾーンの数はリージョンごとに1つで、必要に応じて増設される 正解と解説 正解：B. 少なくとも3つの、独立して物理的に分離されたゾーンで構成される 公式は、各リージョンが「少なくとも3つの、独立して物理的に分離されたアベイラビリティゾーン」で構成されると述べている。リージョンの総数やゾーンの総数は増え続けるため覚える意味が薄いが、1リージョンが最低いくつのゾーンを持つかという構成の決まりは安定していて、そのまま設計の前提に使える。同一の施設内に置かれるという説明は、別々の施設に収容されるという定義と矛盾する。ゾーンは利用者が申請して増やすものでも、リージョンごとに1つだけのものでもない。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
問34｜エッジの役割
エッジロケーションの役割の説明として、適切なものはどれか。
リージョン内の障害を分離し、片方が停止しても処理を続けられるようにする VPC 内のIPアドレス範囲を区切り、ルートテーブルで経路を制御する 通信キャリアの設備内でアプリケーションを実行し、遅延を抑える CloudFront が最も低レイテンシの拠点からコンテンツを配信する 正解と解説 正解：D. CloudFront が最も低レイテンシの拠点からコンテンツを配信する エッジロケーションは、CloudFront がコンテンツを配信する世界規模のデータセンターネットワークである。リクエストは最も低レイテンシのエッジロケーションにルーティングされ、そこから配信される。可用性を上げるための冗長化の単位ではなく、利用者に近いところから配りなおすためのキャッシュの拠点だという点が要である。障害の分離はアベイラビリティゾーン、IPアドレス範囲の区切りはサブネット、通信キャリア設備内での実行は Wavelength Zones の役割である。
根拠：Amazon Web Services, Inc.「Amazon CloudFront デベロッパーガイド」（2026年8月確認）
問35｜キャッシュ無
CloudFront で、要求されたコンテンツがエッジロケーションにキャッシュされていなかった場合の動作はどれか。
リクエストは拒否され、利用者にはエラーが返される 同じリージョン内の別のアベイラビリティゾーンへ転送される オリジンから取得して配信し、次回のためにキャッシュする キャッシュが作られるまで、利用者は待機を求められる 正解と解説 正解：C. オリジンから取得して配信し、次回のためにキャッシュする リクエストは最も低レイテンシのエッジロケーションにルーティングされ、そこにコンテンツがあれば即座に配信される。なければ、S3 バケットやHTTPサーバーといったオリジンから取得して配信し、あわせてキャッシュに残す。だから2回目以降のリクエストは近い拠点から直接返るようになる。キャッシュがないことがエラーになったり、利用者が待たされたまま放置されたりはしない。アベイラビリティゾーンへの転送は障害分離の仕組みであり、コンテンツ配信の流れとは別の話である。
根拠：Amazon Web Services, Inc.「Amazon CloudFront デベロッパーガイド」（2026年8月確認）
問36｜中間キャッシュ
リージョナルエッジキャッシュ（Regional Edge Cache）の位置づけとして、適切なものはどれか。
エッジロケーションとオリジンの間に置かれるキャッシュ層である リージョン内のアベイラビリティゾーンをまとめる管理単位である 通信キャリアのネットワーク内に配置されるゾーンの総称である 利用者の端末上にコンテンツを保存するブラウザ側の仕組みである 正解と解説 正解：A. エッジロケーションとオリジンの間に置かれるキャッシュ層である リージョナルエッジキャッシュは、エッジロケーションとオリジンの間に位置するキャッシュ層である。エッジで見つからなかったときにオリジンまで取りに行く回数を減らす役目を持つ。アベイラビリティゾーンをまとめる管理単位はリージョン、通信キャリアのネットワーク内に配置されるゾーンは Wavelength Zones であり、いずれも別の概念である。利用者の端末側のキャッシュは AWS の仕組みではなく、ブラウザやOSが持つ機能にあたる。
根拠：Amazon Web Services, Inc.「Amazon CloudFront デベロッパーガイド」（2026年8月確認）
問37｜マルチAZ
同じ役割のサーバーを2つ以上のアベイラビリティゾーンに分けて配置する構成の、主な目的はどれか。
世界各地の利用者に対して、最も近い拠点からコンテンツを配信するため 扱うデータの所在地に関する法規制の要件を満たすようにするため 使用量へのコミットにより、コンピューティングの単価を下げるため 片方のゾーンがまるごと停止しても、処理を続けられるようにするため 正解と解説 正解：D. 片方のゾーンがまるごと停止しても、処理を続けられるようにするため アベイラビリティゾーンは別々の施設に収容され、冗長化された電源とネットワークを備えた障害分離の単位である。同じ役割のリソースを複数のゾーンに分けて置けば、片方のゾーンがまるごと停止しても残りで処理を続けられる。これがマルチAZ構成であり、可用性設計の出発点になる。最も近い拠点からの配信はエッジロケーションの役割、データの所在地はリージョン選択の判断材料、使用量へのコミットによる単価の引き下げは料金モデルの話であって、いずれもゾーンを分ける動機ではない。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
問38｜LocalZones
AWS の Local Zones の説明として、適切なものはどれか。
リージョン内で障害を分離するために設けられた、標準のゾーンである 利用者やワークロードのより近くでアプリケーションを実行できる仕組みである CloudFront がコンテンツをキャッシュして配る、配信専用の拠点である オリジンの手前に置かれ、取得回数を減らすための中間キャッシュである 正解と解説 正解：B. 利用者やワークロードのより近くでアプリケーションを実行できる仕組みである Local Zones は、エンドユーザーやワークロードのより近くのAWSインフラでアプリケーションを実行できるようにする仕組みで、リージョンからは離れた都市に置かれる。エッジロケーションと似て「近いところ」を扱うが、こちらはアプリケーションそのものを動かす場所であり、コンテンツを配るキャッシュではない点が違いである。リージョン内の障害分離はアベイラビリティゾーン、配信専用の拠点はエッジロケーション、オリジンの手前の中間キャッシュはリージョナルエッジキャッシュを指している。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
問39｜Wavelength
AWS の Wavelength Zones が置かれる場所として、適切なものはどれか。
通信キャリアのネットワークの中に配置される エッジロケーションとオリジンの中間に配置される リージョンの中に障害分離の単位として配置される VPC のIPアドレス範囲を区切る形で配置される 正解と解説 正解：A. 通信キャリアのネットワークの中に配置される Wavelength Zones は、通信キャリアのネットワーク内に配置されるゾーンである。Local Zones と同じく利用者に近いところでアプリケーションそのものを動かすための仕組みで、コンテンツを配るキャッシュの拠点であるエッジロケーションとは目的が異なる。エッジロケーションとオリジンの間に置かれるのはリージョナルエッジキャッシュ、リージョンの中で障害を分離する単位はアベイラビリティゾーン、VPC のIPアドレス範囲を区切るのはサブネットである。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
問40｜可用性設計
1つのアベイラビリティゾーンにWebサーバーとデータベースをまとめて配置している。ゾーンの障害が起きてもサービスを継続できるようにしたい。最初に検討すべき対応はどれか。
同じゾーン内にサーバーを増設し、ロードバランサーで振り分ける CloudFront を前段に置き、エッジロケーションから配信させる 同一リージョンの別のゾーンにもサーバーを配置し、振り分ける 使用量にコミットする料金プランに切り替え、費用の変動を抑える 正解と解説 正解：C. 同一リージョンの別のゾーンにもサーバーを配置し、振り分ける アベイラビリティゾーンは別々の施設に収容された障害分離の単位なので、ゾーンごと止まる事態に備えるにはゾーンをまたいで配置するしかない。各リージョンは少なくとも3つの分離されたゾーンで構成されるため、同一リージョン内で複数ゾーンへの分散が可能である。同じゾーン内で台数を増やしても、そのゾーンが落ちれば全滅するので要件を満たさない。CloudFront は配信を速くする仕組みであって、オリジンが止まれば動的な処理は続けられない。料金プランの変更は費用の話であり、可用性には関係しない。
根拠：Amazon Web Services, Inc.「AWS Global Infrastructure」（2026年8月確認）
演習：この章の問題を解く ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。
← クラウド・AI・Python 合格ラボ トップ 次の章：AWSの主要サービス → ※ 解説は学習用の情報提供です。最新の出題範囲・制度は必ず公式発表をご確認ください。