【無料】AWS SAA-C03練習問題10問｜図解解説付き｜Udemy講師作成

正解：D

A. アカウントでAmazon GuardDutyを有効にする。

不正解 Amazon GuardDutyは脅威検出サービスで、AWSアカウント内の悪意のあるアクティビティや不正な行動を特定することに特化しています。機械学習を使用してネットワークアクティビティを分析し、セキュリティ脅威を検出しますが、DDoS攻撃の防御・軽減機能は提供しません。検出は可能でも、実際の攻撃トラフィックをブロックする機能はありません。

B. EC2インスタンスでAmazon Inspectorを有効にする。

不正解 Amazon InspectorはEC2インスタンスとアプリケーションの脆弱性評価サービスです。ソフトウェアの脆弱性、意図しないネットワークアクセス、セキュリティのベストプラクティス違反を特定します。ランタイムでの動作分析により内部セキュリティを強化しますが、外部からのDDoS攻撃の検出や防御には対応していません。

C. AWS Shieldを有効にしてAmazon Route 53を割り当てる。

不正解 AWS ShieldはDDoS攻撃の防御に特化したサービスですが、2つの問題があります。まず、問題文で「DNSにはサードパーティサービスが使用されており、変更できません。」と明記されており、Route 53は使用されていません。次に、大規模DDoS攻撃の防御にはShield Advancedが必要で、標準のShieldでは高度で大規模な攻撃に対する十分な保護を提供できません。

D. AWS Shield Advancedを有効にしてELBを割り当てる。

正解 AWS Shield AdvancedはDDoS攻撃の検出と防御に特化した高度なサービスで、大規模で複雑なDDoS攻撃に対する強化された保護を提供します。ELBとの統合により、ネットワークレベルとアプリケーションレベルの両方で攻撃を軽減できます。AWS DDoS Response Team（DRT）へのアクセス、リアルタイム攻撃通知、詳細な攻撃診断など、包括的なDDoS対策機能を提供します。

全体的な説明

問われている要件

• パブリック向けWebアプリケーションの大規模DDoS攻撃対策
• ELB背後のEC2インスタンス群の保護
• サードパーティDNSサービス環境での実装
• 検出機能と防御機能の両方の提供
• スケーラブルで効果的なDDoS軽減策

前提知識

DDoS防御サービスの特徴について

• AWS Shield StandardはすべてのAWSアカウントに無料で含まれており、最も一般的なネットワークおよびトランスポート層のDDoS攻撃に対する基本的な保護を提供します。CloudFront、Route 53、Elastic Load Balancingなどのサービスで自動的に有効になりますが、高度な攻撃や大規模攻撃には限界があります。
• AWS Shield Advancedは月額料金制の高度なDDoS保護サービスで、より大規模で複雑な攻撃に対応します。EC2、ELB、CloudFront、Route 53、Global Acceleratorを保護対象とし、リアルタイム攻撃通知、AWS WAFとの統合、DDoS Response Team（DRT）によるサポートを提供します。攻撃によるスケーリングコストの保護も含まれます。

セキュリティ監視サービスの特徴について

• Amazon GuardDutyは機械学習、異常検出、統合された脅威インテリジェンスを使用してAWSアカウントとワークロードを保護する脅威検出サービスです。VPCフローログ、DNSログ、CloudTrailイベントログを分析して悪意のあるアクティビティを検出しますが、攻撃の軽減機能は提供しません。
• Amazon InspectorはEC2インスタンスとコンテナイメージの脆弱性管理サービスで、ソフトウェアの脆弱性と意図しないネットワークアクセスを継続的にスキャンします。内部セキュリティの強化には有効ですが、外部からの攻撃の防御には対応していません。

解くための考え方

この問題の鍵は「大規模DDoS攻撃」というキーワードと、システム構成の理解です。まず、大規模DDoS攻撃の対策には、AWSの中でAWS Shield Advancedが最も特化したサービスです。次に、問題文を分析すると、トラフィックはELBを通じてEC2インスタンスに到達するため、ELBレベルでの保護が最も効果的です。

また、「DNSにはサードパーティサービスが使用されており、変更できません。」という記述により、Route 53は環境に含まれていないため、技術的に適用できません。

GuardDutyとInspectorは検出には有効ですが、実際の攻撃トラフィックの軽減・ブロック機能は提供しないため、DDoS攻撃の防御という要件を満たしません。

したがって、Shield AdvancedとELBの組み合わせが唯一の適切な解決策となります。

アーキテクチャ図

アーキテクチャ図の解説

Shield AdvancedによるELBレベルでのDDoS防御

外部からのトラフィックはサードパーティDNSサービスを経由してAWS環境に到達し、AWS Shield AdvancedがELBレベルで大規模DDoS攻撃を検出・軽減します。Shield Advancedは機械学習ベースの検出エンジンにより、正常なトラフィックと攻撃トラフィックを区別し、攻撃トラフィックを自動的にフィルタリングします。ELBの背後にある複数のEC2インスタンスは、攻撃が軽減された正常なトラフィックのみを受信し、安定したサービス提供を維持できます。リアルタイム攻撃通知により、セキュリティチームは攻撃状況を即座に把握できます。

包括的なDDoS対策と24/7サポート体制

AWS Shield AdvancedはDDoS Response Team（DRT）による24/7の専門サポートを提供し、攻撃発生時には即座に対応を開始します。CloudWatchとの連携により、DDoS攻撃のメトリクスを継続的に監視し、攻撃パターンの分析や対策効果の測定が可能です。また、AWS WAFとの統合により、ネットワーク層の攻撃だけでなく、アプリケーション層の攻撃も防御でき、多層防御アーキテクチャを実現します。攻撃によるスケーリングコストの保護機能により、DDoS攻撃による予期しない課金増加からも保護されます。

他のソリューションとの比較

他のセキュリティサービスと比較すると、Shield Advancedの優位性は明確です。

GuardDutyは攻撃の検出には優れていますが、実際の攻撃トラフィックをブロックする機能は提供しません。

Inspectorは内部の脆弱性評価には有効ですが、外部からのDDoS攻撃とは無関係です。

Shield Standardは基本的な保護は提供しますが、大規模攻撃や高度な攻撃には対応できません。また、問題文でサードパーティDNSサービスが使用されているため、Route 53ベースの解決策は適用できません。

Shield AdvancedとELBの組み合わせのみが、大規模DDoS攻撃の検出と防御の両方を効果的に実現できます。

実装の考慮事項

実装時には、Shield Advancedの有効化とELBへの適用、適切なCloudWatchアラームの設定、DRTとの連携手順の確立が必要です。コスト面では、Shield Advancedは月額$3,000の固定費用に加えて、データ転送量に基づく課金が発生するため、予算計画が重要です。

セキュリティ面では、AWS WAFルールの最適化、アクセスログの分析、定期的な攻撃シミュレーションによる対策効果の検証が推奨されます。また、攻撃発生時の対応手順の文書化、関係者への通知体制の整備、復旧手順の事前準備も重要な考慮事項です。DRTとの効果的な連携のため、攻撃時の連絡先や権限設定も事前に整備する必要があります。

参考資料

• AWS Shield とは
• AWS Shield Advanced の機能
• DDoS 攻撃への対応のベストプラクティス
• Elastic Load Balancing での DDoS 軽減
• Amazon GuardDuty とは
• Amazon Inspector とは
• AWS WAF とは
• DDoS Response Team（DRT）サポート

正解：D

A. Amazon Kinesis Data Analyticsにイベント情報を保存し、コンシューマーアプリケーションがイベントを読み取って処理するように設定する

不正解 Kinesis Data Analyticsはリアルタイムデータ分析サービスであり、メッセージのデカップリングや配信には適していません。このサービスはApache Flinkを使用してストリーミングデータを変換・分析することが主目的です。複数のコンシューマーアプリケーションへのメッセージ配信機能は提供されておらず、要件である「数十のアプリケーションとマイクロサービスがイベント情報を消費する」という部分を満たすことができません。

B. Auto Scalingグループ内のAmazon EC2インスタンスに取り込みアプリケーションをデプロイし、CPUメトリクスに基づいてEC2インスタンス数をスケールする

不正解 EC2 Auto ScalingはCPUメトリクスに基づいてスケールしますが、試合クライマックス時のような突然のイベント急増に対する反応速度が不十分です。インスタンスの起動には時間がかかり、毎秒100,000件という急激な負荷変動に対応できません。また、このアプローチではアプリケーション間のデカップリングが実現されず、取り込みアプリケーションとコンシューマーアプリケーションが直接結合したままになります。運用コストも高くなる傾向があります。

C. 単一シャードでAmazon Kinesis Data Streamsにイベント情報を書き込み、AWS Lambda関数でイベントを前処理してAmazon DynamoDBに保存し、コンシューマーアプリケーションがDynamoDBから読み取って処理するように設定する

