SCS-2.4 ロギングソリューションのトラブルシューティングを行う。
ブックマークページはこちら
正解番号の相違等のご報告はコメントでいただけますと幸いです。技術質問は会員制コミュニティで対応しております。
8/2:AWSサービス種別の演習カテゴリを提供開始しました。
8/8:全問ランダムを模擬試験に名称変更。合格時に認定証を表示するようにしました。
採点する
10問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 10
1. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-76】貴社は世界 3 リージョンへ配信する BtoC EC サイトを CloudFront で公開している。
通常 1 IP あたり /login パスへのリクエストは 5 分で 300 件以下だが、最近は 1,500 件超のブルートフォース攻撃が発生し、オリジンサーバーの Auto Scaling コストが急増した。
要件は (1) 正当ユーザ誤遮断率 1% 未満、(2) バージニア北部リージョン外での変更禁止、(3) CloudWatch でリアルタイム可視化、(4) 追加コスト最小化。
可用性を維持しつつ攻撃のみを自動遮断する最適な対策はどれか。正解不正解ヒントボタン
CloudFront のレイヤ 7 防御はバージニア北部に配置される AWS WAF のレートベースルールが最も近道です。Scope-down Statement で URI を「/login*」に限定すれば、そのパスだけが集計対象となり、商品一覧や画像取得など他ページの健全トラフィックを誤って抑制するリスクを最小化できます。
通常のアクセスは 1 IP あたり 5 分で約 300 回という実測値がありますから、閾値を 1,000 回前後に設定すると統計上 99% 超の正当ユーザが通過できます。AWS WAF の Rate-based rule は IP 単位で自動集計し BLOCK アクションを選ぶだけで機能するため、複雑な Lambda@Edge や Auto Scaling への追加設定を施す必要がありません。
AWS WAF は AllowedRequests と BlockedRequests を自動で CloudWatch メトリクスに出力するので、ダッシュボード化によるリアルタイム可視化が容易です。ルール 1 本分の課金で済み Shield Advanced よりコストを抑え、変更範囲もバージニア北部のみで済む点から、可用性・誤遮断率・運用コストという複数要件を俯瞰して判断すると最適解が見えてきます。
-
質問 2 of 10
2. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-77】グローバル展開する動画配信企業 MediaCast 社は、CloudFront → ALB → EC2 の階層で REST API を公開している。
平常時は総計 1 分 2,000 リクエスト、1 IP 当たり 50 リクエストだが、最近 1 IP から 5 分間で 20,000 リクエストの L7 DDoS が発生し ALB が 503 を返した。
要件は次のとおり。
①異常トラフィックを 5 分以内に自動遮断する
②正規ユーザへの影響を最小化する
③閾値やブロック状況を運用ダッシュボードで即時確認できる
④追加コストを抑える。
最も適切なアーキテクチャ変更はどれか。正解不正解ヒントボタン
CloudFront と連携させた AWS WAF のレートベースルールは「1 IP あたりのリクエスト数を 5 分間で集計してしきい値超過時に自動 Block」という機能が標準で備わっているため、エッジで悪性トラフィックを遮断しつつ ALB や EC2 の負荷と 503 返却を抑えられます。通常ユーザの通信はキャッシュと正規レスポンスで処理されるためレイテンシを悪化させず、設定変更も閾値を入力するだけで即時反映され、コード追加や複雑な運用手順が不要なのが大きな利点です。
AWS Shield Advanced は主に L3/L4 のネットワーク攻撃に有効で HTTP Flood など L7 の細かなレート制御を行えず、Route 53 の DNS レートリミットはあくまでクエリ段階の防御にとどまり、Lambda@Edge と DynamoDB でカウンタを作ると高頻度書込や関数同時実行のコストが増大します。これらの方法はリアルタイム統計や 5 分以内ブロックといった要件に対しオーバースペックまたは不足しがちで、運用負荷や課金額の面でも不利になりやすい点を整理して比較してみてください。
WAF ログを Kinesis Data Firehose で S3 に流し込み CloudWatch ダッシュボードや QuickSight で可視化すれば閾値超過・ブロック数をほぼリアルタイムで確認でき、平常時は従量課金だけでコストを抑制できます。検知速度、正規ユーザ影響の少なさ、自動化された運用と即時の可観測性、追加コストの低さという複数要件を俯瞰すると、エッジに配置した AWS WAF のレートベース制御が最も整合的でシンプルな解決策であることが見えてきます。
-
質問 3 of 10
3. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-78】ある動画ストリーミング企業は CloudFront 経由で SPA 型ウェブアプリを世界配信している。
最近、1 時間当たり最大 20 万リクエストを発生させるスクレイピング Bot によりオリジンの EC2 Auto Scaling が過剰にスケールしコストが 15% 増加した。
正規ユーザーには Cookie company_session が付与され、提携企業のクローラは共有済み API キーを X-Partner-Key ヘッダーに設定する。
要件は次のとおり:
1) Bot を高精度で特定し遮断しつつ誤検知を最小化する。
2) 提携クローラは許可し、リクエストが 1 分 3,000 件を超えた場合のみ遅延させる。
3) 将来の Bot 変化に追従でき、運用負荷を最小化するマネージドルールを採用する。
最も適切な設計はどれか。正解不正解ヒントボタン
CloudFront に関連付けた AWS WAF を用いればリクエストはエッジの PoP で精査され、1 時間 20 万件のスクレイピングでも EC2 Auto Scaling へ届かずコスト増を抑止できます。加えて Bot Control マネージドルールセットは AWS セキュリティチームの脅威インテリジェンスが自動反映されるため、ヘッダー偽装や頻繁に姿を変える Bot にも高精度で追従でき、Cookie company_session を持つ正規ユーザーに過度な影響を与えにくい点が安心です。
提携クローラを確実に許可する鍵は AWS WAF の評価順序です。最優先に X-Partner-Key ヘッダーを検証して Allow するカスタムルールを置けば、正規キー付きのトラフィックは Bot Control やレートベースルールの判定を受けず、誤検知が避けられます。その次に 1 分 3,000 リクエスト超を対象に CAPTCHA を返すレートベースルールを配置すれば、キー漏れや突発的な高負荷時でも「遅延」という要件を満たしつつ業務を継続できます。
IP レピュテーションリストや User-Agent 判定を自作スクリプトや Lambda@Edge で維持すると更新・整合の運用負荷が高まりがちですが、AWS WAF Bot Control とレートベースルールはマネージドで継続アップデートされるため保守がほぼ不要です。L3/L4 を担う AWS Shield Advanced とも役割分担が明確で、エッジ遮断・ヘッダーホワイトリスト・分単位のレート制御を単一 Web ACL で完結できる構成が複数要件を俯瞰した総合判断として最適といえます。
-
質問 4 of 10
4. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-79】動画配信サービスを展開する企業は、CloudFront と ALB を用いて世界 190 か国へ HTTPS 配信している。
最近、SQL インジェクションと 1 分あたり 2,000 リクエストを超える突発的アクセスが急増した。
要件は次のとおり。
1) CloudFront でオリジン到達前に攻撃を遮断する 2) /admin/* はパートナー CIDR（10.10.0.0/16）のみ許可 3) 追加レイテンシを最小化し、WAF キャパシティを 200 WCU 未満に抑える 4) EU 圏からの通常トラフィックには緩いレート制限を適用する。
最も効率的な構成はどれか。正解不正解ヒントボタン
CloudFront レイヤで AWS WAF のグローバル Web ACL を紐付けると、エッジロケーションで SQL インジェクション検査やレート制御が完結し、ALB までリクエストを運ばずに遮断できるため「オリジン到達前に防御」と「追加レイテンシをミリ秒以内に抑制」を同時に達成でき、リージョナル Web ACL を ALB に適用する構成に比べ遠距離転送後に検査が行われるという弱点を解消できます。
パスが /admin/* のときだけパートナー CIDR 10.10.0.0/16 を許可したい場合は、AWS WAF のルールグループで URI 条件と IPSet を組み合わせ、優先度 1 で許可しデフォルトアクションをブロックにすれば意図したロジックがエッジで機能し、Security Group や Network ACL では実現しづらいパスレベル制御を簡潔に行えます。
SQLi Managed Rule で約 40 WCU、Rate-based Rule を 1 分 2,000 リクエストに設定して EU リージョンをスコープダウン条件から除外すれば合計 WCU はおよそ 150 に収まり、CloudFront 上の分散アキュレータが突発アクセスを吸収しつつ EU 圏の通常視聴者には緩い制限を残せるため、性能・キャパシティ・セキュリティという複数要件をバランスよく満たす最適解となります。 -
質問 5 of 10
5. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-80】ある動画配信企業は、東京リージョン 2AZ の ECS/Fargate クラスタを ALB（HTTPS）経由で公開している。
ピーク時には /login への合計 5,000 req/s が発生するが、同一 IP から 30 秒間に 1,500 回を超える POST が検出され認証基盤に過負荷が生じた。
要件は「同一 IP が 5 分間に 1,000 リクエストを超えた場合、自動で 24 時間ブロックし、正規ユーザーへの影響を最小化しつつ監査ログを取得する」ことである。
最も適切なアプローチはどれか。正解不正解ヒントボタン
ピーク時の過負荷を送信元 IP 単位で抑制するには、ALB へアタッチした AWS WAF のレートベースルールが 5 分窓でリクエスト数を自動カウントし、閾値超過 IP を 24 時間隔離する仕組みを持ち、GUI で 1,000 件という値を設定するだけで ECS/Fargate を変更せずに目的を達成でき、TTL は自動更新され管理作業も発生しません。
認証エンドポイントだけを対象にして正規トラフィックへの影響を最小に抑えるなら、AWS WAF のスコープダウン条件で HTTP メソッド POST とパス /login を組み合わせ、他の GET やストリーミング要求をカウント対象外としたうえで ALB 上に実装すれば、CloudFront 追加や Shield Advanced 連携による構成変更や証明書移行を避けつつピンポイントに防御できます。
監査面まで考慮すると、AWS WAF のログ機能をオンにして CloudWatch Logs へ JSON を全量送信すれば Athena で検索も行え、NACL やセキュリティグループでは残らない URI とヘッダーが取得できるため、自動遮断・パス限定・24 時間ブロック・詳細ログという四つの要件を総合的に満たすのは ALB 直結の WAF 構成という結論になります。 -
質問 6 of 10
6. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-81】国際 EC 企業は CloudFront → ALB → EC2 でサイトを提供している。
ピーク 3 万 rps、可用性 99.95%。
全トラフィックに
①AWS マネージドルール (OWASP Top 10) と
②5 分間 2,000 件のレート制限を適用し、/admin 配下は社内 CIDR 10.0.0.0/16 だけ許可したい。
WAF ルールは一元管理し、ALB への直接攻撃は遮断、追加コストと運用負荷は最小化する必要がある。
要件を満たす構成を 1 つ選べ。正解不正解ヒントボタン
まず、AWS WAF を配置する位置を考えると、CloudFront の Web ACL にまとめることで世界中のエッジで OWASP Top10 マネージドルールや 5 分 2,000 件のレートベースルールを適用し、ピーク 3 万 rps をさばきながら悪質リクエストをオリジン手前で破棄できます。ALB 側は Security Group で防御を補完できるため Web ACL が 1 個で済み、課金対象と運用変更点が最小化され、CloudFront の 99.95% SLA も可用性要件に合致します。
次に /admin の社内限定アクセスですが、Web ACL のカスタムルールで URI 条件と IPSet 条件を組み合わせ「パスが /admin かつ 10.0.0.0/16 のみ ALLOW、それ以外 Block」と簡潔に表現できます。さらに ALB の Security Group を CloudFront エッジ IP プレフィックスと 10.0.0.0/16 だけに絞れば、インターネットからの直接 TCP 接続を遮断できます。AWS Managed Prefix List を使えばエッジ IP の自動更新が可能で、手動メンテナンスの負荷も抑えられます。
一方で CloudFront と ALB に同一の Web ACL を二重配置したり Lambda@Edge で IP 判定を分散させたりすると、ルール変更やデプロイが複数箇所に分かれて WAF 料金や Lambda 実行コストも増加します。提示された「ルール一元管理」「追加コストと運用負荷の最小化」「ALB への直接攻撃遮断」を俯瞰すると、エッジに単一 Web ACL を置き Security Group でオリジンを閉じる案が最もシンプルかつ総合的に要件を満たすと判断できます。
-
質問 7 of 10
7. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-82】あるグローバル EC 企業は、2 リージョンの ALB をオリジンとする CloudFront ディストリビューションを公開している。
最近、毎秒 150 万 HTTP リクエストと 120 Gbps の UDP リフレクションを伴う DDoS 攻撃で一時的に 503 エラーが発生した。
要件は以下の通りである。
・可用性 99.99% を維持する
・追加レイテンシを 30 ms 未満に抑える
・誤検知によるブロックを最小化する
・攻撃時のデータ転送料コスト増を抑制する
これらの要件を最も満たすアーキテクチャとして適切なものはどれか。正解不正解ヒントボタン
毎秒 150 万リクエストと 120 Gbps の複合 DDoS をリージョンまで届かせないためには、CloudFront のエッジネットワークでトラフィックを終端し、AWS Shield Advanced でレイヤー3/4 を自動防御するのが定石です。グローバルに分散した PoP が攻撃を希釈し、ユーザとの距離も短くなるため追加レイテンシは 20〜30 ms 程度に収まりやすくなります。
レイヤー7 の HTTP フラッドは量だけでなくパターン変化にも対応が必要です。CloudFront に紐付けた AWS WAF のレートベースルールやカスタムヘッダマッチを活用すると秒単位でスロットリングでき、150 万 RPS 規模でも即時に緩和可能です。ヘッダや URI 条件で細かく絞り込むことで正規リクエストを残し、誤検知を最小限に抑えられます。
さらに Route 53 フェイルオーバーヘルスチェックで 2 リージョンの ALB を自動切替えすれば 99.99% の可用性が確保でき、Shield Advanced の DDoS コスト保護で転送料増分も補填されます。CloudFront＋WAF＋Shield Advanced＋Route 53 を組み合わせる構成は、可用性・レイテンシ・誤検知・コストという複数要件を俯瞰しバランス良く満たす総合判断となります。
-
質問 8 of 10
8. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-83】多国籍 E コマース企業が ap-northeast-1 で運用するウェブ API (EC2 Auto Scaling + ALB) を世界に公開している。
ピーク 20,000 RPS、RTO 5 分、月間 99.9% 可用性が必須で、DDoS・SQLi・Bot を低減したい。
直接 ALB への到達は遮断し、リージョン障害時は us-west-2 の待機系へ自動フェイルオーバーする必要がある。
最小の運用負荷で要件を満たすエッジレイヤ設計はどれか。正解不正解ヒントボタン
エッジに置ける CloudFront は世界中の PoP でリクエストを終端し、キャッシュと TCP フラッド吸収でオリジンを守ります。ALB のセキュリティグループを CloudFront 公開 IP のみに絞れば直接到達面を閉じられます。さらに同じディストリビューションに AWS WAF Web ACL と Shield Advanced を有効化すると、SQLi や Bot 対策のマネージドルールと 24/7 DDoS サポートを一括適用でき、20,000 RPS を運用負荷なく処理できます。
RTO 5 分以内でリージョンを切り替えたい場合、DNS の TTL やキャッシュを待つ方式より速い仕組みが必要です。CloudFront のオリジングループはプライマリ ALB が 5xx を返すかヘルスチェックに失敗した瞬間、ミリ秒単位でセカンダリ ALB（us-west-2）へ自動転送し、復旧後は自動リストアします。CNAME を一つ発行するだけで運用でき、Route 53 フェイルオーバーより確実に 5 分未満を達成できます。
可用性 99.9% と低運用を同時に満たすには、多層防御と多地域冗長をマネージドで束ねる構成が鍵です。CloudFront + Shield Advanced が L3〜L7 攻撃を分散軽減し、AWS WAF がアプリ層の悪質トラフィックを遮断、背後の ALB と EC2 Auto Scaling が負荷変動に追従します。ap-northeast-1 と us-west-2 をオリジングループで並列登録すれば障害時も自動復旧し、監視・切替・キャパシティ計画をサービス側に委ねられるため、複数要件を俯瞰すると最少の手間で全条件を網羅できます。
-
質問 9 of 10
9. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-84】メディア企業 X 社は日本向け静的ニュースサイトを Amazon S3 バケットで運用している。
1 日あたり最大 1 億リクエスト、瞬間 100 Gbps の DDoS に耐え、95 % のユーザーへ 400 ms 以内で HTTPS 配信することが求められる。
オリジン転送量は月 1 TB 以下に抑え、SQL インジェクションも遮断したい。
ルートドメイン (example.jp) は自動フェイルオーバーで冗長化し、運用負荷は最小にしたい。
要件を満たす構成はどれか。正解不正解ヒントボタン
100Gbps級DDoSと日本国内95％を400ms以内で届ける両方の数値目標を同時に満たすには、世界分散エッジから応答するCloudFrontを前段に置き、大容量攻撃を自動吸収するShield Advancedを重ねる構成が現実的であり、ALB直結やS3直公開では地理的距離と帯域不足がボトルネックとなるためキャッシュ能力の確保が鍵となります。
月間1TB以下というオリジン転送量制限を守るには、CloudFrontのOrigin Shieldで複数エッジからのミスを集約して重複要求を防ぎつつAmazon S3をオリジンに据え、統合AWS WAFのSQLiマネージドルールでレイヤ7攻撃を自動遮断することでバケットポリシーでは難しい粒度の検査を行いながらキャッシュTTL最適化でさらにバックエンド負荷を抑制できます。
ルートドメインの可用性を高めるにはRoute 53エイリアスとヘルスチェックを併用したアクティブパッシブ切替が適しており、障害時に別リージョンのCloudFrontへ自動ルーティングできるためDNS短TTLや加重ポリシーより確実で高速、Origin ShieldやShield Advancedと組み合わせた全マネージド構成がDDoS耐性・レイテンシ・転送量・運用負荷の総合バランスを最も満たすと俯瞰できます。 -
質問 10 of 10
10. 質問
カテゴリ: SCS-3.1エッジサービスのセキュリティコントロールを設計し、実装する。【SCS-85】国際通販企業 Z 社は、独自ドメイン www.example.com を世界 14 リージョン向けに Amazon CloudFront で配信する計画を立てている。
平均 5 万 req/秒、TLS1.2 以上必須、公開 CA から取得した RSA 2048bit 証明書を用いる。
証明書の更新は完全自動化し、運用担当者が秘密鍵を保管・操作することを禁止する。
最も要件を満たす証明書配置方法はどれか。正解不正解ヒントボタン
CloudFront で独自ドメインの TLS1.2 以上を提供する場合、ビューワーが参照できる証明書は us-east-1 の AWS Certificate Manager に保管されたもの、または IAM サーバー証明書のいずれかに限定されており、us-east-1 以外の ACM に取り込んだりオリジンや Application Load Balancer 側で終端したりしても CloudFront 自体は正しい証明書を提示できず、世界 14 リージョンからの毎秒 5 万リクエストを安全に処理できない点がポイントです。
ACM で発行またはインポートされた RSA 2048bit 証明書は更新期限が近付くと ACM が自動で新しい鍵ペアを生成しエッジに反映してくれるため、秘密鍵がマネージドサービスの内部から出ることはなく運用担当者が鍵ファイルを手元で保管・配布・更新する作業が不要になり、監査要件で定められた鍵非保持の方針や自動化という運用効率の両方を簡単に満たすことができます。
複数リージョン向けに高負荷配信を行いながらセキュリティと運用自動化を両立させるには、CloudFront が認識できる場所に公開 CA からの証明書を置き、ACM の自動更新機能で鍵管理をサービスに委譲し、Viewer ↔ CloudFront ↔ オリジンの通信経路で暗号化レイヤをどこに置くかを総合的に比較して最も制約の少ない構成を選ぶ視点が重要です。