AWS SAA-C03 試験対策

セクション別　ポイント解説

各セクションの対策問題から、要点だけをまとめて読み返せます。 問題を解いた際の正答率からセクションを絞り込めるので、弱点をすばやく確認できます。

セクション一覧（全80セクション）

セキュアなアーキテクチャの設計 #1

オンプレミスのデータセンター宛のうち特定の範囲だけをアプライアンス経由にし、残りは Direct Connect へ直接出す経路を設計する・台数が変動するインスタンス群からの外向きの通信の送信元アドレスを、1 つに固定する構成を選ぶ・暗号化した EBS スナップショットを別リージョンへ複製するときに指定するキーを選ぶ・2 つのフォレストの従業員を、普段の認証情報のまま IAM Identity Center から AWS アカウントへサインインさせる手順を選ぶ・今後の DDoS 攻撃で増えた利用料について、AWS へクレジットを申請できるようにしておく方法を選ぶ

弾力性に優れたアーキテクチャの設計 #1

追加するリージョンを平常時にも活かしつつ、片方の喪失にも耐える構成を選ぶ・順序を守る単位と並列度を両立させる、メッセージグループの決め方を選ぶ・分散できない 1 台構成のアプリケーションを、障害時に自動で置き換える・帳票の画像から構造を取り出す処理と、文章から意味を判定する処理を、それぞれの目的特化型サービスへ割り当てる・Windows と Active Directory を前提とした共有フォルダの置き場所を選ぶ

高パフォーマンスなアーキテクチャの設計 #1

1 か所に集中したオブジェクトの読み出しで断られる状況を、性能の割り当ての単位から解消する・ファイル数の急増で遅くなったファイルシステムについて、どの性能の軸を引き上げるかを選ぶ・サイズの見直しの推奨が的を外すときに、材料になる指標と分析される期間の両方を補う・利用者の国と処理するリージョンの対応を確実にする・書き込みが終わった分だけを安い層へ移し、検索が続く分と転送料の思い込みを切り分ける

コストを最適化したアーキテクチャの設計 #1プレミアム

1,100 個のリソースを同じ分析にかけ、変更先の候補まで含んだ削減の結果を受け取る・使う時間帯が限られる開発用データベースで、使っていない時間の費用をどう消すかを問う・アクセスの頻度が読めないログを、すぐに読める状態のまま最も安く保管できる S3 のストレージクラスを選ぶ・中断を許容できるタスクには割安な実行基盤を、24 時間動くタスクにはコミット型の割引を、別々に当てる・参照されなくなった項目を、削除の費用をかけずに取り除く手段を問う

セキュアなアーキテクチャの設計 #2プレミアム

既に付いているパブリック ACL による公開を、社内の読み取りを止めずに短時間で解消する方法を選ぶ・組織のすべてのアカウントへ、後から作られる分も含めて同じ検査ルールを最小の手間で行き渡らせる手順の組み合わせを選ぶ・暗号化されたスナップショットを持つ AMI を一般公開できる状態にする・専用接続を使って、複数リージョンの Amazon S3 と Amazon DynamoDB へ届く経路を用意する・レプリケーション設定より前からあるオブジェクトを、元のメタデータを保ったまま送信先へ複製する方法を選ぶ

弾力性に優れたアーキテクチャの設計 #2プレミアム

停止したタスクを人手を介さずにあるべき数へ戻すコンテナ実行の構成を選ぶ・後続を止めている失敗を個別に切り離し、解決後に元の経路へ戻す 2 つのステップを選ぶ・人の承認をはさみ、二度実行できない処理を含むワークフローの組み方を選ぶ・名前解決に依存せずに数秒でリージョンを切り替える方法を選ぶ・リージョン障害への備えを、RPO と RTO と平常時の費用から選ぶ

高パフォーマンスなアーキテクチャの設計 #2プレミアム

工場の中で動かす必要がある構成の置き場所と形を決める・月に 2 日しか使わないデータウェアハウスの費用を、どの提供形態で抑えるかを選ぶ・バッチで受け取る処理の再試行の範囲を、失敗した項目だけに絞る方法を選ぶ・VPC が増え続ける構成で、相互接続の作り方を選び直す・1 本のブロックボリュームを 2 台のインスタンスから同時に読み書きするために必要な条件をそろえる

コストを最適化したアーキテクチャの設計 #2プレミアム

遅い理由が距離だと問題文に書かれているので、エッジ経由で長距離の区間を短くする加速機能を選ぶ・専用接続の開通までの空白を埋め、開通後に暫定の費用を残さないための 2 つの手順を選ぶ・アーカイブ階層に移して得をするスナップショットと、移すとかえって損をするスナップショットを切り分ける・読み取り専用のファイルを増減の激しい閲覧に配るとき、動かし続ける実行基盤を持たない置き場を選ぶ・前段に置いた配信の仕組みが効いていない原因を突き止め、オリジンの台数を減らす手を選ぶ

セキュアなアーキテクチャの設計 #3プレミアム

多数のセキュリティグループに散らばった同じ IP アドレス範囲の許可を、1 か所の更新で維持できる形にまとめる・オンプレミスからの S3 アクセスをプライベート化するときに、VPC 内の無料の経路を巻き込まない方法を選ぶ・複数アカウントの EC2 を 1 つの Active Directory ドメインへ、少ない運用で参加させる手順を選ぶ・SSE-KMS のバケットで膨らんだ AWS KMS のリクエスト料金を下げる方法を選ぶ・ブロックルールを本番へ入れる際に、正当なリクエストを落とさずに影響だけを先に測る手順を選ぶ

弾力性に優れたアーキテクチャの設計 #3プレミアム

全体には余裕があるのに一部のシャードだけが詰まる状態を解消する手を選ぶ・急ぎの依頼を先に処理するキューの構成を選ぶ・性質の違う 2 つのデータ層に、それぞれ合うデータベースを当てる・15 分以内の再開と数秒の更新損失を、余分な移行を増やさずに満たす手段を選ぶ・希望容量まで起動できない原因を切り分けて、解消する操作を選ぶ