不正解 単一シャードのKinesis Data Streamsでは毎秒1,000レコードまでしか処理できず、毎秒100,000件という要件を満たすには大幅にシャード数を増やす必要があります。さらに、DynamoDBからイベント情報を読み取る方式では、コンシューマーアプリケーションが継続的にポーリングする必要があり、効率的ではありません。この構成は複雑でコストも高く、真のデカップリングが実現されていません。

D. 複数のAmazon Simple Queue Service（Amazon SQS）サブスクリプションを持つAmazon Simple Notification Service（Amazon SNS）トピックにイベント情報をパブリッシュし、コンシューマーアプリケーションがキューからイベントを処理するように設定する

正解 SNSとSQSを組み合わせたファンアウトパターンは、メッセージの分離と拡張性の両方を実現する最適なソリューションです。SNSトピックに一度パブリッシュされたイベント情報は、複数のSQSキューに自動的に配信され、各コンシューマーアプリケーションが独立してイベントを処理できます。標準SQSキューは実質的に無制限のスループットを提供し、複数キューの並列処理により毎秒100,000件の要件も満たせます。

全体的な説明

問われている要件

• イベント情報を取り込むアプリケーションと数十のコンシューマーアプリケーション間のデカップリング実現
• 毎秒100,000件まで対応可能な高いスケーラビリティの確保
• 急激なイベント量変動への対応能力
• 複数のマイクロサービスが同一イベント情報を並列処理できる仕組みの構築
• コスト効率性と運用の簡素化

前提知識

メッセージングサービスの特徴

• Amazon SNS：フルマネージドなパブリッシュ・サブスクライブメッセージングサービスで、一つのメッセージを複数の宛先に同時配信可能。標準トピックでは実質的に無制限のスループットを提供し、メッセージフィルタリング機能も備えています。FIFOトピックは毎秒300メッセージまでの制限があります。
• Amazon SQS：フルマネージドなメッセージキューサービスで、標準キューは実質無制限のスループット、FIFOキューは毎秒3,000メッセージ（バッチ使用時）まで処理可能。デッドレターキューや可視性タイムアウトなど、信頼性の高いメッセージ処理機能を提供します。

ストリーミングサービスについて

• Amazon Kinesis Data Streams：リアルタイムデータストリーミングサービスで、シャードあたり毎秒1,000レコードまで処理可能。複数のコンシューマーが同一データを並列処理でき、データは最大365日間保持されます。スケーリングには事前のシャード数調整が必要です。
• Amazon Kinesis Data Analytics：Apache Flinkを使用したリアルタイムデータ分析サービスで、SQLやJavaでストリーミングデータを処理できます。分析が主目的で、メッセージの配信には適していません。

コンピューティングサービスの特徴

• Amazon EC2 Auto Scaling：需要に応じてEC2インスタンス数を自動調整するサービスで、CPUやメモリなどのメトリクスに基づいてスケールします。インスタンス起動には通常30秒から数分かかり、急激な負荷変動への対応には限界があります。

解くための考え方

この問題の核心は「デカップリング」と「スケーラビリティ」の両立です。まず、デカップリングの要件を満たすには、メッセージの送信者と受信者が直接接続されない仕組みが必要です。次に、毎秒100,000メッセージという高いスループット要件と急激な負荷変動への対応を考慮する必要があります。選択肢を検討すると、Kinesis Data Analyticsは分析サービスであり配信には不適切、EC2 Auto Scalingは起動時間の問題でリアルタイム性に欠ける、単一シャードのKinesis Data Streamsは容量不足という問題があります。一方、SNS + SQSの組み合わせは、SNSによる1対多のメッセージ配信とSQSによる非同期処理により、完全なデカップリングを実現します。さらに、複数のSQSキューを並列運用することで必要なスループットを確保でき、各コンシューマーアプリケーションが独立してスケールできる理想的なアーキテクチャとなります。

アーキテクチャ図

SNS-SQSファンアウトアーキテクチャ

アーキテクチャ図の解説

メッセージフローとファンアウト処理

図に示されているように、取り込みアプリケーションがSNSトピックに一度メッセージをパブリッシュすると、そのメッセージは自動的に複数のSQSキューに同時配信されます。これがファンアウトパターンの核心で、一つのメッセージが数十のコンシューマーアプリケーションやマイクロサービスに確実に届けられます。SNSは毎秒100,000メッセージの要件に対応できる十分なスループットを提供し、メッセージの重複や欠損を防ぐ信頼性の高い配信を保証します。

デカップリングとスケーラビリティの実現

このアーキテクチャでは、取り込みアプリケーションはコンシューマーアプリケーションの存在や状態を意識する必要がありません。各コンシューマーアプリケーションは専用のSQSキューから独立してメッセージを処理でき、処理速度に応じてポーリング頻度を調整できます。新しいコンシューマーアプリケーションの追加は単純にSQSキューの追加とSNSサブスクリプションの設定のみで実現でき、既存システムへの影響を最小限に抑えられます。

高可用性と障害対応

SQSキューはメッセージの一時的な保存機能を提供し、コンシューマーアプリケーションが一時的に利用不可能になってもメッセージが失われることはありません。デッドレターキューの設定により、処理に失敗したメッセージを別途管理でき、システム全体の可用性を向上させます。また、複数のアベイラビリティゾーンにまたがるAWSの冗長化により、高い可用性が確保されています。

他のソリューションとの比較

Kinesis Data Streamsを使用したストリーミング処理と比較すると、SNS + SQSソリューションは運用が簡素でコスト効率に優れています。Kinesisはリアルタイム分析には適していますが、単純なメッセージ配信においては過剰な機能となり、シャード管理の複雑さとコストが増大します。EC2ベースのソリューションと比べて、完全マネージドサービスであるため運用負荷が大幅に軽減され、自動スケーリングにより予期しない負荷変動にも柔軟に対応できます。

実装の考慮事項

実装時には、SQSキューの可視性タイムアウトとメッセージ保持期間を適切に設定し、コンシューマーアプリケーションの処理時間に合わせて調整する必要があります。また、メッセージの順序性が重要な場合はFIFO SQSキューの使用を検討しますが、スループットが制限されるため複数キューでの並列処理が必要です。デッドレターキューの設定により障害時のメッセージ損失を防ぎ、CloudWatchメトリクスを活用した監視体制の構築も重要な要素となります。

参考資料

• Amazon SNS とは – Amazon Simple Notification Service
• Amazon SQS とは – Amazon Simple Queue Service
• SNS から SQS へのファンアウト – Amazon Simple Notification Service
• Amazon Kinesis Data Analytics とは – Amazon Kinesis Data Analytics
• Amazon Kinesis Data Streams とは – Amazon Kinesis Data Streams
• Amazon EC2 Auto Scaling とは – Amazon EC2 Auto Scaling

正解：B

A. オブジェクトを自動的に移行するためにS3 Intelligent-Tieringを設定します。

不正解 S3 Intelligent-Tieringは予測不可能なアクセスパターンに適していますが、この場合のアクセスパターンは明確で予測可能です（1ヶ月は頻繁、その後はアクセスなし）。また、Intelligent-Tieringは長期アーカイブストレージほど安価ではなく、監視料金も発生するため、明確なアクセスパターンがある場合は手動でのLifecycle設定の方がコスト効率的です。

B. 1ヶ月後にオブジェクトをS3 StandardからS3 Glacier Deep Archiveに移行するS3 Lifecycle設定を作成します。

正解 S3 Glacier Deep ArchiveはAmazon S3で最も安価なストレージクラスで、年に1-2回程度しかアクセスされない長期保存データに最適化されています。1ヶ月後にアクセスされなくなる品質検査ログファイルを無期限保存する要件に完全に適合し、大幅なコスト削減を実現できます。Lifecycle設定により自動移行が可能で、運用オーバーヘッドも最小限です。

C. 1ヶ月後にオブジェクトをS3 StandardからS3 Standard-Infrequent Access（S3 Standard-IA）に移行するS3 Lifecycle設定を作成します。

不正解 S3 Standard-IAは稀にアクセスされるデータには適していますが、Glacier Deep Archiveと比較するとストレージコストが高くなります。1ヶ月後に全くアクセスされないファイルに対しては、より安価なアーカイブストレージの方が適切です。また、取得料金も発生するため、万が一のアクセス時のコストも考慮する必要があります。

D. 1ヶ月後にオブジェクトをS3 StandardからS3 One Zone-Infrequent Access（S3 One Zone-IA）に移行するS3 Lifecycle設定を作成します。

不正解 S3 One Zone-IAは単一のAvailability Zoneにのみデータを保存するため、AZ障害時にデータが失われるリスクがあります。コンプライアンス要件を持つ品質検査ログという重要なデータに対してはリスクが高すぎます。また、Glacier Deep Archiveほど安価ではなく、長期保存のコスト効率性も劣ります。

