SAA-231-240

【SAP-231】あるIT系SaaS企業はリアルタイム分析サービスを顧客に提供しており、マーケティング施策の影響で負荷が月ごとに大きく変動している。
システムは Auto Scaling を前提に Amazon EC2、AWS Fargate、AWS Lambda で構築し、複数アカウントを AWS Organizations で一元管理している。
運用担当は少人数のため、インスタンスタイプやリージョン単位で予約を細かく最適化する作業は現実的ではない。
経営層はキャッシュフローを安定させるため、向こう 3 年間のコンピューティング費用を平準化したいと考え、ソリューションアーキテクトに対して過去 6 か月間の各アカウント平均使用量を基に全ワークロードのコスト最適化プランを策定するよう求めている。
EC2 だけでなく Fargate や Lambda も割引対象とし、需要の急増にも自動的に追随しながら最大の割引率を享受できる仕組みが条件となる。
ソリューションアーキテクトは組織全体のコスト削減を実現するために、どの選択肢を採用すべきか？

【SAP-232】ある金融サービス企業は、決済取引を担うオンプレミスの Java アプリケーションと 5 TB の MySQL データベースを、段階的に AWS へ移行して Amazon RDS for MySQL を本番とする計画を進めている。
利用者はブラウザやスマートフォンから残高照会や即時送金を行うため、昼夜を問わず更新系トラフィックが発生している。
金融当局のガイドラインにより「インターネットを経由しない通信経路の確保」と「転送中・保存中の完全な暗号化」が義務付けられており、サービス停止は決済締め時間帯を除く数十 分以内に抑えるよう経営層から求められている。
同社はすでに KMS 暗号化を有効化した RDS インスタンスを用意し、1 Gbps の AWS Direct Connect 回線でパブリック／プライベート VIF を確立している。
オンプレミス側の夜間オペレーション要員は最低限にとどまり、運用負荷を増やさずスケーラブルに移行作業を完結させる必要がある。
以上の制約とビジネス背景を踏まえ、ソリューションアーキテクトはダウンタイムを極小化しつつ規制要件を満たす移行戦略をインフラ設計レベルで選定しなければならない。
どの構成を採用すべきか？

【SAP-233】あるオンライン予約プラットフォームを運営する会社では、顧客が Web やモバイルからリアルタイムに空席検索・決済を行えるよう Amazon ECS 上のマイクロサービスを Amazon API Gateway で公開している。
予約情報と決済履歴は Amazon Aurora と Amazon DynamoDB に保存し、インフラは AWS CloudFormation、デプロイは AWS CodePipeline で自動化している。
経営陣は「リージョン全停止時でもデータ損失 2 時間 (RPO)・復旧 4 時間 (RTO) を保証しつつ平常コストは最小に」と要請しており、運用部門は 24 時間体制だが二次リージョンに常時稼働する高額リソースを置く予算がない。
ビジネス的には短時間で予約受付を再開できれば機会損失を抑えられ、技術的にはアプリケーション層を CloudFormation テンプレートから迅速に再構築できることが前提となる。
ソリューションアーキテクトは DR 戦略としてどの構成を採用すべきか。
最もコスト効率よく要件を満たす選択肢はどれか？

【SAP-234】ある人材派遣会社では、全国の派遣スタッフがスマートフォンから毎週タイムシートを提出できるモバイルアプリを提供している。
入力はほぼ金曜終業後に集中し、平日はアクセスが少ない。
タイムシートは API 経由で受け付け、保存されたデータを基に給与担当者が月次で SQL 形式の集計レポートを実行できる必要がある。
提出受付は 24 時間 365 日停止できず、アクセス急増時にも遅延なく自動的にスケールする高可用インフラが前提となる。
IT 部門は少人数のため、サーバ管理やパッチ適用の工数を極小化することが経営の意思決定として重視されている。
また、法定保存期間を満たす高耐久ストレージとバックアップの自動化が必須である。
ソリューションアーキテクトは、インフラ変更を伴わずスケーラブルな受付基盤を保ちつつ、レポーティングに適したデータ形式を維持する構成を検討している。
運用オーバーヘッドを最小化しながらこれらのビジネス背景と技術要件を同時に満たせる AWS のサービスおよび手順の組合せとして妥当なのはどの選択肢か。
二つ選びなさい。

【SAP-235】あるECサイト運営企業は、世界中の顧客にWebカタログ閲覧と購入機能を提供するフロントエンドを、Application Load Balancer（ALB）の背後に配置したAuto Scalingグループ内の複数のAmazon EC2インスタンスで稼働させている。
ユーザーはブラウザやモバイルアプリからHTTPSでアクセスし、システムは需要の増減に応じて自動でEC2台数を調整する運用方針を採用している。
内部統制部門は、不正注文の兆候を早期に検知し監査証跡を長期保存するため、アプリケーションへのすべてのアクセス試行を網羅的に収集し、クライアントのIPアドレス、接続タイプ、ユーザーエージェントを含めて分析基盤へ連携する新しいポリシーを策定した。
ビジネス上、これによりセキュリティインシデント対応の迅速化とコンプライアンス遵守を図る考えである。
技術面では、スケーラブルにログを取得できること、既存EC2へ追加エージェントを導入せず運用負荷を増やさないことが必須要件となっている。
ソリューションアーキテクトは、上記の制約下で監査ログ要件を満たすため、インフラレイヤでどの機能／構成を採用すべきか。
最も適切な選択肢はどれか？