高パフォーマンスなアーキテクチャの設計 #3プレミアム

需要に追従するために、いくつの単位をスケールさせる必要があるのかを見極める問題です・ローカルディスクの読み取り性能が要る自己管理型データベースに合う EC2 インスタンスタイプを選ぶ・稼働中の VPC のアドレス空間を、必要数から逆算したサイズで広げる・Athena が読み取る範囲を絞りつつ、パーティションの登録作業を増やさない構成を選ぶ・エッジに保持される期間の決まり方を理解し、更新の反映を早める設定を選ぶ

コストを最適化したアーキテクチャの設計 #3プレミアム

同じリージョンの 2 つの VPC をプライベートに結ぶ手段を、総額の観点で選ぶ・AWS へ入ってくる転送は原則無課金なので、比べるのは運ぶ仕組みに乗る課金と作り込みの量・EFS のライフサイクル管理で、IA へ落とす設定と Standard へ戻す設定を組み合わせる・アクセスとして数えられる操作が毎晩繰り返され、S3 Intelligent-Tiering の階層が下がらない状態を解消する・増分で保存されるバックアップの保管量を、復旧の要件を保ったまま減らす手当てを問う

セキュアなアーキテクチャの設計 #4プレミアム

EC2 上のアプリケーションが DynamoDB へ書き込むときの認証情報の持たせ方を見直す・VPC エンドポイント経由の S3 アクセスを、自社アカウントのバケットだけに絞る仕組みを選ぶ・責任共有モデルの境界を、利用者が操作できるかどうかで切り分ける・デフォルトのセキュリティグループのまま起動したインスタンス群を、停止させずにワークロード単位の許可へ移行する手順を選ぶ・入れ替えが要る認証情報と大量の設定値を、それぞれ適した保管先へ振り分ける

弾力性に優れたアーキテクチャの設計 #4プレミアム

届いた順に 1 件ずつ処理し、終わるまで保持する受け口を選ぶ・数百台で共有する作り直せる作業領域に、どのストレージとどの冗長範囲を当てるかを選ぶ・決めた時間帯に 300 台へパッチを当て、当たっていない台も把握できる仕組みを選ぶ・コンテナへ移すアプリケーション側で必要になるログ出力と終了処理の設計を選ぶ・復旧や計画メンテナンスでも共有ファイルが止まらないように、Amazon FSx for Windows File Server の構成を選ぶ

高パフォーマンスなアーキテクチャの設計 #4プレミアム

ピークが読めない Kafka の基盤で、ブローカーの台数を決めずに済む形態を選ぶ・ライターへ偏ったプロキシ経由の接続を、総数を増やさずに配分し直す方法を選ぶ・平日の朝に集中する利用に間に合うように台数を用意し、夕方以降は台数を減らす Auto Scaling の設定を選ぶ・オンプレミスのアプリケーションへの見せ方を変えずに、主となるデータの保管先を AWS 側へ移す・稼働中のシステムを止めずにブロックストレージの空き容量を増やす手順の組み合わせを選ぶ

コストを最適化したアーキテクチャの設計 #4プレミアム

付けたタグで費用を分けて見られるようにするために足りていない一手を選ぶ・ルートには HDD 系を使えないため SSD 系から選び、めったに読み出さない長期保管のデータ用に sc1 を割り当てる・費用の内訳から Aurora のストレージ構成を選び、変動する項目を請求から外せるかを問う・バケットから直接出ている配信の下りを、料金の発生する区間ごと移すための手順を選ぶ・保存と読み書きのどちらが費用の中心かを見極めて、テーブルの単価の組み合わせを選べるかを問う

セキュアなアーキテクチャの設計 #5プレミアム

組織の外のプリンシパルへアクセスを許可しているリソースを、継続的に検出する仕組みを選ぶ・インターネットから隔離したいデータベース層をどこに置き、接続元をどう絞るかを選ぶ・複数のファイルへのアクセスを会員だけに限定する方法を選ぶ・1 か所の NAT ゲートウェイに依存した外向きの経路を、アベイラビリティーゾーンごとに独立させる・サインイン済みのアプリ利用者が S3 へ直接アップロードするための認証情報の受け取り方を選ぶ

弾力性に優れたアーキテクチャの設計 #5プレミアム

36 億行から 3 列だけを使う集計の所要時間と、受付への影響を同時に解消する構成を選ぶ・初回リクエストの遅さを、追加の料金をかけずに縮める手段を選ぶ・コードを変えずに、メッセージブローカーがゾーンの障害でも止まらないようにする・1 つの NAT ゲートウェイに集まっている送信を、ゾーンの喪失に耐える形へ変える 2 つのステップを選ぶ・取引先に求める変更を接続先だけに抑えて SFTP でファイルを受け取り、Amazon S3 に保存する受け口を選ぶ

高パフォーマンスなアーキテクチャの設計 #5プレミアム

ゾーンを増やしたあと 1 つのゾーンだけ Transit Gateway 経由の通信が通らない原因を直す・常時 CPU を使い切る動画変換の所要時間が日によってばらつく原因を取り除き、安定させる方法を選ぶ・距離による遅延とデータベースへの繰り返しクエリを、それぞれ適した層のキャッシュで解消する・キューの滞留でワーカーを増減させるときに、どの指標をどの値で追うかを決める・許可リストに載せる固定の宛先と、既存のパス振り分けを同時に成立させる入口を選ぶ

コストを最適化したアーキテクチャの設計 #5プレミアム

本番の構成を複製した非本番環境から、使っていない時間と過剰な台数の費用を落とす・使われていないまま課金され続けるリソースを一覧で洗い出す手段を選ぶ・費用のしきい値をきっかけに実行まで進む仕組みかどうかで選択肢が分かれる・自動スケーリングの上限そのものを引き上げたうえで、追随の速さが足りない一括ロードには事前の手動拡張で備える・完了しなかったマルチパートアップロードのパートが残って生じる保管の料金を、運用を増やさずに自動で片付ける