全体的な説明

問われている要件

• 1ヶ月間の頻繁なアクセス期間への対応
• 1ヶ月後の完全なアクセス停止パターン
• 無期限の長期保存要件
• 最もコスト効率的なストレージソリューション
• 品質検査ログファイルの確実な保護

前提知識

S3ストレージクラスのコスト比較について

• S3 Standard頻繁アクセス用の高性能ストレージ
• 最も高いストレージ料金だが取得料金なし
• 1ヶ月間の頻繁アクセス期間に最適

S3 Glacier Deep Archive

• 最も安価なストレージクラス（Standard比約95%削減）
• 年に1-2回程度のアクセス頻度を想定
• 取得時間は5-12時間
• 最小保存期間180日（削除時の課金条件）

S3 Standard-IA

• 稀なアクセス用、Standardより約50%安価
• 取得料金が発生（GBあたり$0.01）
• 最小保存期間30日

S3 One Zone-IA

• 単一AZ構成、Standard-IAより約20%安価
• 可用性とデータ保護が大幅に低下
• バックアップ用途には不適切

S3 Lifecycleポリシーの設定について

• 自動移行ルールオブジェクト作成日を基準とした自動移行
• 複数ストレージクラス間の段階的移行
• プレフィックスやタグベースでの条件指定

移行パス制限

• Standard → Standard-IA → Glacier → Glacier Deep Archive
• 直接的な移行パス：Standard → Glacier Deep Archive
• 逆方向の自動移行は不可

バックアップデータの特性について

• アクセスパターンの予測可能性作成直後の検証・復旧テスト期間
• 長期間のアーカイブ保存期間
• 災害時やコンプライアンス要件での稀な取得

コスト最適化の要点

• ストレージ料金の大幅削減（長期保存の主要コスト）
• 取得料金の考慮（緊急時アクセスのコスト）
• 運用管理コストの最小化

解くための考え方

この問題は明確で予測可能なアクセスパターン（1ヶ月は頻繁、その後はアクセスなし）と無期限保存要件を持つバックアップデータの最適化問題です。

キーポイントは「最もコスト効率的」という条件です。1ヶ月後に全くアクセスされないファイルを無期限保存する場合、S3 Glacier Deep Archiveが圧倒的に最も安価な選択肢となります。年間ストレージコストをS3 Standardと比較すると約95%の削減が可能で、数年間の保存期間を考慮すると大幅なコスト削減効果が得られます。

Intelligent-Tieringは予測不可能なパターンには有効ですが、明確なパターンがある場合は監視料金が無駄になり、最安価なGlacier Deep Archiveへの移行も行いません。

Standard-IAは中間的な選択肢ですが、長期保存コストがGlacier Deep Archiveの約4倍高く、取得料金も発生します。

One Zone-IAは可用性リスクが高く、バックアップデータには不適切です。

数年間の保存期間を考慮すると、Glacier Deep Archiveによる年間95%のコスト削減効果は圧倒的です。

アーキテクチャ図

アーキテクチャ図の解説

初期アクセス期間とS3 Standard活用

品質検査ログファイルの作成直後から1ヶ月間は、S3 Standardストレージクラスで高性能なアクセスを提供します。この期間中は検証作業、不良分析、データ整合性確認などが頻繁に実行されるため、低レイテンシーと高スループットが重要です。S3 Standardは取得料金が発生せず、頻繁なアクセスパターンに最適化されています。

自動移行システムとコスト最適化

S3 Lifecycle Policyにより、オブジェクト作成から30日後に自動的にS3 Glacier Deep Archiveへの移行が実行されます。この移行により、ストレージコストを約95%削減できる大幅なコスト最適化が実現されます。手動管理は一切不要で、運用オーバーヘッドなしに継続的なコスト削減効果を得られます。

長期アーカイブ保存と稀なアクセス対応

S3 Glacier Deep Archiveでの無期限保存により、最低コストでの長期データ保護を実現します。災害復旧やコンプライアンス監査などの稀なアクセス要件に対しては、5-12時間の取得時間で対応可能です。バックアップデータの性質上、この取得時間は実用的な範囲内であり、コスト削減効果を大幅に上回る価値を提供します。

他のソリューションとの比較

Intelligent-Tieringは予測不可能なアクセスパターンには有効ですが、明確なパターンがある場合は監視料金が無駄になり、最安価なGlacier Deep Archiveへの移行も行いません。

Standard-IAは中間的な選択肢ですが、長期保存コストがGlacier Deep Archiveの約4倍高く、取得料金も発生します。

One Zone-IAは可用性リスクが高く、バックアップデータには不適切です。

数年間の保存期間を考慮すると、Glacier Deep Archiveによる年間95%のコスト削減効果は圧倒的です。

実装の考慮事項

Lifecycle設定では、オブジェクト作成日を基準とした30日後の自動移行ルールを設定します。Glacier Deep Archiveには180日の最小保存期間がありますが、無期限保存要件により問題となりません。

緊急時のデータ取得には5-12時間の復元時間を考慮した運用手順を準備し、より高速な取得が必要な場合は一部データのStandard-IAでの保存も検討できます。コスト監視では、CloudWatchメトリクスでストレージ使用量を追跡し、移行による削減効果を定量化します。また、データ取得時の料金も事前に把握し、災害復旧計画に組み込む必要があります。

参考資料

• Amazon S3 ストレージクラス
• S3 Glacier Deep Archive
• S3 Lifecycle の設定
• S3 Lifecycle 移行アクション
• Amazon S3 の料金
• S3 オブジェクトの復元
• CloudWatch による S3 メトリクス
• S3 のコスト最適化

正解：D

A. AWS Lambda関数を作成して.csvファイルをダウンロードし、ファイルをParquet形式に変換して、出力ファイルをS3バケットに配置します。各S3 PUTイベントに対してLambda関数を呼び出します。

不正解 1GBのファイルサイズは、Lambda関数での処理に複数の制限があります。Lambdaの最大実行時間は15分で、1GBのCSVからParquet変換は時間がかかる可能性があります。また、カスタムコードの作成・保守・テストが必要で運用オーバーヘッドが増加します。メモリ使用量とネットワークI/Oの制約も考慮が必要です。

B. Apache SparkジョブでCSVファイルを読み取り、ファイルをParquet形式に変換して、出力ファイルをS3バケットに配置します。各S3 PUTイベントに対してSparkジョブを呼び出すAWS Lambda関数を作成します。

不正解 Apache Sparkクラスターの管理が必要となり、運用オーバーヘッドが大幅に増加します。Sparkジョブの設定、監視、スケーリング、障害対応など、複雑な運用作業が発生します。Lambdaとの組み合わせにより、アーキテクチャの複雑性も増します。

C. アプリケーションが.csvファイルを配置するS3バケット用にAWS GlueテーブルとAWS Glueクローラーを作成します。AWS Lambda関数をスケジュールして定期的にAmazon AthenaでAWS Glueテーブルをクエリし、クエリ結果をParquet形式に変換してS3バケットに出力ファイルを配置します。

不正解 複数のAWSサービス（Glueテーブル、クローラー、Athena、Lambda）を組み合わせた複雑なアーキテクチャで、各コンポーネントの設定と調整が必要です。定期的なスケジューリングによりリアルタイム処理ができず、効率性も劣ります。運用と監視の複雑性も高くなります。

D. AWS Glue抽出、変換、ロード（ETL）ジョブを作成して.csvファイルをParquet形式に変換し、出力ファイルをS3バケットに配置します。各S3 PUTイベントに対してETLジョブを呼び出すAWS Lambda関数を作成します。

正解 AWS Glue ETLは、大容量データの変換処理に最適化された完全マネージドサービスです。CSVからParquetへの変換は標準機能として提供されており、カスタムコード開発が最小限で済みます。インフラ管理、スケーリング、監視がAWSにより自動化され、運用オーバーヘッドが最小になります。

全体的な説明

問われている要件

• 大容量（1GB）CSVファイルの効率的なParquet変換
• 毎時間数百ファイルの高頻度処理対応
• S3イベント駆動型のリアルタイム処理
• 最小限の運用オーバーヘッドでの実装
• スケーラブルで信頼性の高いデータ変換パイプライン

前提知識

AWS Glue ETLの特徴と利点について

• AWS Glue ETLは、Apache Sparkエンジンをベースとした完全マネージドETLサービスで、大容量データの処理に最適化されています
• CSVからParquetへの変換は組み込み機能として提供されており、コード生成機能により最小限の開発作業で実装できます
• 自動スケーリング機能により、処理負荷に応じてリソースが動的に調整され、コスト効率と性能を両立できます