【SAP-236】あるオンライン広告配信サービスを展開する企業では、レイテンシに厳しいリアルタイム入札エンジンを AWS 上で運用しています。
ユーザーは広告枠表示のたびにミリ秒単位の応答を受けており、遅延は直収益に直結するため経営層からネットワーク待ち時間のさらなる短縮が強く求められています。
現在、Amazon EC2 インスタンス上にプライマリ 1 台とワーカー 8 台から成る分散型インメモリデータベースクラスタを構築し、プライマリがヘルスチェックとリクエスト集約、ワーカーがデータ複製を担当しています。
将来的なスループット向上のため水平スケールが前提となる一方、運用チームは小規模で追加ミドルウェアの導入は避けたい状況です。
ビジネス上の狙いは「全ノード間の往復遅延を最小化し広告応答率を維持する」ことであり、技術的には「インスタンス間通信を同一 AZ 内で可能な限り近接させる」ことが必須条件となります。
ソリューションアーキテクトはインフラレベルでどの構成を採用すべきか？

【SAP-237】世界中の大学生向けに講義動画や課題管理機能を提供する SaaS 形式の教育プラットフォームが、ALB 配下の Auto Scaling グループ上に展開した Amazon ECS クラスターで稼働している。
学期末には利用が急増するため水平スケーリングで可用性を担保しているが、最近毎週約500のユニーク IP から大量のログイン失敗が発生し、認証サービスのレスポンスが劣化している。
ビジネス部門は「正規学生の学習体験を損なわないこと」を重視し、運用部門は「手作業による IP ブロックやインスタンス増設に依存しない自動防御」を求めている。
したがって、アプリケーション改修を伴わず、維持運用を簡素化しながら不正リクエストのみを精査・遮断できる仕組みを導入する必要がある。
ソリューションアーキテクトは、インフラレベルで不要なトラフィックを検出しつつ世界各地の正規ユーザーには影響を与えない構成を選定すべきだが、運用効率と要件をともに満たす最適な AWS サービス／機能の選択肢はどれか？

【SAP-238】航空機の軌跡データを提供する情報配信会社では、ユーザーがブラウザやモバイルアプリからリアルタイムで便名を検索し、現在位置を地図上に確認できる SaaS 型サービスを運営している。
システム構成は、単一アベイラビリティゾーンに置かれた大型 Amazon EC2 インスタンス 2 台を Application Load Balancer で分散し、DNS は Amazon Route 53 で ALB に向けている。
フライトデータおよび顧客設定は 1 台構成の Amazon RDS for MySQL に保存するのみで、運用は開発チームが兼務しているため人員的にもスケジュール的にも保守余力が乏しい。
今後、航空会社との新規契約により「年 99.9% 以上のサービス可用性」を保証する SLA が義務づけられ、障害発生時の違約金を回避するために冗長化と自動復旧の強化が急務となっている。
こうしたビジネス要件を満たしつつ、パッチ適用やフェイルオーバーを極力自動化して運用負荷を最小化するために、ソリューションアーキテクトはインフラ設計の観点からどの構成変更と AWS サービスの採用を行うべきか。
最も適切なアクションの組み合わせはどれか。

【SAP-239】ある総合物流企業では、配送最適化アルゴリズムを実行する EC2 ベースの集中型サービスを開発し、中央 IT 部門が管理する共有 VPC に配置している。
利用部門は最大 10 個の独立した VPC にクライアントアプリケーションを持ち、このサービスの REST API を呼び出して配送ルートを即時に取得している。
フロントエンドは高負荷に備えて Network Load Balancer でスケールアウトしている。
直近の経営会議で「他部門への誤接続や外部公開リスクを排除しつつ、既存システムを改修せずに接続範囲を限定せよ」と指示があった。
ただし、①各部門 VPC と共有 VPC の CIDR が歴史的経緯で一部重複しており変更できない、②ルートテーブルやサブネット構成を部門側で追加管理する運用コストは許容されない、という条件がある。
さらに中央 IT 部門は、接続を許可する VPC をサービス側でホワイトリスト管理し、部門増減に応じて柔軟に制御したいと考えている。
ソリューションアーキテクトは、これらのビジネス背景と技術制約を踏まえて、部門 VPC のクライアントが共有 VPC の Network Load Balancer 越しに集中型サービスへ安全かつ疎結合に接続できるようにするため、どのネットワーク構成を採用すべきか？

【SAP-240】ある小売 EC 事業者では、セキュリティ統制の観点から AWS アカウントを職能別に分離している。
プライベート DNS はガバナンス部門が一元管理する方針の下、すべてアカウント A の Amazon Route 53 プライベートホストゾーンに集約されている。
一方、受注処理 Web アプリケーションと Amazon RDS for MySQL で構成される 2 層システムはアカウント B で稼働しており、社員は社内ネットワーク経由で注文登録や在庫照会を行っている。
年末商戦に備え、このシステムを新しい VPC へクローンするプロジェクトが始まり、運用簡素化を目的に RDS エンドポイントを指す db.example.com の CNAME レコードを既存ホストゾーンに追加した。
DNS を単一箇所に集約する方針は維持しつつ、各 VPC がオートスケールに追従できることが技術上の必須条件となっている。
しかしデプロイ後、EC2 インスタンスで db.example.com が解決できずアプリケーションが起動に失敗した。
Route 53 上ではレコード自体が正しく作成されていることを確認済みである。
インフラ設計を担当するソリューションアーキテクトは、上記のビジネス要求と運用方針を満たしながらこの名前解決問題を解消するため、どの構成変更または追加設定を実施すべきか。
最も適切な手順の組み合わせを二つ選択せよ。