セキュアなアーキテクチャの設計 #6プレミアム

ゲートウェイエンドポイントを作成したのに S3 へ届かない通信を、ネットワーク ACL で許可する宛先を選び直して通す・許可リストの SCP をルートに置いたために本番用 OU まで絞られた状態を、SCP を置く階層を直して解消する・CloudFront からオリジンまでの転送を常に暗号化するために必要な 2 つの設定を選ぶ・ボールトに別のキーを設定しても、DynamoDB のバックアップがテーブルと同じキーで暗号化される状態を直す・時間帯によって件数が跳ね上がる送信元に対し、件数が落ち着いている間は通す抑制の仕組みを選ぶ

弾力性に優れたアーキテクチャの設計 #6プレミアム

継続的バックアップの費用を、戻せる範囲を保ったまま下げる方法を選ぶ・変更できない NFS のアプリケーションを保ったまま、データの実体を AWS 側へ移す手段を選ぶ・同期の要求に紛れた時間のかかる処理を、接続を占有しない形へ切り替える・ゾーンの正常な台数の下限でレコードを切り離す Route 53 の構成を選ぶ・関数を直接つないだ処理の再試行・分岐・進行の記録を、どこに持たせるかを選ぶ

高パフォーマンスなアーキテクチャの設計 #6プレミアム

S3 上のデータセットをコピーせず読ませる学習用ファイルシステムの種類と種別を決める・携帯電話網の端末に近い場所へ処理を置く方法を選ぶ・ソースを複製元にせずに、更新が届き続ける読み取り用の DB インスタンスを 1 台増やす方法を選ぶ・月 1 回だけ動かす集計を、使わない期間の費用も成果物の消失も避けられる Amazon EMR の構成にする・同じ項目への読み取りの集中によるスロットリングを、長期的に解消する手段を選ぶ

コストを最適化したアーキテクチャの設計 #6プレミアム

分離の単位をホストに置くと使わない容量にも払い続ける。タスクごとに分離の境界を持つ実行基盤へ移す・ストレージクラスを移す日数を、見当ではなく実際の参照のされ方の観測から決める手段を選ぶ・サードパーティのアプライアンスを複数の VPC で共有するために要る 2 つの構成要素を選ぶ・1 つのパスへの過剰なリクエストだけを送信元ごとに抑え、他のパスの利用を保つ方法を選ぶ・小さなオブジェクトを 1 件ずつ書き込んでいる構成で、請求を押し上げている書き込みの回数を減らす

セキュアなアーキテクチャの設計 #7プレミアム

自宅の端末から VPC の社内システムへ、暗号化した経路で接続させる手段を選ぶ・参照パターンに合う多段ライフサイクルのストレージクラスを決める・アプリケーションが必要とする DynamoDB の操作だけを許可する IAM ポリシーを選ぶ・キーポリシーで広く与えた許可から、復号を残してキーを管理する操作だけを外す・暗号化された EBS スナップショットを別のアカウントで復元できるようにする

弾力性に優れたアーキテクチャの設計 #7プレミアム

復旧までの猶予が長い業務で、リージョン障害への備えを最も安く用意する・ほかの関数に同時実行を先に使い切られないよう、特定の関数の取り分を追加の料金なしで確保する設定を選ぶ・Aurora クラスターで、ライターが使用不能になったときに自動で処理を引き継げる構成を選ぶ・改修できない製品と新しい関数が同じデータベースの接続を奪い合う状況を解く・1 つのキューから複数のチームへ、内容に応じてイベントを配る構成の作り方を選ぶ

高パフォーマンスなアーキテクチャの設計 #7プレミアム

読み取りの量が 10 倍近くまで増える前提で、保管の料金と追加の待ち時間を抑えられる複製の作りを選ぶ・CIDR が重なる多数の顧客へ、ネットワークをつながずに API をプライベートに公開する提供側の手順を選ぶ・計算能力だけを、特定のインスタンスタイプの空きキャパシティの偏りに強い形でスポットで足せる Amazon EMR のクラスター構成を選ぶ・指定した IOPS が実測に現れない原因の層を切り分け、頭打ちを外す変更を選ぶ・データレイクの利用者とアクセス先を追える記録の残し方を選ぶ

コストを最適化したアーキテクチャの設計 #7プレミアム

1 本の専用接続のまま、3 つのアカウントの VPC すべてへ拠点から到達させる仕組みを選ぶ・性能が余っている EBS ボリュームを見つけて、止めずに費用を下げる手順を選ぶ・割引に加えて、指定したゾーンでインスタンスを起動できる保証まで要るかどうかでスコープを選ぶ・バージョニングが有効なバケットで失効を設定しても減らない保管の容量が、どのバージョンにあるのかを見極める・タグを請求で使える状態にする準備と、リソース単位・時間単位の明細を受け取る仕組みを組み合わせる

セキュアなアーキテクチャの設計 #8プレミアム

手作業で行っている新しいアカウントの作成と標準構成の適用を、承認済みの構成で自動的にプロビジョニングできる仕組みへ置き換える・キーマテリアルの保有と暗号処理の場所に関する規制要件を満たす鍵の基盤を選ぶ・アプリの利用者自身のサインアップとサインインを、自前で作らずに用意する・終わりの時期が読めない係争の間だけ書類を守り、終わったらすぐ戻すための 2 つのステップを選ぶ・1 本の専用接続で、増え続ける多数の VPC へ届く経路を最小限の運用で用意する

弾力性に優れたアーキテクチャの設計 #8プレミアム

読み取りが飽和した Aurora クラスターで、増やすべきスケール単位を選ぶ・GPU が要るうえに中断しても投入し直せるバッチ処理を最も安く回す構成を選ぶ・作り直せる派生データを、待たずに読み出せるまま最も安く保存できるクラスを選ぶ・不要なフェイルオーバーを避けながら、実際の喪失では短時間で切り替えを終える運用を組む・短時間で終わる大量のワークフローの費用を抑える方法を選ぶ