Lambdaの制限事項と適用範囲について

• AWS Lambdaの最大実行時間は15分、最大メモリは10GBですが、1GBファイルの変換処理は実行時間制限に抵触する可能性があります
• Lambdaは軽量で短時間の処理に最適化されており、大容量データの変換処理には技術的・経済的制約があります
• ネットワークI/O制約により、大きなファイルのダウンロード・アップロードに時間がかかる場合があります

データ変換における運用オーバーヘッドの要因について

• カスタムコードの開発、テスト、デバッグ、保守は継続的な運用作業を必要とします
• インフラストラクチャの管理（サーバー、クラスター、ネットワーク）は専門知識と監視体制を要求します
• 複数サービスの組み合わせは、統合テスト、依存関係管理、障害対応の複雑性を増加させます

解くための考え方

この問題の核心は「最小限の運用オーバーヘッド」という要件です。

まず、1GBという大容量ファイルサイズから、軽量処理向けのLambda単体での実装は技術的制約があることがわかります。

次に、毎時間数百ファイルという高頻度処理から、手動管理が必要なソリューション（Sparkクラスター管理など）は運用負荷が高すぎることが明確です。

「運用オーバーヘッド最小」という要件から、完全マネージドサービスの活用が重要になります。AWS Glue ETLは、データ変換に特化した完全マネージドサービスで、この要件に最適です。

複数サービスの複雑な組み合わせよりも、シンプルで目的に特化したソリューションが運用面で優れています。

アーキテクチャ図

アーキテクチャ図の解説

イベント駆動型リアルタイム処理パイプライン

このアーキテクチャでは、アプリケーションが1GBのCSVファイルを入力S3バケットにアップロードすると、S3 PUTイベントが自動的にLambda関数をトリガーします。Lambda関数は軽量なトリガー機能のみを担当し、実際の重い変換処理はAWS Glue ETLジョブに委譲されます。

この分離により、Lambdaの実行時間制限を回避しながら、リアルタイムでの処理開始を実現しています。

AWS Glue ETLによる完全マネージド変換処理

AWS Glue ETLジョブは、Apache Sparkエンジンを基盤とした完全マネージドな変換処理を実行します。CSVからParquetへの変換は標準機能として提供されており、カスタムコードの開発が最小限で済みます。

自動スケーリング機能により、毎時間数百ファイルという高頻度処理にも対応でき、処理負荷に応じてリソースが動的に調整されます。インフラ管理、パッチ適用、監視がAWSにより自動化されています。

運用オーバーヘッド最小化の仕組み

CloudWatch監視、実行ログ記録、エラーハンドリング、自動リトライなどの運用機能がすべて自動化されており、手動による運用作業が大幅削減されます。Parquetファイルは最適化されたカラム形式で出力S3バケットに保存され、後続の分析処理で高いパフォーマンスを実現します。

他のソリューションとの比較

Lambda単体での実装では、1GBファイルの処理時間制限、メモリ制約、ネットワークI/O制約により技術的困難があり、カスタムコード開発の運用負荷も高くなります。

Apache Sparkクラスターの自己管理では、クラスター設定、監視、スケーリング、障害対応、セキュリティパッチ適用などの継続的な運用作業が必要になります。

複数サービス組み合わせによる複雑なアーキテクチャでは、各コンポーネント間の依存関係管理、統合テスト、障害分析が複雑になり、運用オーバーヘッドが増加します。

実装の考慮事項

実装時には、AWS Glue ETLジョブの設定で、CSVファイルの構造に適したスキーマ定義と、Parquet出力の最適化パラメーター（圧縮形式、パーティション設定など）を適切に設定する必要があります。

また、S3イベント通知の設定では、特定のプレフィックスやサフィックスによるフィルタリングにより、関連ファイルのみがETLジョブをトリガーするよう制御できます。

コスト最適化の観点では、Glue ETLジョブのワーカータイプ（Standard、G.1X、G.2X）と最大ワーカー数を、ファイルサイズと処理時間要件に基づいて適切に設定することが重要です。

運用面では、CloudWatchダッシュボードでETLジョブの実行状況、成功率、処理時間を継続監視し、必要に応じてアラート設定を行うことが推奨されます。

参考資料

• AWS Glue とは – AWS Glue
• AWS Glue ETL ジョブ – AWS Glue
• CSV データを Apache Parquet に変換する – AWS Glue
• S3 イベント通知 – Amazon Simple Storage Service
• AWS Lambda の制限 – AWS Lambda
• AWS Glue の料金 – AWS Glue
• ETL パフォーマンスの最適化 – AWS Glue

正解：D

A. ダッシュボードアプリケーションをオンプレミスでホストし、インターネット経由で生産分析プラットフォームに直接クエリします。

不正解 ダッシュボードアプリケーションをオンプレミスでホストし、インターネット経由でプラットフォームにアクセスする場合、クエリ結果の50MBがAWSからオンプレミスに転送されるため、最も高いインターネットエグレス料金が発生します。また、インターネット接続による帯域幅制限や遅延の問題も生じる可能性があります。

B. ダッシュボードアプリケーションを生産分析プラットフォームと同じAWSリージョンでホストし、インターネット経由でアクセスします。

不正解 ダッシュボードアプリケーションを同じAWSリージョンにホストすることで、プラットフォームとの間の50MBデータ転送は無料になりますが、オンプレミスからダッシュボードアプリケーションへのアクセスにインターネット経由で500KBの転送が発生します。Direct Connectを活用しないため、最適なコスト効率を実現できません。

C. ダッシュボードアプリケーションをオンプレミスでホストし、同じAWSリージョンのDirect Connect接続経由で生産分析プラットフォームに直接クエリします。

不正解 Direct Connect接続を使用することでインターネットよりも低いデータ転送料金を実現できますが、依然として50MBという大容量のクエリ結果をオンプレミスに転送する必要があります。ダッシュボードアプリケーションがオンプレミスにある限り、大きなデータ移動を避けることができません。

D. ダッシュボードアプリケーションを生産分析プラットフォームと同じAWSリージョンでホストし、同じリージョンのDirect Connect接続経由でアクセスします。

正解 ダッシュボードアプリケーションを生産分析プラットフォームと同じAWSリージョンに配置することで、50MBのクエリ結果転送が同一リージョン内（無料）で完結します。オンプレミスからはDirect Connect経由で500KBのWebページアクセスのみとなり、エグレスデータ量を大幅に削減できます。既存のDirect Connect接続を効果的に活用し、最低のエグレスコストを実現します。

全体的な説明

問われている要件

• 生産分析プラットフォームへのクエリ（50MB）とダッシュボードアクセス（500KB）の最適化
• 最低のデータ転送エグレスコストの実現
• 既存のDirect Connect接続の効果的活用
• オンプレミスユーザーからのダッシュボードアプリケーションアクセス
• キャッシュされない結果セットの効率的な処理

前提知識

AWSデータ転送料金の仕組みについて

• AWS内の同一リージョン間でのデータ転送は無料で、同一アベイラビリティーゾーン内のEC2インスタンス間転送、RDSとEC2間転送、S3とEC2間転送などが対象となります
• インターネットエグレス料金は転送量に応じて段階的に設定され、最初の1GBは無料、次の9.999TBまでは$0.09/GB、その後さらに安価になる従量制です
• クロスリージョンデータ転送は送信側リージョンで課金され、料金はリージョンペア間で異なります

AWS Direct Connectの料金体系について

• Direct Connectのデータ転送料金はインターネットエグレスより大幅に安価で、通常50-80%のコスト削減が可能です
• 専用線接続の固定費用（ポート時間、回線費用）は既に発生しているため、データ転送量を最小化することが重要です
• Direct Connect Gatewayを使用することで、複数のリージョンやVPCへの接続を効率化できます

データウェアハウスアーキテクチャのベストプラクティスについて

• 可視化ツールはデータソースに近い場所に配置することで、ネットワーク遅延とデータ転送コストを最小化できます
• クエリ結果のキャッシュ機能がない場合、アーキテクチャレベルでのデータ移動最適化が重要です
• BI（Business Intelligence）ツールの配置戦略は、データサイズ、アクセス頻度、ユーザー分散を考慮して決定すべきです

解くための考え方

この問題の核心は、大容量のクエリ結果（50MB）と小容量のWebページ（500KB）という2つの異なるデータフローを理解することです。

まず、各選択肢でのデータ転送パターンを分析する必要があります。ダッシュボードアプリケーションがオンプレミスにある場合、50MBのクエリ結果を毎回AWS外部に転送する必要があり、これが最も高コストな要因となります。

一方、ダッシュボードアプリケーションをAWS内に配置すれば、生産分析プラットフォームとの間の大容量データ転送は同一リージョン内で完結し、エグレス料金が発生しません。オンプレミスユーザーは500KBの軽量なWebページのみを受信すればよくなります。

さらに、既存のDirect Connect接続を活用することで、残りの500KBのデータ転送もインターネットより安価な料金で実現できます。この組み合わせにより、総エグレスコストを最小化できます。

アーキテクチャ図

アーキテクチャ図の解説

AWS内無料データ転送の活用

このアーキテクチャの最大の特徴は、大容量のクエリ結果（50MB）を同一AWS リージョン内で処理することです。ダッシュボードアプリケーションと生産分析プラットフォームを同じリージョンに配置することで、プラットフォームへのクエリ実行と結果の取得が完全にAWS内で完結し、この部分のデータ転送コストは無料になります。

これにより、従来オンプレミスのダッシュボードアプリケーションが必要としていた50MBのエグレストラフィックが完全に削除され、大幅なコスト削減が実現されます。

Direct Connect経由の最適化されたユーザーアクセス

エンドユーザーからのアクセスは、既存のDirect Connect接続を活用して500KBの軽量なWebページのみを転送します。Direct Connectのデータ転送料金はインターネットエグレス料金より大幅に安価であり、さらに転送量も50MBから500KBに削減されているため、コスト効率性が大幅に向上します。

専用線接続により安定した帯域幅と低遅延も確保され、ユーザーエクスペリエンスの向上も期待できます。

データフロー最適化の効果

このアーキテクチャにより、総エグレスデータ量が従来の50MBから500KBへと99%削減されます。ダッシュボードアプリケーションがクエリ処理と結果の可視化をAWS内で実行し、完成されたWebページのみをオンプレミスに送信することで、ネットワーク効率性とコスト効率性を両立しています。

結果セットがキャッシュされない環境においても、この最適化により継続的なコスト削減効果が期待できます。

他のソリューションとの比較

オンプレミスダッシュボード + インターネット接続の組み合わせは、50MBの高額なインターネットエグレス料金が毎回発生し、最もコスト効率が悪い選択となります。

AWS内ダッシュボード + インターネット接続は、AWS内転送は無料になりますが、500KBのインターネット転送がDirect Connectより高コストです。

オンプレミスダッシュボード + Direct Connect接続は、転送料金は削減されますが、依然として50MBという大容量データの移動が必要で、根本的な最適化には至りません。

実装の考慮事項

実装時には、ダッシュボードアプリケーションのAWSへの移行計画を慎重に策定する必要があります。既存のオンプレミス環境からのスムーズな移行のため、段階的な移行アプローチやハイブリッド運用期間の設定を検討すべきです。

また、ダッシュボードアプリケーションのインスタンスサイズは、同時ユーザー数とクエリ負荷に基づいて適切に設計し、Auto Scalingによる動的なスケーリング機能も活用できます。

セキュリティ面では、Direct Connect接続のセキュリティ設定、VPC内のネットワークセグメンテーション、IAMによるアクセス制御を適切に設定し、企業のセキュリティポリシーに準拠する必要があります。運用面では、ダッシュボードアプリケーションのパフォーマンス監視とコスト監視を継続的に実施することが重要です。

参考資料

• AWS Direct Connect とは – AWS Direct Connect
• AWS Direct Connect 料金 – Amazon Web Services
• Amazon EC2 データ転送 – Amazon Elastic Compute Cloud
• AWS データ転送料金 – Amazon Web Services
• AWS Direct Connect ゲートウェイ – AWS Direct Connect
• Amazon Redshift とは – Amazon Redshift
• VPC エンドポイント – Amazon Virtual Private Cloud

正解：C

A. プロダクションVPCのトラフィック検査とトラフィックフィルタリングにAmazon GuardDutyを使用します。

不正解 Amazon GuardDutyは脅威検知サービスで、機械学習を使用してアカウントやワークロードの異常な活動を検出します。ネットワークトラフィックの検査やフィルタリング機能は提供しておらず、主に既存のログやメタデータを分析して脅威を特定するサービスです。VPCトラフィックのリアルタイム制御や阻止機能はありません。

B. プロダクションVPCのトラフィックをコピーしてトラフィック検査とフィルタリングを行うためにVPC Traffic Mirroringを使用します。

不正解 Traffic Mirroringはネットワークトラフィックをコピーして別の場所に送信するサービスで、検査は可能ですがフィルタリング機能は提供していません。ミラーリングされたトラフィックは元のトラフィックフローに影響を与えず、実際のトラフィック制御や阻止はできません。検査用途には適していますが、要件のフィルタリング機能を満たしません。

C. プロダクションVPCのトラフィック検査とトラフィックフィルタリングに必要なルールを作成するためにAWS Network Firewallを使用します。

正解 AWS Network Firewallはマネージドなステートフルネットワークファイアウォールサービスで、VPCのトラフィック検査とフィルタリングの両方を提供します。インターネットゲートウェイ、NATゲートウェイ、VPN、Direct Connect経由のトラフィックをフィルタリングでき、カスタムルールグループの作成、パケット検査、TLS検査機能を提供します。オンプレミスのインスペクションサーバーの機能を完全に代替できます。

D. プロダクションVPCのトラフィック検査とトラフィックフィルタリングに必要なルールを作成するためにAWS Firewall Managerを使用します。

不正解 AWS Firewall Managerは複数のAWSアカウントやVPCにわたってファイアウォールルールを一元管理するサービスです。実際のトラフィック検査やフィルタリングを実行するのではなく、セキュリティポリシーの管理と適用を行うオーケストレーションサービスです。Network Firewallやセキュリティグループなどの管理は可能ですが、直接的なトラフィック制御機能はありません。

全体的な説明

問われている要件

• プロダクションVPCに出入りするトラフィックの保護
• オンプレミスインスペクションサーバーと同等のトラフィックフロー検査機能
• トラフィックフィルタリング機能の実装
• AWSクラウドでの一元的なネットワークセキュリティ制御
• インライン処理による実時間トラフィック制御

前提知識

ネットワークセキュリティサービスの特徴について

• AWS Network Firewallマネージド型ステートフルネットワークファイアウォールサービス
• レイヤー3からレイヤー7までの検査とフィルタリング機能を提供
• カスタムルールグループと AWS管理ルールグループをサポート
• TLS検査、侵入検知・防止（IDS/IPS）機能を内蔵
• VPCの境界でインラインでトラフィックを処理

Amazon GuardDuty

• AIと機械学習を活用した脅威検知サービス
• VPCフローログ、DNS クエリログ、CloudTrailイベントログを分析
• 異常な活動や悪意のある動作を検出してアラートを生成
• リアルタイムトラフィック制御機能は提供しない

トラフィック監視・制御サービスについて

• VPC Traffic MirroringEC2インスタンスのネットワークインターフェースからトラフィックをコピー
• 複製されたトラフィックを分析用ターゲットに送信
• 元のトラフィックフローに影響を与えない受動的な監視機能
• ミラーフィルターでコピーするトラフィックを選択可能だが制御機能はなし

AWS Firewall Manager

• マルチアカウント・マルチリージョンでのセキュリティポリシー管理サービス
• AWS WAF、AWS Network Firewall、セキュリティグループの一元管理
• セキュリティポリシーの自動適用と継続的なコンプライアンス監視
• 実際のトラフィック処理は管理対象のサービスが実行

ネットワーク制御の実装方法について

• インライン処理とアウトオブバンド処理インライン：トラフィックパス上でリアルタイム制御（Network Firewall）
• アウトオブバンド：トラフィックをコピーして別途分析（Traffic Mirroring）
• インライン処理はレイテンシーが発生するが確実な制御が可能
• アウトオブバンド処理は元のパフォーマンスに影響しないが制御は不可

解くための考え方

この問題はオンプレミスのインスペクションサーバーの機能をAWSクラウドで再現する最適な方法を求めています。要件として「トラフィックフロー検査」と「トラフィックフィルタリング」の両方が明記されており、これらを同時に実現できるサービスが必要です。AWS Network Firewallは唯一両方の機能を提供するマネージドサービスで、VPCの境界でインラインでトラフィックを処理できます。レイヤー3からレイヤー7までの深いパケット検査、ステートフル接続追跡、カスタムルール作成機能により、オンプレミスのインスペクションサーバーと同等以上の機能を提供します。Amazon GuardDutyは検知のみでフィルタリング機能がなく、Traffic Mirroringは監視専用で制御機能がありません。AWS Firewall Managerはポリシー管理サービスで実際のトラフィック処理は行いません。従って、要件を完全に満たす唯一のソリューションはAWS Network Firewallとなります。

アーキテクチャ図

アーキテクチャ図の解説

インライントラフィック制御による包括的保護