高パフォーマンスなアーキテクチャの設計 #8プレミアム

割り当てた 1 台へ確実に届けつつ、遠方の参加者の経路も改善する構成を選ぶ・呼び出しの粒度を決めている 2 つの設定を両方そろえる問題です・送信側のアプリケーションを改修せず、必要なトピックだけを別リージョンへ届ける方法を選ぶ・キャッシュが効かない読み取りの速さを、テーブル側の設計で改善する・SaaS で作成されたレコードを短い待ち時間で分析基盤へ届けるための、フローの起動の仕方を選ぶ

コストを最適化したアーキテクチャの設計 #8プレミアム

継続的に大量のデータを送り出す経路を、転送の課金と経路の安定性の両面から選び直す・数分間だけ跳ね上がる書き込みを、常時の容量を増やさずに受け止める構成を選ぶ・年に数回しか読まない EFS のファイルを、読み出しの頻度に合う最も単価の低いストレージクラスへ移す・NAT インスタンスからマネージドの出口へ、通信を止めずに切り替える 2 つの手順を選ぶ・月内で保存量が大きく上下する共有ファイルは、容量を確保する型から、置いた量に課金される EFS へ移す

セキュアなアーキテクチャの設計 #9プレミアム

締め出された唯一の管理者の権限を復旧し、バックアップスクリプトが使う長期的な認証情報をなくすための手順を選ぶ・キューのメッセージを保管時に暗号化し、キーの扱いと証跡の要件も満たす構成を選ぶ・維持しなければならない経路を残したまま、内容の検査を関連付けられる入口をどこに用意するかを決める・キー ID と既存のデータを保ったまま、暗号化キーのキーマテリアルを定期的に切り替える方法を選ぶ・全員が同じ権限を使う大人数に対して、見直した内容を自社で決めて一度に反映できる権限の配り方を選ぶ

弾力性に優れたアーキテクチャの設計 #9プレミアム

1 台のディスクに溜まる受け取り済みの画像と処理待ちの一覧を、ゾーンの喪失に耐える置き場へ移す・項目の変更を履歴として別の場所へ残す仕組みを選ぶ・複製先にも渡ってしまった誤った書き込みを、失う更新を最小にして戻す・計算だけで時間がかかっている関数の実行時間を、最小の変更で縮める手段を選ぶ・既存のアプリケーションの接続方式を保ち、ブローカーの運用も抱えない移行先を選ぶ

高パフォーマンスなアーキテクチャの設計 #9プレミアム

Redshift を宛先にした Firehose の配信を成立させるために、経路の途中と取り込みで必要になる 2 つの設定を選ぶ・稼働中のテーブルに別の属性での検索を足す方法を選ぶ・大量のログを順に読み出す速さを、いちばん安く確保できるボリュームタイプを選ぶ・鮮度・空のノードでの欠落・使われない項目の滞留という 3 つの要求を同時に満たすキャッシュ戦略を組み立てる・標準 SQL のクエリだけで足りる分析を、実行する環境を用意も管理もせずに始める方法を選ぶ

コストを最適化したアーキテクチャの設計 #9プレミアム

SMB と Active Directory の前提を保てるファイルストレージを選び、確保した量で決まる課金を要件ちょうどに合わせる・移すのがデータではなくサーバーそのものなので、OS ごと複製できる手段を選ぶ・入口を変えずに、待ち受けの時間に対する課金だけをなくせる構成を選ぶ・Savings Plans の割引が届かない課金項目を見分け、料金の発生条件そのものを外す・HTTP ではない張ったままの接続を、AWS のネットワークに乗せて最寄りのリージョンへ届ける仕組みを選ぶ

セキュアなアーキテクチャの設計 #10プレミアム

組織の全アカウントで構成基準の反映漏れと是正の遅れを同時に解消する方式を選ぶ・キーの利用記録と自社によるアクセス制御を、最小限の運用で両立する S3 の暗号化方式を選ぶ・管理者自身も解除できない保持をバックアップに強制する方法を選ぶ・外向きの送信先をドメイン名で限定する仕組みを、最小限の運用で用意する・多数の企業を顧客に持つサードパーティへ、自社アカウントの読み取りアクセスを安全に委任する方法を選ぶ

弾力性に優れたアーキテクチャの設計 #10プレミアム

コンテナを載せるサーバーの保守に人手を割けない体制で、業務システムをコンテナで動かす・障害の原因が自社側か AWS 側かを切り分ける根拠の入手先を選ぶ・オリジンのウェブサーバーの障害時に、人の操作なしで複製から配信する設定を選ぶ・月末の締め処理が始まる時点で、必要な台数をそろえる 2 つの設定を選ぶ・デプロイのたびに数時間遅くなる状態を、停止も DNS の切り替えもせずに解消する方法を選ぶ

高パフォーマンスなアーキテクチャの設計 #10プレミアム

クエリの条件が変わり続ける業務データを、どの種別のデータベースに置くかを選ぶ・CSV で届くストリーミングデータを、取り込みの途中で列指向の形式に変換する構成を選ぶ・1 項目に収まらない大きなデータの持たせ方を選ぶ・ファイルとデータベースという性質の違う 2 つの資産を、それぞれに適した移行の手段で AWS へ移す・処理能力に上限のある後段を急増から守るために、どの層で流量を抑えるかを選ぶ

コストを最適化したアーキテクチャの設計 #10プレミアム

期間あたりの呼び出し回数を契約どおりに止められる仕組みを選ぶ・パスで呼び分けられる複数のサービスを、何台のロードバランサーでホストできるかを問う・使わない期間のデータだけを、稼働する実体を残さずに最も安く保持する・移行が終わっても費用が下がらないときに、どこに残っている課金を止めるかを問う・停止中も発生し続ける EBS ボリュームの容量への課金を、中身を残したまま止める