このアーキテクチャでは、AWS Network FirewallがプロダクションVPCへの全てのトラフィックフローの中間に配置され、インラインでトラフィック検査とフィルタリングを実行します。インバウンドトラフィックはインターネットからNetwork Firewallエンドポイントを経由してInternet Gatewayに到達し、アウトバウンドトラフィックはNAT Gatewayを経由してNetwork Firewallで検査された後にインターネットに送信されます。この構成により、オンプレミスのインスペクションサーバーと同等の包括的なトラフィック制御が実現されます。

マルチAZ高可用性とスケーラビリティ

Network Firewallエンドポイントは複数のAvailability Zoneに分散配置され、単一AZ障害に対する耐性を提供します。各エンドポイントは自動的にスケーリングし、トラフィック量の増加に対応できます。プロダクションVPC内のアプリケーションサーバーとデータベースサーバーも複数AZに分散配置され、Network Firewallの保護下で安全に運用されます。内部通信は直接行われますが、外部との通信は全てNetwork Firewallを経由することで一元的なセキュリティ制御が実現されます。

統合監視と一元管理機能

CloudWatchにより、Network Firewallのログ、メトリクス、アラートが一元的に監視され、トラフィックパターンや脅威の分析が可能です。AWS Firewall Managerとの統合により、複数のアカウントやVPCにわたるファイアウォールポリシーの一元管理と自動適用が実現されます。これにより、運用の一貫性とコンプライアンスの確保が可能となり、スケーラブルなセキュリティ運用が実現されます。

他のソリューションとの比較

Amazon GuardDutyはログベースの脅威検知サービスで、リアルタイムトラフィック制御機能がないため要件を満たしません。

Traffic Mirroringはトラフィックのコピーと監視には有効ですが、フィルタリング機能がなく、別途インスペクションサーバーの構築・運用が必要となります。

AWS Firewall Managerは管理ツールとして有効ですが、実際のトラフィック処理は行わないため、Network Firewallと組み合わせて使用する必要があります。

これらの比較から、要件を単独で満たせるのはNetwork Firewallのみです。

実装の考慮事項

Network Firewallの実装では、ルートテーブルの適切な設定により全てのトラフィックがファイアウォールを経由するよう構成する必要があります。ルールグループの設計では、アプリケーション要件に応じたきめ細かいルール作成と、パフォーマンスへの影響を最小化するルール最適化が重要です。TLS検査機能を有効化する場合は、証明書管理とプライバシー要件の検討が必要です。コスト面では、処理データ量に応じた従量課金制のため、トラフィック量の予測と最適化が重要となります。また、既存のセキュリティグループやNACLとの適切な役割分担により、多層防御を実現できます。

参考資料

• AWS Network Firewall とは
• AWS Network Firewall の開始方法
• Amazon VPC Traffic Mirroring とは
• Amazon GuardDuty とは
• AWS Firewall Manager とは
• Network Firewall のルールグループ
• Network Firewall のログ記録と監視
• VPC のセキュリティグループ

正解：C

A. Amazon CloudWatch Application InsightsがRDPまたはSSHアクセスを検出したときにAWS Systems Manager OpsItemsを作成するように設定する。

不正解 CloudWatch Application Insightsは主にアプリケーションの問題検出とパフォーマンス監視に特化したサービスです。RDPやSSHアクセスの検出機能は提供しておらず、ネットワークレベルの接続監視には適していません。また、Systems Manager OpsItemsは運用作業の管理に使用されるもので、リアルタイムの通知要件には適合しません。

B. AmazonSSMManagedInstanceCoreポリシーがアタッチされたIAMロールを持つIAMインスタンスプロファイルでEC2インスタンスを設定する。

不正解 AmazonSSMManagedInstanceCoreポリシーの設定は、Systems Manager Session Managerを使用するための前提条件ですが、RDPやSSHアクセスの検出や通知機能は含まれていません。このポリシーはインスタンスへのアクセス方法を提供するものですが、アクセス監視や通知の仕組みは別途構築する必要があります。

C. VPC Flow LogsをAmazon CloudWatch Logsに発行する。必要なメトリックフィルターを作成する。アラーム状態の時に通知アクションを持つAmazon CloudWatchメトリックアラームを作成する。

正解 VPC Flow LogsはVPC内のネットワークインターフェースとの間のIPトラフィック情報をキャプチャできます。SSH（ポート22）やRDP（ポート3389）への接続トラフィックを検出し、CloudWatchメトリックフィルターで特定のポートへの接続パターンをフィルタリングできます。CloudWatchアラームにより、検出時にセキュリティ運用チームへの自動通知を実現できる包括的なソリューションです。

D. EC2 Instance State-change NotificationタイプのイベントをリッスンするためのAmazon EventBridgeルールを設定する。Amazon Simple Notification Service（Amazon SNS）トピックをターゲットとして設定する。セキュリティ運用チームをトピックにサブスクライブする。

不正解 EC2 Instance State-change Notificationは、インスタンスの状態変更（pending、running、stopping、stopped、shutting-down、terminated）をキャプチャします。しかし、RDPやSSHアクセスの確立はインスタンスの状態変更とは無関係で、これらの接続はインスタンスが実行中状態のまま確立されるため、この方法では検出できません。

全体的な説明

問われている要件

• 医療ソフトウェア検証環境への不正アクセス監視
• RDPおよびSSH接続の確立時点での即座の通知
• 各VPCで分離された環境での一元的な監視
• セキュリティ運用チームへの自動通知システムの構築
• ネットワークレベルでのアクセス検出機能

前提知識

VPC Flow Logsの監視機能について

• VPC Flow LogsはVPC内のネットワークインターフェースとの間で送受信されるIPトラフィックに関する情報をキャプチャします。送信元IP、宛先IP、ポート番号、プロトコル、アクション（ACCEPT/REJECT）などの詳細情報を記録できます。
• SSH（ポート22）やRDP（ポート3389）への接続試行は、Flow Logsに記録されるため、これらの特定ポートへの接続パターンを監視できます。成功した接続だけでなく、失敗した接続試行も検出できるため、セキュリティ監視に有効です。
• Flow LogsはCloudWatch Logs、S3、Kinesis Data Firehoseに出力でき、CloudWatch Logsに出力することでリアルタイムに近い監視が可能になります。

CloudWatchメトリックフィルターとアラームについて

• メトリックフィルターは、CloudWatch Logsに送信されるログデータから特定のパターンを検索し、カスタムメトリックを生成できます。正規表現やワイルドカードを使用して、SSH/RDP接続を示すログエントリを検出できます。
• CloudWatchアラームは、メトリックが指定した閾値を超えた場合にアクションを実行できます。SNS通知、Lambda関数の実行、Auto Scalingアクションなどを自動的にトリガーできます。
• アラーム状態では、メール、SMS、Slack通知など複数の通知チャネルを設定でき、運用チームへの迅速な通知を実現できます。

他のAWSサービスの特徴について

• Amazon EventBridgeはイベント駆動型アーキテクチャを構築するためのサービスですが、EC2インスタンスの状態変更イベントは、インスタンスのライフサイクル（起動、停止、終了など）に関するもので、ネットワーク接続とは無関係です。
• Systems Manager Session Managerは、インスタンスへの安全なアクセス方法を提供しますが、従来のSSH/RDPアクセスとは別のアクセス経路であり、従来の接続方法の監視には直接的には役立ちません。

解くための考え方

この問題の核心は、ネットワークレベルでのRDP/SSH接続の検出と通知の自動化です。RDPやSSH接続は、EC2インスタンスの状態変更を伴わないため、インスタンスレベルのイベントでは検出できません。

ネットワークトラフィックを監視できるVPC Flow Logsは、このような要件に最適なソリューションです。特定のポート（SSH: 22、RDP: 3389）への接続を検出し、CloudWatchの機能を活用して自動通知システムを構築できます。

CloudWatch Application InsightsやSystems Manager関連のソリューションは、アプリケーション監視や管理の観点では有用ですが、ネットワーク接続の検出という特定の要件には適していません。

VPC Flow Logsとメトリックフィルターの組み合わせにより、カスタマイズ可能で拡張性の高い監視システムを構築でき、将来的な要件変更にも柔軟に対応できます。

アーキテクチャ図

アーキテクチャ図の解説

ネットワークトラフィックの包括的監視

複数のVPCに分離された検証環境において、各EC2インスタンスのネットワークインターフェースを通じて送受信されるトラフィックをVPC Flow Logsが包括的にキャプチャします。外部ユーザーからのRDP（ポート3389）やSSH（ポート22）接続試行は、すべてFlow Logsに記録され、CloudWatch Logsに集約されます。この方式により、環境の数が増加しても一元的な監視が可能になります。

自動検出と即座の通知システム