セキュアなアーキテクチャの設計 #11プレミアム

上限を固定したロールで、アクセス許可ポリシーにある操作が拒否される原因を突き止め、上限だけを必要な範囲で広げる・キーの管理はできるのに SSE-KMS の書き込みだけが失敗する原因を、キーポリシーの区分から見つける・ポリシーの編集権限を残したままパブリック公開だけを封じる方法を選ぶ・AWS のデータセンターの統制について、監査法人へ提出する SOC 2 レポートを用意する方法を選ぶ・同じアドレス範囲のうち 1 台だけを通して残りを止めるように、ネットワーク ACL に追加するルールの番号を決める

弾力性に優れたアーキテクチャの設計 #11プレミアム

手元に残すコンテナとクラウドのコンテナを同じ仕組みで管理し同じイメージを配る構成を選ぶ・急な立ち上がりに追従できないスケーリングの方式を、運用を増やさずに置き換える・誤った更新の直前へ、数分以内のずれで戻せる備えを選ぶ・取引先ごとに違う呼び出し回数の上限を課せる API の構成を選ぶ・順序を保つトピックに、順序を必要としない 2 つの宛先を足す構成を選ぶ

高パフォーマンスなアーキテクチャの設計 #11プレミアム

期限と回線の帯域から、大量データの移行にオフライン輸送とオンライン転送をどう組み合わせるかを決める・gRPC だけを公開するマイクロサービスへ、Application Load Balancer 経由で呼び出しを届ける設定を選ぶ・重い参照クエリを基幹システムから切り離し、直近の内容を見せ続ける読み取り先をどう用意するかを選ぶ・件数と容量が桁違いに増え続けるデータについて、容量の作業が発生しない保管先と置き方を選ぶ・量も時刻も見積もれない山谷に、設定を見直さずに追従できるスループットの決め方を選ぶ

コストを最適化したアーキテクチャの設計 #11プレミアム

移行の完了には、データを運び込む手当てと、移行後も同じパスで使い続ける手当ての両方が要る・必要な帯域と、1 か所の障害への耐性を同時に満たす専用接続の敷き方を決める・保持する期間と、選んだストレージクラスの最低保管期間が合っていない状態を正す・読み書きが費用の中心で、その量が予測できるテーブルの単価をどう下げるかを問う・オンプレミス宛の通信の送信元アドレスを少数にまとめる出口を選ぶ

セキュアなアーキテクチャの設計 #12プレミアム

承認していないサービスを、今後追加されるものも含めて OU 単位で使えない状態にする統制の作り方を選ぶ・ACM の証明書を、担当者が関与しなくても更新され続ける状態にする方法を選ぶ・接続先の設定を変えずに、AWS サービスへの通信を VPC の中で完結する経路へ切り替える・本番アカウントのバックアップを、同じ組織の別のアカウントへ少ない手間でコピーして残す方法を選ぶ・ピアリングで結んだ 2 つの VPC のうち、出口を持たない側から、受信を開かず運用の手間も抑えて外部の API を呼び出す方法を選ぶ

弾力性に優れたアーキテクチャの設計 #12プレミアム

Amazon SNS の購読者ごとに不要なイベントの配信を止めて、受信と呼び出しの料金を下げる方法を選ぶ・長時間かかる処理を、待機時間の課金と基盤の保守を増やさずに実行する方式を選ぶ・予約ごとに指定された日時へ 1 回だけ処理を起動する仕組みを選ぶ・北米で参照と更新を同じ接続先から行い、リージョン障害にも備える 2 つのステップを選ぶ・リージョン障害に備える構成を、復旧の目標と切り替えの手順から選ぶ

高パフォーマンスなアーキテクチャの設計 #12プレミアム

増減の往復を抑えたいが増やす側は速いままにしたい、という要求に対して、どちら側の待ち時間を触るのかを問う問題です・伸び方が見通せない新しいテーブルで、キャパシティをどう用意するかを選ぶ・集計を移したリードレプリカで I/O が上限に達したまま伸びない原因を取り除き、本番に手を入れずに所要時間を縮める・実行の途中から性能が落ちるブロックストレージについて、費用を抑えて必要な性能を常時確保する構成を選ぶ・1 本の VPN の帯域を超えるために、接続を増やして束ねる

コストを最適化したアーキテクチャの設計 #12プレミアム

使わない時間の課金を止めつつ、メモリに読み込んだ状態を保って再開する方法を選ぶ・ソケット単位で数えるライセンスを持ち込むには、物理サーバーのソケット数とコア数が見える配置が要る・2 つの要件を保ったまま、リージョンをまたぐバックアップの保管量を減らす設計を問う・特定の API と関数にだけ効く上限を、層を選んで 2 か所に置く・性能のためにサイズを過大に確保しているブロックストレージを、必要な IOPS を保ったまま実データに見合う容量へ縮める

セキュアなアーキテクチャの設計 #13プレミアム

インターネット経由の VPN で不安定な転送を、暗号化を保ったまま安定させる・リソースベースのポリシーで欠けている必須の要素を見つける・IA へ移すルールがあっても下がらない、1 件数十 KB のログのストレージコストを下げる・S3 全体から機密データを含むバケットを、手間をかけずに継続して把握する・暗号化されたオブジェクトを別アカウントへ読ませるために、リソース側で足りない 2 つの許可を補う

弾力性に優れたアーキテクチャの設計 #13プレミアム

失われる更新の量と再開までの時間の両方を満たす別リージョンの構成を選ぶ・文章での質問に対して答えの箇所を返せる検索の仕組みを選ぶ・改修できないアプリケーションが動くサーバー 60 台を、業務を数分だけ止めて AWS へ移す・配信に失敗した EventBridge のイベントを失わないための対策を選ぶ・1 MiB を超える本体の運び方と、空の応答が返る呼び出しの料金を抑える設定を選ぶ

高パフォーマンスなアーキテクチャの設計 #13プレミアム

配信されるファイルを大きくしつつ、PUT リクエストの料金を増やさないバッファの設定を選ぶ・停止と起動をまたいで出力が消える原因を踏まえ、同じパスから読み直せる置き場へ移す・スキャン量を下げるために、既存の CSV テーブルをクラスターなしで列指向へ作り替える・業務データのダッシュボードを作り、そのまま自社アプリの画面に組み込める可視化サービスを選ぶ・同じクラスター配置のまま、毎回 40 台をそろえて起動する

コストを最適化したアーキテクチャの設計 #13プレミアム

Aurora でインスタンスを増やしたときに、どの料金が増えてどの料金が増えないかを切り分ける・今のデータ量と将来の増え方から、データウェアハウスのノードタイプと保存の形を決められるかを問う・既存のバックアップソフトウェアの設定と手順を変えずに、書き出し先の物理テープ装置だけを AWS へ置き換える・ゾーンをまたぐ内部通信で膨らむデータ転送の費用を、経路の設計で抑える・ワークロードごとに支配的なリソースを見極め、そのリソースに厚いインスタンスファミリーを選ぶ

セキュアなアーキテクチャの設計 #14プレミアム

自前で運用しているディレクトリの運用負担を下げる移し先を選ぶ・暗号化されていない DB インスタンスから、暗号化された複製を別のリージョンへ用意する経路を選ぶ・EC2 起動タイプの Amazon ECS で動くアプリケーションに、AWS API を呼ぶための許可を最も安全に与える方法を選ぶ・Client VPN で端末から VPC 内のリソースへ到達させるために必要な設定をそろえる・別アカウントからアップロードされる S3 オブジェクトを、バケット所有者のポリシーだけで制御できるようにする設定を選ぶ

弾力性に優れたアーキテクチャの設計 #14プレミアム

宛先の IP アドレスを固定したまま、インスタンスの増減と置き換えに追随できる構成を選ぶ・ゾーンが失われても、同じリージョンの別のゾーンで記録を戻せるバックアップの置き場を選ぶ・切り替えの直後から処理を受けられる構成を、平常時の費用を抑えて選ぶ・サービスごとに健全性を判定し独立して増減させるために必要な 2 つのステップを選ぶ・SFTP で受け取ったファイルへの復号・スキャン・タグ付けを、保守するものを増やさずに転送のたび自動実行する

高パフォーマンスなアーキテクチャの設計 #14プレミアム

UDP のリアルタイム通信を 1 つの入口で受け、台数の増減に追従させる構成を選ぶ・検証環境の設定のままの DB インスタンスを本番向けにするために必要な 2 つの変更を選ぶ・1 つのテーブルを共有したまま、チームごとに参照できる行を変える仕組みを選ぶ・ストリームのデータへ SQL を当てられる時点と、保持と分岐のしかたを選ぶ・Dashboards のサインインを社内の認証情報で行える構成のうち、維持する対象が最も少ないものを選ぶ

コストを最適化したアーキテクチャの設計 #14プレミアム

VPC の中では効いているエンドポイントが、オンプレミスからの通信では効かない理由を特定して直す・同じ内容を別リージョンに読める形で持ち続けるなら、追加のたびに S3 の側が複製する仕組みに寄せる・NAT ゲートウェイの費用がどちらの料金で膨らんでいるかを量から見抜き、効く手を選ぶ・保管の費用は自社に残したまま、リクエストとダウンロードの費用だけを取得する側の AWS アカウントへ移す・移行の途中でレプリケーションインスタンスのストレージが尽きたときの復帰手段を問う

セキュアなアーキテクチャの設計 #15プレミアム

apex ドメインでだけ証明書の警告が出る原因を取り除く方法を選ぶ・取引先に期間限定で S3 オブジェクトを渡す手段を選ぶ・複数アカウント・複数リージョンの CIS 準拠を一元評価する構成を選ぶ・自社運用 DB の認証情報を安全に保管し自動ローテーションする手段を選ぶ・他部門が所有するキーで、請求処理を止めずに特定のロールの復号をすぐ止める方法を選ぶ

弾力性に優れたアーキテクチャの設計 #15プレミアム

新しいバージョンを一部の利用者で確かめながら本番へ寄せる方法を選ぶ・既存の Kubernetes の資産と運用手順をそのまま使えるコンテナ実行環境を選ぶ・稼働中の 20 台へ新しい AMI を、処理を止めずに行き渡らせる 2 つのステップを選ぶ・VPC へ接続した Lambda 関数が、ゾーンの障害の間だけ VPC の中のデータベースへ届かなくなる原因を取り除く・関数の応答の上限を超える結果を、バケットを公開せずに利用者へ届ける受け渡し方を選ぶ

高パフォーマンスなアーキテクチャの設計 #15プレミアム

S3 では通っている経路がキューには通らない理由を突き止め、外向きの出口を作らずに到達させる・稼働中のテーブルに新しい引き方の画面を足すとき、インデックスに何を用意するかを決める・Windows と Linux が同じディレクトリを共有できるファイルストレージを選ぶ・確定直後だけ最新が必要な読み取りと、切り替えの後に書き換えの要らない接続先を、Aurora のエンドポイントの選び方で両立させる・S3 に貯まるファイルを、テーブル定義の手作業なしで SQL 分析できるようにする構成を選ぶ

コストを最適化したアーキテクチャの設計 #15プレミアム

オブジェクトとして見えない課金の所在を、組織を横断してバケット単位まで特定する・商用エンジンのライセンス費そのものを払わずに済む構成はどれかを問う・書き込みの重さと読み出しの頻度が違うデータを、期間で分けてどこに置くかを問う・3 年間動かないものだけを固定して割引を最大化しつつ、これから変わる OS には割引を追従させる・処理が間欠的で待ち時間が大半なら、呼び出されたときだけ課金されるコンピューティングを選ぶ