CloudWatch Logsに送信されたトラフィックデータは、メトリックフィルターによってRDP/SSH接続パターンが検出され、カスタムメトリックとして変換されます。このメトリックがCloudWatchアラームで監視され、接続が検出された瞬間にSNSトピック経由でセキュリティ運用チームに自動通知されます。この自動化により、24時間体制でのセキュリティ監視を人的リソースなしで実現できます。

他のソリューションとの比較

EventBridgeによるEC2状態変更監視と比較して、VPC Flow Logsはネットワーク接続という実際の脅威を直接検出できます。インスタンスの起動や停止ではなく、実際のアクセス試行を監視するため、セキュリティ上の意味のあるイベントのみを通知できます。

CloudWatch Application InsightsやSystems Manager関連のソリューションと比較して、VPC Flow Logsは既存のインフラストラクチャに追加設定なしで適用でき、アプリケーションレベルの変更も不要です。また、成功した接続だけでなく失敗した接続試行も検出できるため、より包括的なセキュリティ監視を提供します。

実装の考慮事項

VPC Flow Logsの設定では、必要最小限のフィールド（送信元IP、宛先ポート、アクション）のみをキャプチャしてコストを最適化します。メトリックフィルターでは、正規表現を使用してSSH/RDP接続を正確に識別し、誤検知を最小化する必要があります。

CloudWatchアラームの閾値設定では、正常な管理アクセスと不正アクセスを区別するため、時間帯や接続頻度を考慮した設定を行います。SNS通知では、緊急度に応じて複数の通知チャネル（メール、SMS、Slack）を設定し、セキュリティ運用チームの確実な認知を保証します。

コスト管理の観点では、Flow Logsの保持期間を適切に設定し、古いログは自動的に削除されるよう設定することが重要です。また、大量のトラフィックが予想される場合は、サンプリング機能の活用も検討できます。

参考資料

• VPC Flow Logs
• VPC Flow Logs レコードの例
• CloudWatch メトリックフィルター
• CloudWatch アラーム
• SSH アクセス試行の監視方法
• EC2 インスタンス状態変更の監視
• Amazon SNS 通知

正解：D

A. AWS Storage Gateway volume gatewayを作成します。必要なクライアントプロトコルを使用するファイル共有を作成します。エンジニアリングサーバーをファイル共有に接続します。

不正解 AWS Storage Gateway volume gatewayは、iSCSIプロトコルを使用するブロックストレージボリュームを提供するサービスです。SMBクライアントアクセスは提供されません。また、ゲートウェイアプライアンス（仮想マシン）の展開と維持管理が必要で、完全にマネージドなソリューションとは言えません。

B. AWS Storage Gateway tape gatewayを作成します。Amazon S3を使用するようにテープを設定します。エンジニアリングサーバーをtape gatewayに接続します。

不正解 AWS Storage Gateway tape gatewayは、仮想テープライブラリ（VTL）インターフェイスを提供し、既存のバックアップソフトウェアとの統合に使用されます。iSCSIプロトコルを使用し、SMBクライアントアクセスは提供されません。エンジニアリング設計アプリケーションの共有ストレージ要件にも適していません。

C. Amazon EC2 Windowsインスタンスを作成します。インスタンスにWindowsファイル共有ロールをインストールして設定します。エンジニアリングサーバーをファイル共有に接続します。

不正解 EC2 WindowsインスタンスにWindowsファイル共有を設定することで技術的にはSMBアクセスを提供できますが、インスタンスの管理、パッチ適用、バックアップ、高可用性設定などをユーザーが行う必要があり、完全にマネージドなソリューションではありません。

D. Amazon FSx for Windows File Serverファイルシステムを作成します。ファイルシステムを元のサーバーにアタッチします。エンジニアリングサーバーをファイルシステムに接続します。

正解 Amazon FSx for Windows File Serverは、SMBプロトコルをネイティブにサポートする完全にマネージドなWindowsファイルシステムサービスです。ファイルシステムの管理、パッチ適用、バックアップなどがAWSにより自動化され、エンジニアリング設計アプリケーションの共有ストレージ要件を満たします。

全体的な説明

問われている要件

• エンジニアリング設計アプリケーション用の共有ストレージソリューション
• SMBクライアントを使用したデータアクセス機能
• 完全にマネージドなソリューション（運用負荷の最小化）
• AWS Cloud上での実装
• 高性能なファイルアクセスの提供

前提知識

Amazon FSx for Windows File Serverの特徴について

• Amazon FSx for Windows File Serverは、Microsoft Windows Server上に構築されたフルマネージドなファイルシステムで、SMB（Server Message Block）プロトコルをネイティブにサポートします
• Active Directory統合、重複排除、圧縮、VSS（Volume Shadow Copy Service）、Windows ACL（Access Control List）などのWindows固有の機能を提供します
• SSDとHDDストレージオプションがあり、メディアファイルのような大容量データに対して高いスループットとIOPSを提供できます

SMBプロトコルとファイル共有について

• SMB（Server Message Block）は、ネットワーク上でファイル、プリンター、シリアルポートを共有するためのプロトコルで、Windowsファイル共有の標準プロトコルです
• SMB 2.0/3.0では、暗号化機能、パフォーマンスの向上、可用性の改善が提供され、企業環境での安全なファイル共有が可能になります
• メディアアプリケーションでは、大容量ファイルの並行アクセス、ストリーミング再生、編集作業での共有が重要な要件となります

AWS Storage Gatewayの制限について

• AWS Storage Gateway file gatewayはSMBをサポートしますが、オンプレミスまたはEC2インスタンス上にゲートウェイアプライアンスを展開する必要があります
• ゲートウェイの運用管理、パッチ適用、監視は顧客が行う必要があり、完全にマネージドなソリューションではありません
• Volume gatewayとtape gatewayは、それぞれiSCSIプロトコルを使用し、SMBクライアントアクセスは提供されません

解くための考え方

この問題では「SMBクライアントアクセス」と「完全にマネージド」という2つの重要な要件を同時に満たす必要があります。

まず、SMBプロトコルのサポートが必要なため、iSCSIベースのvolume gatewayやtape gatewayは除外されます。これらのサービスはブロックストレージやテープストレージの抽象化を提供しますが、ファイルレベルのSMBアクセスは提供しません。

次に、「完全にマネージド」という要件により、EC2インスタンス上での自己管理Windowsファイル共有も除外されます。このアプローチでは、OSの管理、セキュリティパッチ、バックアップ、高可用性設定などの運用作業が必要になります。

Amazon FSx for Windows File Serverは、これらの要件を完全に満たすサービスです。SMBプロトコルをネイティブにサポートし、AWS が完全に管理するため、顧客の運用負荷を最小限に抑えながら高性能なファイル共有を実現できます。

アーキテクチャ図

アーキテクチャ図の解説

Multi-AZ FSx for Windows File Serverの高可用性

このアーキテクチャでは、Amazon FSx for Windows File Serverが複数のアベイラビリティーゾーンにまたがって配置され、高可用性を提供しています。優先サブネットでアクティブなファイルサーバーが稼働し、スタンバイサブネットで自動フェイルオーバー機能が待機しています。

メディアアプリケーションサーバーとSMBクライアントは、SMB 3.xプロトコルを使用してファイルシステムに接続し、大容量メディアファイルの読み取り、書き込み、ストリーミングアクセスを実行できます。

Active Directory統合によるセキュリティ管理

FSx for Windows File ServerはActive Directoryと統合され、既存のユーザーアカウントとグループベースのアクセス制御を活用できます。AWS Managed Microsoft ADまたはオンプレミスのActive Directoryとの接続により、企業のセキュリティポリシーに準拠したファイルアクセス管理が実現されます。

Windows ACL（Access Control List）により、ファイルやフォルダレベルでの詳細なアクセス権限設定が可能で、メディアアセットの適切な保護が確保されます。

完全マネージド機能による運用負荷軽減

AWSが提供する完全マネージド機能により、自動バックアップ、パッチ適用、CloudWatch監視、重複排除などが自動化されています。これにより、顧客はメディアアプリケーションの開発と運用に集中でき、インフラストラクチャの管理負荷を大幅に削減できます。

他のソリューションとの比較

Storage Gateway file gatewayもSMBをサポートしますが、ゲートウェイアプライアンスの展開と運用管理が必要で、ハイブリッド環境での使用に最適化されています。完全クラウドベースのメディアアプリケーションには不要な複雑性を追加します。

EC2ベースのWindowsファイル共有は、カスタマイズ性は高いものの、OSレベルの管理、セキュリティパッチ、バックアップ戦略、高可用性設定などの運用作業が必要になります。

Amazon EFSはLinux/Unix環境に最適化されており、SMBプロトコルのサポートやWindows固有の機能は提供されません。

実装の考慮事項

実装時には、メディアファイルのサイズとアクセスパターンに基づいて適切なストレージタイプ（SSDまたはHDD）とスループット容量を選択する必要があります。4K/8K動画編集のような高帯域幅要件がある場合は、SSDストレージと高スループット設定が推奨されます。