セキュアなアーキテクチャの設計 #16プレミアム

S3 のイベント通知が SQS キューへ届くようにするために、許可をどこへ書くかを選ぶ・取引先のシステムごとに許可した操作の範囲に応じて、API のエンドポイントごとの呼び出しを認可する仕組みを選ぶ・RDS のデータベース本体とその派生リソースをまとめて保管時に暗号化する方法を選ぶ・組織の全メンバーアカウントで、暗号化されていない EBS ボリュームの作成を止め、すでにあるものを一覧にする手段の組み合わせを選ぶ・サブネットに追加したネットワーク ACL で応答が返らなくなった原因を突き止め、正しい向きとポート範囲で許可する

弾力性に優れたアーキテクチャの設計 #16プレミアム

同じリソース一式を 12 アカウント × 3 リージョンへ 1 回の操作で作り、更新も 1 回で全対象へ届ける方法を選ぶ・送信の送り直しで生まれる重複を、キューの機能で止める方法を選ぶ・台数を増減させても操作が途切れないように、利用者の状態の置き場を決める・SMB の使い勝手を保ったまま検査記録の保管先を移し、開かれない画像の費用を下げる・可視性タイムアウトの上限を超える長時間処理で、二重の処理を運用の負担少なく止める設計を選ぶ

高パフォーマンスなアーキテクチャの設計 #16プレミアム

元のままの値をデータストアに置かず、しかも待たされずに参照できるようにする変換の置き方を選ぶ・1 つの商品だけがスロットリングする原因を突き止め、上限に収める方法を選ぶ・決済端末から届く大量の記録を、端末ごとの順序を保ったまま処理する受け口を選ぶ・データベースからの差分取り込みと、第三者データセットの受け取り方をそれぞれ選ぶ・すでに 2 本のピアリングがある 3 つの VPC で、残りの 1 組を通信させる方法を決める

コストを最適化したアーキテクチャの設計 #16プレミアム

取りすぎた RDS の割り当てストレージは減らせないので、小さい割り当ての DB インスタンスを作って移す・複数台に分けられない処理の容量を、コストを抑えながら増やす方式を選ぶ・アーカイブクラスに置いた図面を、参照先を変えずに待ち時間なく読める状態へ恒久的に戻す手順を選ぶ・複数アカウントのバックアップの保持と費用の管理を 1 か所へ集める手順を問う・スポットの中断に先回りするなら、確定後の 2 分前通知ではなく、リスクが高まった時点で出る再調整の推奨事項を起点にする

セキュアなアーキテクチャの設計 #17プレミアム

暗号化と読み取りの制御を備えたパスワードの保管先を選ぶ・リージョンで今後作られる EBS ボリュームを一律に暗号化させる方法を選ぶ・非公開の S3 バケットに置いた SSE-KMS のオブジェクトを CloudFront から配信するために必要な許可を選ぶ・オンプレミスの利用者アカウントのまま、マネージドの SQL Server で Windows 認証を成立させる構成を選ぶ・本社の社内システムから、VPN 経由で VPC 内の業務アプリケーションへ接続できるようにする

弾力性に優れたアーキテクチャの設計 #17プレミアム

自前運用の Cassandra クラスターを、CQL のクエリが変わらず台数の管理も残らない移行先に寄せる・スケールインで終了するインスタンスの作業ファイルを、終了前に確実に退避する方法を選ぶ・四半期末の状態を 1 年間残し、業務を止めずにその時点を参照できるようにする・障害の最中でも成立する切り替えの仕組みへ、手順を作り替える・集計の元になった生のレコードを、あとから取り出せる期間を確保する方法を選ぶ

高パフォーマンスなアーキテクチャの設計 #17プレミアム

参照が偏る DynamoDB の読み取りを一桁下の応答時間にするために、どのキャッシュを前に置くかを決める・Lambda 関数の書き出しが容量不足で失敗するとき、最小限の運用上のオーバーヘッドで書き出せる領域を広げる手段を選ぶ・キャッシュに載せられる量が足りなくなったとき、どの方向へ伸ばすかを選ぶ・複数ゾーンに分散した状態保持型のアプライアンスへ、往復の通信を同じ機器に着地させる設定を選ぶ・大きなオブジェクトのアップロードと読み出しにかかる時間を、転送の分割で短くする

セキュアなアーキテクチャの設計 #18プレミアム

プライベートサブネットのウェブサーバーへ、社内からだけ SSH できる入口を設計する・RDS のマスターユーザーのパスワードを、運用の手間をかけずに暗号化して保管し、ローテーションする方法を選ぶ・アカウントをまたいで EC2 のタグを付与する Lambda 関数に、長期のキーを持たせずアクセスを成立させる設定を選ぶ・追加されるリソースを取りこぼさず、削除後もバックアップを 3 年残す方法を選ぶ・組織の全アカウントへ職務別のアクセスを付与しつつ、社内 ID プロバイダーとの接続点を最小にする仕組みを選ぶ

弾力性に優れたアーキテクチャの設計 #18プレミアム

多段の呼び出しのうち、どの区間で時間がかかっているかを特定する手段を選ぶ・自分たちで導入したデータベースを、手作業を減らしながらゾーンの障害に短時間で耐える形へ移す・1 つのゾーンに閉じた 2 台構成を、台とデータの両面でゾーンの喪失に耐える構成へ変える・デフォルトの終了ポリシーで、スケールイン時に終了するインスタンスの決まり方を答える・クライアントが必要な項目を指定して取得できる API の構成を選ぶ

高パフォーマンスなアーキテクチャの設計 #18プレミアム

エンジンの異なるデータベースへ、業務ロジックを保ったまま数分の停止で移すために必要な 2 つのステップを選ぶ・オブジェクトのアップロードを合図に処理を起動する構成を選ぶ・稼働する日が限られた共有ファイルストレージで、必要なスループットと運用の手間の釣り合いを取る・要求リソースがばらばらな数千件のコンテナジョブを、依存関係を保ちながら運用の手間なく実行する仕組みを選ぶ・クリックを、直後に読む処理と S3 の分析基盤の両方へ流す取り込みと配送の構成を選ぶ

セキュアなアーキテクチャの設計 #19プレミアム

追跡と無効化の要件を満たす AWS KMS のキーの種類を選ぶ・既存のオンプレミス Active Directory を AWS から使うための接続方式を選ぶ・増え続けるアカウント全体へ、同じ保持期間のバックアップを設定の追加なしで行き渡らせる・メンバーアカウントの管理者が解除できない形で、承認外のリージョンでの操作を組織全体で禁止する方法を選ぶ・複数の VPC のインターネット向け通信を、Transit Gateway 経由で出口用の VPC 1 つから出すための 2 つのステップを選ぶ

弾力性に優れたアーキテクチャの設計 #19プレミアム

外形の応答では分からない不調を、振り分けの判断へ持ち込む・Fargate へ移したサービスがロードバランサーに登録できない状況を解消する方法を選ぶ・処理待ちの量を表さない指標で増減していた構成を、滞留に追従する指標へ替える・改修できないアプリケーションのために、データベースの切り替えで接続が切れないようにする・プライマリ 1 台の ElastiCache クラスターで、ゾーン障害から数秒で復帰させる 2 つの設定を選ぶ

高パフォーマンスなアーキテクチャの設計 #19プレミアム

キーで引く読み書きと、語で引く全文検索を、どのデータストアに割り当てるかを決める・1 台の Transit Gateway で、開発と本番を分離しながら共有サービスにだけ双方から到達させる構成を決める・同時に落ちたノードの影響範囲を配置で分ける・値が発行されない区間にも判定の材料を用意して、評価を続けさせる手を選ぶ問題です・特性の違う 2 つの Lambda 関数のメモリ設定を、速さと料金の両面から根拠をもって決め直す

セキュアなアーキテクチャの設計 #20プレミアム

復号する場所をインスタンスに限りながら分散とヘルスチェックを行う構成を選ぶ・複数のポリシーで許可が足し合わされているロールから、特定のタグを持つインスタンスの終了だけを止める・S3 バケットへのアクセスを特定の VPC エンドポイント経由だけに閉じ込める構成を組み立てる・別リージョンへの複製に時間の上限を持たせる方法を選ぶ・複数のアカウントで作業する担当者の IAM ユーザーを 1 つにし、サインインしたまま他のアカウントも操作できるようにする

弾力性に優れたアーキテクチャの設計 #20プレミアム

固有の語彙を含む長文の文書を音声化する仕組みを選ぶ・ソース側の削除が複製先まで届く状態を、複製先が残るように変える・部分更新する作業領域と HTTP で直接配る配信先で、ストレージの種類を使い分ける・ロードバランサーが異常と判定したインスタンスを Auto Scaling グループに自動で置き換えさせる方法を選ぶ・同じ項目が複数のリージョンで同時に更新される設計を、引き当てが消えない形にする

セキュアなアーキテクチャの設計 #21プレミアム

SCP で止まらない起動の経路を見極め、サービスの設定側で止める・配信を止めずに OAI から OAC へ切り替える手順を選ぶ・規程が定めるローテーション周期に合わせるために、キーの種類と周期の設定をどう変えるかを選ぶ・拠点側の機器障害で切れた VPN 接続を、通信が継続する構成へ改める・同じドメイン名を複数リージョンのロードバランサーで HTTPS 提供するときの証明書の用意のしかたを選ぶ

弾力性に優れたアーキテクチャの設計 #21プレミアム

耐久性の桁とゾーンの喪失への耐性を切り分け、保持されるゾーンの数を増やす・参照の切り離しと確定済み更新の保護を同時に満たす Amazon RDS の構成を選ぶ・バックアップからの復旧が目標時間を超えている原因に、直接効く準備を選ぶ・インスタンスの中の設定を全台で同じ内容に保ち、書き換えられても戻る仕組みを選ぶ・自社で構築した Apache Kafka のメッセージ配信基盤を、担当者の復旧作業なしにブローカーの喪失へ耐えさせる

セキュアなアーキテクチャの設計 #22プレミアム

規格の統制項目に対する適合状況を継続的に判定する仕組みとして、どのサービスを推奨するかを選ぶ・S3 バケットへの HTTP のリクエストを拒否するバケットポリシーに足りない要素を見つける・既存と新規の両方のオブジェクトを SSE-KMS へ切り替えるために必要なステップを選ぶ・台数が変動する層からの接続を、ルールの書き換えなしに限定できる送信元の指定方法を選ぶ・共有サービスアカウントのサブネットを、増え続ける事業部アカウントへ手作業なしに使わせる方法を選ぶ

セキュアなアーキテクチャの設計 #23プレミアム

NAT ゲートウェイのデータ処理料金が乗っている S3 宛の通信を、課金されない経路へ振り替える・アクセスキーによる API 呼び出しにも第 2 要素を要求する仕組みを選ぶ・非対称 KMS キーを毎年入れ替えつつ、過去の署名の検証も続ける手順を選ぶ・ピアリング接続を作ったあとに通信を流すための手順を選ぶ・ブロックパブリックアクセスの有効化で止まったクロスアカウントの読み取りを、公開に戻さずに復旧させる

セキュアなアーキテクチャの設計 #24プレミアム

社内だけで信頼されればよい証明書を、サーバー上で終端したまま手作業を増やさずに配る・S3 に保管するオブジェクトへ多層のサーバー側暗号化を適用できる方式を選ぶ・カスタマーマネージドキーで暗号化したオブジェクトを、今後追加されるロールからも復号できるようにする・ログ基盤を先に用意せずに、API 呼び出しの異常と通信先の異常を検出する・公開中の S3 バケットを CloudFront 経由だけに絞る 2 つのステップを選ぶ

セクション別問題一覧へ