また、メディアアセットのライフサイクル管理のため、FSxと Amazon S3との統合やAWS DataSyncを使用したデータ移行戦略も検討できます。

セキュリティ面では、VPCエンドポイントの使用、転送時暗号化の有効化、適切なセキュリティグループ設定により、メディアコンテンツの保護を強化することが重要です。運用面では、CloudWatchメトリクスによるパフォーマンス監視、容量使用率の追跡、バックアップ戦略の定期的な見直しにより、システムの健全性と効率性を確保することが推奨されます。

参考資料

• Amazon FSx for Windows File Server とは – Amazon FSx for Windows File Server
• SMB ファイル共有 – Amazon FSx for Windows File Server
• Active Directory との統合 – Amazon FSx for Windows File Server
• AWS Storage Gateway とは – AWS Storage Gateway
• FSx for Windows File Server のパフォーマンス – Amazon FSx for Windows File Server
• バックアップと復元 – Amazon FSx for Windows File Server
• FSx for Windows File Server の料金 – Amazon Web Services

正解：B

A. S3バケットを作成する。S3バケットへの書き込み権限を持つIAMロールを作成する。AWS CLIを使用してすべてのファイルをローカルストレージからS3バケットにコピーする。

不正解 AWS CLIを使用してS3バケットに直接ファイルをコピーするアプローチは、70TBものデータを転送するために大量のネットワーク帯域幅を消費します。インターネット経由での転送は時間がかかり、1Gbpsの接続でも6日以上かかる可能性があります。これは「最小限のネットワーク帯域幅を使用する」という要件に反します。また、大容量データの転送中にネットワーク障害が発生した場合の再送信リスクもあります。

B. AWS Snowball Edgeジョブを作成する。オンプレミスでSnowball Edgeデバイスを受け取る。Snowball Edgeクライアントを使用してデータをデバイスに転送する。AWSがデータをAmazon S3にインポートできるようにデバイスを返送する。

正解 AWS Snowball Edgeは、大容量データの移行に最適な物理的データ転送サービスです。70TBのデータを扱えるデバイス（80TBまでサポート）を使用し、ネットワーク帯域幅を全く消費しません。デバイスの配送と返送に時間はかかりますが、実際のデータ転送は100Gbpsの高速で実行でき、約1.5時間で完了します。「最小限のネットワーク帯域幅」という要件を完全に満たし、「データはもう増加していない」という一回限りの移行に最適です。

C. S3 File Gatewayをオンプレミスに導入する。S3 File Gatewayに接続するためのパブリックサービスエンドポイントを作成する。S3バケットを作成する。S3 File Gatewayで新しいNFSファイル共有を作成する。新しいファイル共有をS3バケットに向ける。既存のNFSストレージからS3 File Gatewayにデータを転送する。

不正解 S3 File Gatewayは、オンプレミスとクラウドストレージ間の継続的な同期に適したハイブリッドソリューションです。70TBのデータを転送するために大量のネットワーク帯域幅を消費し、インターネット経由での転送に時間がかかります。このソリューションは、継続的なファイルアクセスが必要な場合に適していますが、一回限りの移行には適していません。また、「最小限のネットワーク帯域幅」という要件を満たしません。

D. オンプレミスネットワークとAWS間にAWS Direct Connect接続を設定する。S3 File Gatewayをオンプレミスに導入する。S3 File Gatewayに接続するためのパブリック仮想インターフェース（VIF）を作成する。S3バケットを作成する。S3 File Gatewayで新しいNFSファイル共有を作成する。新しいファイル共有をS3バケットに向ける。既存のNFSストレージからS3 File Gatewayにデータを転送する。

不正解 AWS Direct Connectの設定には数週間から数ヶ月の時間がかかり、「可能な限り迅速に」という要件に反します。また、Direct Connectが設定されても、70TBのデータ転送には大量の帯域幅を消費します。Direct Connectは継続的な高速接続が必要な場合に適していますが、一回限りのデータ移行には過剰で、セットアップ時間が長すぎます。

全体的な説明

問われている要件

この問題では以下の要件を満たすソリューションが求められています：

• 70TBという大容量の科学データファイルを移行する必要がある
• データはもう増加しておらず、一回限りの移行である
• 可能な限り迅速にデータを移行する必要がある
• 最小限のネットワーク帯域幅を使用する必要がある

前提知識

AWS Snow Familyサービスについて理解しておく必要があります：

• AWS Snowball Edgeは、80TBまでのデータを物理的に転送できるデバイスです
• ネットワーク帯域幅を全く使用せず、物理的な輸送によってデータを移行します
• デバイス上で最大100Gbpsの高速データ転送が可能です
• 一回限りの大容量データ移行に最適化されています

S3 File Gatewayの特徴：

• オンプレミスとAmazon S3間のハイブリッド接続を提供します
• NFSやSMBプロトコルを使用してS3にアクセスできます
• 継続的なファイルアクセスとローカルキャッシュを提供します
• 一回限りの移行よりも、継続的な同期用途に適しています

AWS Direct Connectの特徴：

• オンプレミスとAWS間の専用ネットワーク接続を提供します
• 高速で一貫した接続を提供しますが、セットアップに時間がかかります
• 継続的な高速接続が必要な場合に適しています
• 新規セットアップには数週間から数ヶ月かかる場合があります

データ転送の時間計算：

• 70TB = 560Tbits（70TB × 8bits/byte = 560Tbits）
• 1Gbps接続：560Tbits ÷ 1Gbps = 560,000秒 ≈ 6.5日
• 10Gbps接続：560Tbits ÷ 10Gbps = 56,000秒 ≈ 15.5時間
• Snowball Edge：100Gbps相当で約1.5時間の転送時間

解くための考え方

要件の優先順位を理解することが重要です。「最小限のネットワーク帯域幅を使用する」という要件が最も重要で、これはネットワーク帯域幅を全く使用しないSnowball Edgeが最適であることを示しています。

「データはもう増加していない」という記述は、一回限りの移行であることを示しており、継続的な同期が必要なFile Gatewayよりも、バッチ移行に適したSnowball Edgeが適していることを示しています。

時間の観点から各選択肢を評価すると、Direct Connectのセットアップ時間が最も長く、「可能な限り迅速に」という要件に合いません。Snowball Edgeは配送時間がかかりますが、実際のデータ転送は最も高速です。

移行プロセスとタイムライン

Snowball Edgeを使用した移行プロセスは以下のようになります。

まず、AWS Management ConsoleでSnowball Edgeジョブを作成し、デバイスの配送を依頼します。デバイスが到着したら（通常4-6営業日）、Snowball Edgeクライアントを使用してNFSストレージから70TBのデータをデバイスに転送します。この転送は100Gbpsの高速で実行され、約1.5時間で完了します。その後、デバイスをAWSに返送し（2-3営業日）、AWSがデータをS3バケットにインポートします。

セキュリティと暗号化

Snowball Edgeデバイスは、転送中および保存時の暗号化を提供します。デバイスは256ビットの暗号化を使用し、転送プロセス全体でデータのセキュリティを保証します。また、デバイスは改ざん検知機能を備えており、物理的なセキュリティも確保されています。

コスト効率性

Snowball Edgeは、大容量データの移行において最もコスト効率的なソリューションです。ネットワーク帯域幅を使用しないため、データ転送コストがかかりません。また、継続的な接続料金も発生しません。一回限りの移行には、継続的なサービス料金が発生するDirect Connectよりもコスト効率が良いです。

他のソリューションとの比較

AWS CLIを使用した直接転送は、小規模なデータには適していますが、70TBのような大容量データには適していません。S3 File Gatewayは、継続的なハイブリッドアクセスが必要な場合に適していますが、一回限りの移行には過剰です。Direct Connectは、継続的な高速接続が必要な場合に適していますが、セットアップ時間が長すぎます。

スケーラビリティの考慮事項

将来的にデータが増加する場合は、S3 File Gatewayや他のハイブリッドソリューションを検討する必要があります。しかし、問題では「データはもう増加していない」と明記されているため、一回限りの移行に最適化されたSnowball Edgeが最適です。

実装の考慮事項

Snowball Edgeの実装では、デバイスの配送スケジュールを事前に計画し、データ転送の時間を確保する必要があります。また、デバイスの返送前に、すべてのデータが正常に転送されたことを確認する必要があります。さらに、AWS側でのインポートプロセスが完了するまで、元のデータを保持しておくことが推奨されます。

参考資料

• AWS Snow Family とは
• AWS Snowball Edge の使用
• AWS Storage Gateway とは
• AWS Direct Connect とは
• 大容量データの AWS への移行
• Amazon S3 へのデータ移行
• AWS Snowball Edge のセキュリティ