type
status
date
slug
summary
tags
category
icon
password
251-AWS SAP AWS 「理論・実践・一問道場」API Key使用プラン
理論
APIセキュリティにおける本質的知識
- アクセス制御 (Access Control)
- IP制限: 信頼できるクライアント（パートナー）のみを許可することで、不正アクセスを防ぐ基本的な方法。AWS WAFを使い、許可リスト（ホワイトリスト）を設定するのが一般的。
- APIキー: ユーザーごとに固有のキーを発行して認証を強化。特にREST APIでは簡単かつ効果的な認証手段。
- リクエスト制限 (Rate Limiting)
- 使用プラン (Usage Plan): API Gatewayでクライアントごとに1秒あたりのリクエスト数や1日あたりの上限を設定可能。リソースの保護やサービスの公平性確保に役立つ。
- WAFルールでの制限: ボット攻撃など大量リクエストを送るクライアントを早期に遮断。
- トラフィック管理
- CloudFrontとの連携: 高速キャッシュや地理的制限を適用可能。ただし、APIの直接的な保護には向かない。
- オリジンアクセスアイデンティティ (OAI): 主にS3アクセス用の仕組み。API Gatewayには適用しづらい。
- コスト最適化
- APIの呼び出し頻度を適切に制御することで、無駄なリクエスト処理を削減し、運用コストを抑える。
- WAFや使用プランを活用することで、追加のインフラコストを抑えながら効果的なセキュリティを実現。
重要なポイント
- IP制限 + 使用プラン + APIキー は、低コストかつセキュアな構成の基本。
- ボット攻撃を防ぎつつ、正当なユーザーには確実にアクセスを提供するバランスが重要。
- APIセキュリティの基本は、最小限の権限で必要なアクセスのみ許可すること。
実践
略
一問道場
質問 #251
トピック 1
ある企業が、米国に拠点を置く6つのパートナーと情報を共有するためにREST APIを作成しています。
この企業はAmazon API Gatewayのリージョナルエンドポイントを作成しました。6つのパートナーは、それぞれ1日1回、このAPIにアクセスして日々の売上データを投稿します。
初回のデプロイ後、企業は世界中の500の異なるIPアドレスから1秒間に1,000件のリクエストが発生していることを観測しました。
企業は、このトラフィックがボットネットから発生していると考えており、コストを最小限に抑えながらAPIを保護したいと考えています。
APIを保護するために企業が取るべきアプローチはどれですか？
A.
Amazon API GatewayをオリジンとするAmazon CloudFrontディストリビューションを作成します。
AWS WAFのWeb ACLを作成し、1日に5件以上のリクエストを送信するクライアントをブロックするルールを設定します。
このWeb ACLをCloudFrontディストリビューションに関連付けます。
CloudFrontにオリジンアクセスアイデンティティ（OAI）を設定し、それをディストリビューションに関連付けます。
API Gatewayを設定し、OAIのみがPOSTメソッドを実行できるようにします。
B.
Amazon API GatewayをオリジンとするAmazon CloudFrontディストリビューションを作成します。
AWS WAFのWeb ACLを作成し、1日に5件以上のリクエストを送信するクライアントをブロックするルールを設定します。
このWeb ACLをCloudFrontディストリビューションに関連付けます。
CloudFrontディストリビューションにカスタムヘッダーを追加し、このヘッダーにAPIキーを設定します。
API Gatewayを設定し、POSTメソッドでAPIキーを要求するようにします。
C.
AWS WAFのWeb ACLを作成し、6つのパートナーが使用するIPアドレスへのアクセスを許可するルールを設定します。
このWeb ACLをAPIに関連付けます。
リクエストの制限を設定したリソースポリシーを作成し、APIに関連付けます。
APIを設定し、POSTメソッドでAPIキーを要求するようにします。
D.
AWS WAFのWeb ACLを作成し、6つのパートナーが使用するIPアドレスへのアクセスを許可するルールを設定します。
このWeb ACLをAPIに関連付けます。
リクエストの制限を設定した使用プランを作成し、APIに関連付けます。
APIキーを作成し、使用プランに追加します。
解説
この問題では、ボットネットによる不正アクセスを防ぎつつ、6つのパートナーがAPIにアクセスできるようにする必要があります。そのため、以下の点が重要です。
- 正当なアクセスのみを許可する方法
6つのパートナーが使用するIPアドレスを特定し、それ以外のアクセスをブロックすることが効果的です。これにより、不要なトラフィックを排除できます。
- リクエストの制御
パートナーのアクセス頻度は1日1回です。これに基づき、APIの使用量を制限するための使用プラン（Usage Plan）を設定し、リクエスト数を制限する必要があります。
- APIキーの利用
パートナーに固有のAPIキーを割り当てることで、認証を追加し、不正なアクセスをさらに防止できます。
各選択肢を検討します：
A. CloudFront + WAF + OAI の設定
- CloudFrontとWAFを利用してトラフィックを制御し、OAIでAPIへのアクセスを限定する方法です。
- 問題点: OAIを使う方法はS3オリジンには適していますが、API Gatewayでは通常不要です。また、この方法では正当なIPアドレスのみにアクセスを限定する仕組みがありません。
- 結論: 不適切。
B. CloudFront + WAF + カスタムヘッダーにAPIキーを追加
- WAFでリクエスト数を制限し、CloudFrontのカスタムヘッダーでAPIキーを活用する方法です。
- 問題点: WAFのルールで「1日5件以上をブロック」としていますが、CloudFrontがあるため、実際のクライアントのIPを完全に制御できるわけではありません。また、APIキーのみに頼る認証はIP制限ほど強固ではありません。
- 結論: 不適切。
C. WAFでIP制限 + リソースポリシーでリクエスト制限
- WAFでパートナーのIPアドレスを許可し、リソースポリシーでリクエスト制限を追加する方法です。
- 問題点: リソースポリシーは主にIAM認証と組み合わせて使われるため、APIキーを使った認証との併用が難しいです。また、使用プランを活用した方がリクエスト制限に適しています。
- 結論: 不適切。
D. WAFでIP制限 + 使用プランでリクエスト制限（正解）
- WAFを利用してパートナーのIPアドレスを許可するルールを設定し、不正アクセスを遮断します。
- 使用プランでリクエスト制限を設定し、パートナーごとにAPIキーを発行します。これにより、1日1回のリクエストに制限可能です。
- 理由: コストを抑えつつ、IP制限、使用プラン、APIキーの認証を組み合わせた実用的な方法です。
- 結論: 適切。
正解: D
WAFでIPアドレスを制限し、使用プランとAPIキーを利用してリクエスト数を制御する方法が、コストとセキュリティの両方を満たします。
252-AWS SAP AWS 「理論・実践・一問道場」データベースアクティビティストリーム
理論
Amazon Auroraのデータベースアクティビティ監視に関連する本質的知識
データベースのアクティビティを監視する際には、セキュリティやコンプライアンス要件を満たすことが重要です。以下は、Amazon Auroraを使用してアクティビティ監視を行うための主要な機能とその応用です。
1. データベースアクティビティストリーム
以下は、データベースアクティビティストリームと**変更データキャプチャ（CDC）**の違いをシンプルにまとめた表です。
項目 | データベースアクティビティストリーム | 変更データキャプチャ（CDC） |
目的 | データベース内でのすべてのアクティビティを記録 | データ変更（挿入、更新、削除）をキャプチャ |
範囲 | クエリ実行、ログイン、権限変更、構造変更など幅広いイベントを対象 | データの変更に特化 |
データ内容 | 実行された操作全般（例: SELECT, ALTER TABLE） | 変更されたデータとその詳細（例: 更新前後の値） |
主な用途 | セキュリティ監査、異常検知、操作履歴の追跡 | データ同期、レプリケーション、リアルタイム分析 |
ツールの例 | Amazon Aurora Database Activity Streams | AWS DMS、Debezium |
ポイント:
- アクティビティストリームはデータベース全体の動きを網羅的に監視したいときに使います。
- CDCはデータ変更だけを効率よく追跡して別システムと連携したいときに使います。
- 概要: Amazon Auroraは、データベースアクティビティストリームという機能を提供し、データベースへのすべてのアクティビティを記録できます。これには、クエリ実行、ログインイベント、データ変更が含まれます。
- 特徴:
- セキュリティ監査: データベースの操作ログを保持して、不正アクセスや不正操作を検知。
- リアルタイム処理: Amazon Kinesisなどと連携して、リアルタイムでの分析が可能。
- データ暗号化: アクティビティデータはAWS Key Management Service (KMS)によって暗号化され、セキュリティが強化されます。
2. Amazon Kinesisとの統合
- Kinesis Data Streams: データベースアクティビティストリームをリアルタイムで処理するために使用。高スループットのデータストリーミングをサポートします。
- Kinesis Data Firehose: データをAmazon S3やAmazon Redshiftに簡単に配信するために使用。リアルタイム性よりも保存や分析を優先する場合に適しています。
3. データ保存と分析
- Amazon S3: アクティビティデータを長期的に保存するための低コストなオプション。保存したデータをAmazon Athenaでクエリ可能。
- Amazon Redshift: 大量のデータを分析する場合に適しており、ビジネスインテリジェンスツールとの統合が簡単。
4. セキュリティとアクセス制御
- AWS IAMとポリシー: データベースアクティビティストリームやKinesisへのアクセスを制限することで、不正使用を防止。
- Amazon EventBridgeの活用: アクティビティストリームをトリガーとしてリアルタイムで特定の処理（例: アラートやログ保存）を実行可能。
適用シナリオ
- セキュリティ監査: Auroraで発生するすべての操作を記録して、監査や法的要件を満たす。
- 運用モニタリング: リアルタイムでデータベースアクティビティを追跡し、問題発生時の迅速な対応が可能。
- コンプライアンス遵守: データ活動のログを保持することで、GDPRやHIPAAなどの規制要件に対応。
まとめ
Amazon Auroraのデータベースアクティビティストリームを中心に、KinesisとS3を組み合わせることで、リアルタイムの監視と低コストなデータ保存が可能になります。このアプローチはセキュリティ、運用効率、コスト効果の観点で非常に優れています。
実践
略
一問道場
質問 #252
トピック 1
ある企業が、単一のAWSリージョンでAmazon Aurora PostgreSQL DBクラスターをアプリケーションに使用しています。同社のデータベースチームは、すべてのデータベースのすべてのデータ活動を監視する必要があります。
どのソリューションがこの目的を達成できますか？
A.
AWS Database Migration Service (AWS DMS)の変更データキャプチャ (CDC) タスクを設定します。Aurora DBクラスターをソースとして指定します。ターゲットとしてAmazon Kinesis Data Firehoseを指定します。Kinesis Data Firehoseを使用してデータをAmazon OpenSearch Serviceクラスターにアップロードし、さらなる分析を行います。
B.
Aurora DBクラスターでデータベースアクティビティストリームを開始し、そのアクティビティストリームをAmazon EventBridgeでキャプチャします。EventBridgeのターゲットとしてAWS Lambda関数を定義します。Lambda関数をプログラムして、EventBridgeからのメッセージを復号化し、すべてのデータベースアクティビティをAmazon S3に公開し、さらなる分析を行います。
C.
Aurora DBクラスターでデータベースアクティビティストリームを開始し、そのアクティビティストリームをAmazon Kinesisデータストリームにプッシュします。Amazon Kinesis Data Firehoseを設定してKinesisデータストリームを消費し、データをAmazon S3に配信してさらなる分析を行います。
D.
AWS Database Migration Service (AWS DMS)の変更データキャプチャ (CDC) タスクを設定します。Aurora DBクラスターをソースとして指定します。ターゲットとしてAmazon Kinesis Data Firehoseを指定します。Kinesis Data Firehoseを使用してデータをAmazon Redshiftクラスターにアップロードします。Amazon Redshiftデータにクエリを実行し、Auroraデータベースでのデータベースアクティビティを判別します。
解説
問題の簡単な解説（Question #252）
質問の要点:
Amazon Aurora PostgreSQL DB クラスターで、データベースのすべてのデータアクティビティを監視する方法を尋ねています。
正しい解答:
C - データベースアクティビティストリームを開始し、Amazon Kinesis データストリームにプッシュして S3 に保存する方法。
解説:
- データベースアクティビティストリームは、Aurora が提供する機能で、すべてのデータベースアクティビティをキャプチャしてストリームとして送信します。
- Kinesis Data Streamsを利用してリアルタイムでデータを転送し、Amazon S3 に保存することで後から分析可能になります。
- この方法は、監視対象のアクティビティ（ログイン、クエリ、変更など）を効率よく追跡する最適解です。
その他の選択肢との比較:
- A, D: AWS Database Migration Service（DMS）はデータの変更追跡（CDC）には適していますが、すべてのアクティビティの監視には向いていません。
- B: EventBridge 経由の処理は追加のデコード作業が必要で、効率が低下します。
ポイント:
Aurora のデータベースアクティビティストリームは、データアクティビティ全般の追跡に最適なソリューションです。
253-AWS SAP AWS 「理論・実践・一問道場」メモリ最適化インスタンス ゲーム
理論
1. Auto Scalingの基本概念
Auto Scalingは、アプリケーションの負荷に応じてインスタンスを動的に増減させる機能です。これにより、トラフィックが急増した場合でも自動的にインスタンスを追加し、トラフィックが少ない場合にはインスタンスを減らして、コストを最適化できます。
スケーリングの設定
- 最小容量（Minimum Capacity）: インスタンスの最小数。これ以下にはスケールダウンしません。
- 最大容量（Maximum Capacity）: インスタンスの最大数。これ以上はスケールアップしません。
- 希望容量（Desired Capacity）: 現在のインスタンス数。スケーリングポリシーに基づいて調整されます。
2. インスタンスの選択と最適化
インスタンスは、アプリケーションのワークロードに最適なものを選ぶ必要があります。たとえば、メモリ集約型のアプリケーションには**メモリ最適化インスタンス（r6gなど）を選び、計算負荷が高いアプリケーションには計算最適化インスタンス（c6gなど）**を選びます。
- メモリ最適化インスタンス（r6g）: メモリを多く消費するアプリケーションに最適。ゲームのようにメモリを多く使うシナリオで有効です。
- 計算最適化インスタンス（c6g）: CPU集約型のワークロードに適しており、負荷の高い計算処理に優れています。
- 汎用インスタンス（m6g）: CPUとメモリのバランスが取れており、さまざまなワークロードに適しています。
3. スケーリングの柔軟性
柔軟なスケーリング幅を設定することで、トラフィックの変動に応じてインスタンスを調整できます。広い調整幅（例: 最小3、最大12）は、リソースの適切な確保とコストの削減を両立させるために重要です。適切なスケーリング設定により、アプリケーションの性能を最適化し、必要ないインスタンスの稼働を避けることができます。
4. コスト最適化
- リソースの過剰な確保を避ける: インスタンスサイズやスケーリング幅を適切に設定することで、無駄なコストを削減できます。
- インスタンスタイプの選定: 必要な性能を確保しつつ、最小限のコストで運用するためには、アプリケーションに最適なインスタンスを選ぶことが重要です。
結論
適切なインスタンスタイプの選定とスケーリング幅を広げることで、アプリケーションの需要に柔軟に対応し、コスト効率を最大化することができます。
実践
略
一問道場
問題 #253
あるエンターテインメント会社は、新しいゲームを最近リリースしました。プレイヤーの体験を良好に保つために、会社は12台のr6g.16xlarge（メモリ最適化）Amazon EC2インスタンスをNetwork Load Balancerの背後に配置しました。運用チームは、Amazon CloudWatchエージェントとカスタムメトリックを使用して、メモリ使用率を監視戦略に組み込みました。リリース期間中のCloudWatchメトリックの分析では、CPUとメモリの消費が予想よりも約4分の1であることがわかりました。ゲームの初期需要は減少し、需要はより変動的になっています。会社は、CPUとメモリの使用量を監視してインスタンスの規模を動的に調整するためにAuto Scalingグループを使用することに決めました。ソリューションアーキテクトは、最もコスト効果の高い方法でAuto Scalingグループを設定する必要があります。
どのソリューションがこの要件を満たすでしょうか？
A. Auto Scalingグループを設定し、c6g.4xlarge（計算最適化）インスタンスをデプロイします。最小容量を3、希望容量を3、最大容量を12に設定します。
B. Auto Scalingグループを設定し、m6g.4xlarge（汎用）インスタンスをデプロイします。最小容量を3、希望容量を3、最大容量を12に設定します。
C. Auto Scalingグループを設定し、r6g.4xlarge（メモリ最適化）インスタンスをデプロイします。最小容量を3、希望容量を3、最大容量を12に設定します。
D. Auto Scalingグループを設定し、r6g.8xlarge（メモリ最適化）インスタンスをデプロイします。最小容量を2、希望容量を2、最大容量を6に設定します。
解説
Cが最適な理由:
- r6g.4xlargeはメモリ集約型のゲームに適したインスタンスで、コスト効率が良い。
- 最小容量3、最大容量12に設定することで、需要に応じて柔軟にスケーリングでき、コストを無駄にせず、パフォーマンスを維持できる。
Dが不適切な理由:
- r6g.8xlargeは過剰なメモリ容量を持ち、コストが無駄になる可能性がある。
- 最小容量2、最大容量6だとスケーリングの柔軟性が足りず、リソースを十分に調整できない。
254-AWS SAP AWS 「理論・実践・一問道場」オンデマンドキャパシティモード
理論
1. DynamoDBのキャパシティモード
以下に、オンデマンドキャパシティモードとプロビジョンドキャパシティモードを使った実例を挙げて、それぞれの特徴を示します。
実例 1: オンデマンドキャパシティモード
シナリオ: 新しいオンラインショッピングサイトを立ち上げた企業。サイトのアクセス数は予測できない。特に新製品のリリース時には急激にアクセスが増加することが予想される。
使用するモード: オンデマンドキャパシティモード
理由:
- サイトのアクセス数が予測できないため、オンデマンドモードを使用すると、トラフィックに応じてDynamoDBが自動的にスケーリングします。
- 特にプロモーションや新製品リリース時など、突発的にアクセスが急増する可能性があるため、事前にキャパシティを設定することなく、負荷に対応できるオンデマンドキャパシティが適しています。
結果:
- アクセス数が増えても、DynamoDBがリアルタイムで自動的にスケールアップします。
- ユーザーがキャパシティを気にする必要なく、コストは使用した分だけに基づいて課金されるため、急なトラフィックの変動にも柔軟に対応可能です。
実例 2: プロビジョンドキャパシティモード + オートスケーリング
シナリオ: 大手eコマースプラットフォームが、日々のトランザクションデータを扱うためのデータベースを構築。アクセスのパターンが比較的予測可能で、ピーク時間帯（例えば、昼休みや夜の時間帯）にアクセスが集中する。
使用するモード: プロビジョンドキャパシティモード + オートスケーリング
理由:
- アクセスパターンが予測可能であるため、プロビジョンドキャパシティモードを使用して、通常時のトラフィックに必要なキャパシティを設定します。
- オートスケーリングを設定することで、昼休みや夜間などのピーク時に自動的にキャパシティを増加させ、トラフィックの変動に対応します。アクセスが少ない時間帯にはリソースを減らしてコストを削減します。
- 最小キャパシティ: RCU 50、WCU 20
- 最大キャパシティ: RCPU 100、WCPU 40
- ターゲット利用率: 70%
結果:
- 通常時のトラフィックに対して最適なキャパシティを維持し、ピーク時には自動的にキャパシティを増加させることで、リソースの効率的な利用が可能です。
- オートスケーリングにより、ピーク時でもパフォーマンスが維持され、過剰なリソースを使わずにコストを抑えることができます。
比較
- オンデマンドキャパシティモード: トラフィックの予測が難しい場合や、予期しないアクセス増加に対応するために有効。設定なしでスケーリングし、柔軟性が高いが、コストが高くなる可能性もある。
- プロビジョンドキャパシティモード + オートスケーリング: アクセスパターンが予測でき、ピーク時間帯のトラフィックに応じてキャパシティを動的に調整したい場合に有効。リソースを効率よく管理し、コスト最適化が可能。
このように、状況に応じてどちらのモードを選ぶかが重要です。
2. オートスケーリング
オートスケーリングは、プロビジョンドキャパシティモードで設定したキャパシティの使用状況に応じて、リソースを自動で増減させます。これにより、過剰なリソースを使用せず、必要なときにだけスケールアップすることができます。
3. コスト最適化
- DAXやElastiCacheは、読み取り性能を向上させるために使用され、リクエスト回数を減らすことでコスト削減が可能です。
- プロビジョンドキャパシティモードとオートスケーリングを組み合わせると、リソースを無駄なく管理でき、コストを効率的に抑えることができます。
4. パフォーマンスとコストのバランス
- オンデマンドキャパシティモードは簡単にスケーリングできますが、予測可能なトラフィックに対してはプロビジョンドキャパシティモードとオートスケーリングの方がコスト効果が高くなります。
- DAXなどのキャッシュサービスは、頻繁にアクセスされるデータの読み取りパフォーマンスを向上させ、DynamoDBへの負荷を減らし、コスト削減を助けます。
実践
略
一問道場
問題 #254
トピック 1
ある金融サービス会社が、数百万件の過去の株式取引データをAmazon DynamoDBテーブルにロードしました。このテーブルはオンデマンドキャパシティモードを使用しています。毎日午前0時に数百万件の新しいレコードがテーブルにロードされます。アプリケーションの読み取りアクティビティは、1日の中で断続的に発生し、限られたキーが繰り返し参照されます。会社はDynamoDBに関連するコストを削減する必要があります。
どの戦略をソリューションアーキテクトは推奨すべきですか？
A. DynamoDBテーブルの前にAmazon ElastiCacheクラスターをデプロイする
B. DynamoDB Accelerator (DAX)をデプロイする。DynamoDBオートスケーリングを設定する。Cost Explorerでセービングプランを購入する。
C. プロビジョンドキャパシティモードを使用する。Cost Explorerでセービングプランを購入する。
D. DynamoDB Accelerator (DAX)をデプロイする。プロビジョンドキャパシティモードを使用する。DynamoDBオートスケーリングを設定する。
解説
正解はDです。
理由:
- DAXで頻繁に参照されるデータをキャッシュし、読み取り性能を向上させます。
- プロビジョンドキャパシティモードで、安定したリソースを確保し、予測可能なコスト管理ができます。
- オートスケーリングでリソースを柔軟に調整し、効率的なコスト管理を実現します。
この組み合わせが最も効果的にコスト削減を達成します。
A. DynamoDBテーブルの前にAmazon ElastiCacheクラスターをデプロイする
- ElastiCacheは読み取りのパフォーマンスを向上させますが、DynamoDBのキャパシティ管理やコスト削減に直接的な影響を与えません。また、ElastiCacheはDynamoDBのキャパシティモードとは異なり、コスト削減に最適な戦略ではありません。
B. DynamoDB Accelerator (DAX)をデプロイする。DynamoDBオートスケーリングを設定する。Cost Explorerでセービングプランを購入する。
- DAXとオートスケーリングは有効ですが、プロビジョンドキャパシティモードを選ばず、セービングプランを購入するだけでは、安定したコスト削減には不十分です。
C. プロビジョンドキャパシティモードを使用する。Cost Explorerでセービングプランを購入する。
- プロビジョンドキャパシティは確実ですが、DAXを使わないため、読み取りパフォーマンスが最適化されません。コスト削減には効果的ではありますが、全体のパフォーマンス向上が欠けます。
255-AWS SAP AWS 「理論・実践・一問道場」NACL
理論
NACLとセキュリティグループの違い
特徴 | NACL（Network ACL） | セキュリティグループ |
適用範囲 | サブネット単位 | インスタンス単位（ENI単位） |
状態管理 | ステートレス（Stateless） | ステートフル（Stateful） |
ルール評価の方法 | ルール番号順（優先順位あり） | すべてのルールを評価 |
デフォルト設定 | - デフォルトNACLはすべて許可- 新規作成NACLはすべて拒否 | - インバウンドとアウトバウンドはすべて拒否 |
1. AWS PrivateLinkとVPCエンドポイント
AWS PrivateLinkは、VPC内のサービスを他のVPCやオンプレミス環境とプライベートに接続するためのサービスです。これにより、インターネットを経由せずに、セキュアにサービス間通信を行うことができます。VPCエンドポイントは、特にサービスを接続するために作成されるもので、AWSのサービス（例えば、S3やDynamoDBなど）またはカスタムサービス（この場合はログサービス）にアクセスするためのエンドポイントを提供します。
2. ネットワークアクセスコントロールリスト（NACL）
NACL（Network Access Control List）は、VPC内のサブネット間のトラフィックをフィルタリングするためのセキュリティレイヤーです。NACLは、サブネット単位で適用され、インバウンドおよびアウトバウンドのトラフィックルールを設定します。NACLは、セキュリティグループとは異なり、状態を保持しないため、無差別的に通信を許可または拒否します。NACLを適切に設定しないと、ネットワーク通信が遮断され、サービス間の接続に問題が生じることがあります。
3. セキュリティグループ
セキュリティグループは、AWSインスタンス（EC2インスタンスやNLBなど）に対する仮想ファイアウォールで、インスタンスごとにトラフィックを制御します。セキュリティグループは、インバウンドおよびアウトバウンドのルールを設定し、設定されたポートやIPアドレスからの通信を許可または拒否します。セキュリティグループは状態保持型なので、通信を許可するルールを設定すれば、その通信のレスポンスも自動的に許可されます。
4. ネットワークロードバランサー（NLB）とVPCエンドポイント
NLBは、高いスループットと低遅延を提供するためのロードバランサーです。NLBは、VPC内でのトラフィックの分散に使用され、特にTCPおよびUDPトラフィックに対応しています。**VPCエンドポイント（インターフェースエンドポイント）**は、PrivateLink経由でサービスに接続するためのエンドポイントで、NLBが設定されたサービスへのアクセスを制御します。NLBとVPCエンドポイントの間で通信が正しく行われるためには、それぞれのセキュリティグループやNACLが適切に設定されている必要があります。
実践
略
一問道場
問題 #255
トピック 1
ある会社が、数百のAWSアカウントからログを受信して分析する、Amazon EC2上で動作する集中型ログサービスを作成しています。AWS PrivateLinkを使用して、クライアントサービスとログサービス間の接続を提供しています。
各AWSアカウントのクライアントに対して、ログサービス用のインターフェースエンドポイントが作成されており、利用可能です。ログサービスは、ネットワークロードバランサー（NLB）を介して異なるサブネットに展開されたEC2インスタンス上で実行されています。クライアントはVPCエンドポイントを使用してログを送信できません。
この問題を解決するためにソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（2つ選んでください）
A. ログサービスサブネットにNACL（ネットワークアクセスコントロールリスト）がアタッチされており、NLBサブネットとの通信が許可されていることを確認します。また、NLBサブネットにNACLがアタッチされており、ログサービスサブネットのEC2インスタンスとの通信が許可されていることを確認します。
B. ログサービスサブネットにNACLがアタッチされており、インターフェースエンドポイントサブネットとの通信が許可されていることを確認します。また、インターフェースエンドポイントサブネットにNACLがアタッチされており、ログサービスサブネットのEC2インスタンスとの通信が許可されていることを確認します。
C. EC2インスタンス上で実行されているログサービスのセキュリティグループを確認し、NLBサブネットからのインバウンド通信を許可するように設定されていることを確認します。
D. EC2インスタンス上で実行されているログサービスのセキュリティグループを確認し、クライアントからのインバウンド通信を許可するように設定されていることを確認します。
E. NLBのセキュリティグループを確認し、インターフェースエンドポイントサブネットからのインバウンド通信を許可するように設定されていることを確認します。
解説
AとCが正解なのですね。以下の理由を簡潔に説明します。
A. NACLの設定確認（NLBサブネットとログサービスサブネット間の通信を許可）
- NLBを通じてEC2インスタンスが動作しているログサービスに接続するためには、NACL（ネットワークアクセスコントロールリスト）で通信が許可されている必要があります。
- NACLはサブネットレベルで通信を制御するため、NLBサブネットとログサービスサブネット間の通信が可能であることを確認することが重要です。
C. セキュリティグループの設定確認（NLBサブネットからのインバウンド通信を許可）
- NLBからの通信がEC2インスタンス上のログサービスに届くよう、セキュリティグループでインバウンド通信を許可する必要があります。
- セキュリティグループはインスタンスレベルで通信を制御するため、NLBのサブネットからの通信が遮断されないように設定を確認します。
他の選択肢について
- B: インターフェースエンドポイントサブネットとログサービスサブネット間のNACL設定を確認する内容ですが、問題文では「クライアントはVPCエンドポイントを使用できない」とあるため、適用範囲外。
- D: クライアントから直接ログサービスへの通信を許可する内容ですが、PrivateLink経由での通信には該当しない。
- E: NLBのセキュリティグループ設定を確認する内容ですが、NLB自体はセキュリティグループを持たないため無効。
結論
正解は A と C です。
ネットワークの基盤（NACL）とセキュリティグループの設定を確認することが、問題の解決に繋がります。
256-AWS SAP AWS 「理論・実践・一問道場」SSE-C
理論
Amazon S3の暗号化とコスト最適化に関する本質的知識
1. サーバーサイド暗号化（SSE）の種類
- SSE-S3 (Amazon S3 Managed Keys):
- S3が暗号化キーを管理。
- コストが低い。KMSリクエスト料金なし。
- 簡単な運用が可能。
- SSE-KMS (AWS Key Management Service):
- AWS KMSキーを使用。
- 高度なセキュリティ機能（キーの制御、監査）。
- リクエストごとにKMS料金が発生し、アクセス頻度が高い場合コストが増加。
- SSE-C (Customer-Provided Keys):
- ユーザーが暗号化キーを管理。
- コストは抑えられるが、キー管理が煩雑になる可能性あり。
2. コスト最適化のポイント
- 頻繁なKMSリクエストの削減:
- アクセス頻度が高い場合、SSE-S3を選択することでKMS料金を削減可能。
- アプリケーションの変更を最小限に抑えられる。
- アクセス頻度に基づくストレージクラス選択:
- S3標準: 頻繁アクセス用（高コスト）。
- S3インテリジェントティアリング: アクセスパターンに応じて自動的にコスト最適化。
- S3 Glacier: 長期間アクセスが不要なデータ用。
3. 関連技術
- S3バッチ操作:
- 大量のオブジェクトを効率的に移行可能。
- 既存データの再暗号化や新しいバケットへのコピー時に使用。
- CloudHSM:
- 専用ハードウェアでキーを管理。高度なセキュリティが必要な場合に選択肢となるが、運用コストや手間が増加。
実践
略
一問道場
問題 #256
トピック 1
ある会社が、Amazon S3バケットに数百万個のオブジェクトを保存しています。これらのオブジェクトはS3標準ストレージクラスに属しています。すべてのS3オブジェクトは頻繁にアクセスされています。また、これらのオブジェクトにアクセスするユーザーやアプリケーションの数が急速に増加しています。オブジェクトは、AWS KMSキー（SSE-KMS）を使用したサーバーサイド暗号化で暗号化されています。
ソリューションアーキテクトが会社の月次AWS請求書を確認したところ、Amazon S3からのリクエスト数が増加しているため、AWS KMSのコストが増加していることに気づきました。ソリューションアーキテクトは、アプリケーションへの変更を最小限に抑えつつ、コストを最適化する必要があります。
次のうち、最小限の運用負荷でこの要件を満たすソリューションはどれですか？
A. サーバーサイド暗号化に顧客提供キー（SSE-C）を使用する新しいS3バケットを作成します。既存のオブジェクトを新しいS3バケットにコピーし、SSE-Cを指定します。
B. サーバーサイド暗号化にAmazon S3管理キー（SSE-S3）を使用する新しいS3バケットを作成します。S3バッチ操作を使用して、既存のオブジェクトを新しいS3バケットにコピーし、SSE-S3を指定します。
C. AWS CloudHSMを使用して暗号化キーを保存します。新しいS3バケットを作成します。S3バッチ操作を使用して、既存のオブジェクトを新しいS3バケットにコピーし、CloudHSMのキーを使用してオブジェクトを暗号化します。
D. S3バケットにS3インテリジェントティアリングストレージクラスを使用します。90日間アクセスされていないオブジェクトをS3 Glacier Deep Archiveに移行するS3インテリジェントティアリングアーカイブ設定を作成します。
解説
問題のポイント（#256）
会社はS3 Standardストレージクラスを使っており、オブジェクトへのアクセス頻度が高いため、AWS KMS（SSE-KMS）のリクエストコストが急増しています。これを解決するために、コスト最適化を行いつつ、アプリケーションへの変更を最小限に抑える方法を探す必要があります。
各選択肢の評価
- 選択肢A: SSE-Cを利用する
- コスト削減: AWS KMS料金は不要になる。
- デメリット: ユーザーがキーを管理する必要があり、運用負荷が高い。
- 適していない（運用負荷が増える）。
- 選択肢B: SSE-S3を利用する
- コスト削減: AWS KMSの代わりにAmazon S3がキーを管理するため、KMS料金が発生しない。
- メリット: Amazon S3が暗号化を完全に管理するため、運用負荷は増えない。
- 最適な選択肢。
- 選択肢C: AWS CloudHSMを利用する
- コスト削減: AWS KMSを使用しないためKMS料金は削減される。
- デメリット: CloudHSMの導入コストと運用負荷が高い。
- 適していない（コストがかさむ）。
- 選択肢D: S3 Intelligent-Tieringを利用する
- アクセス頻度に応じてストレージ料金を最適化できるが、KMSリクエスト料金には影響しない。
- 問題の本質を解決しない。
解答
- 正解: B（SSE-S3を利用する） Amazon S3がキー管理を行い、KMSコストを削減しつつ運用負荷を増やさないため、最も効率的な解決策です。
解説のまとめ
AWS KMSコストを抑えるには、KMS以外の暗号化方式（例: SSE-S3）に移行するのがベストです。SSE-S3は運用負荷が低く、コスト削減に直結します。他の選択肢は、運用負荷やコスト面で課題があります。
257-AWS SAP AWS 「理論・実践・一問道場」Lambdaの同時実行制限
理論
1. DynamoDBのキャパシティユニット（RCU / WCU）
- *RCU（読み取りキャパシティユニット）とWCPU（書き込みキャパシティユニット）**は、DynamoDBのパフォーマンスを決定する重要なリソースです。適切に調整しないと、リクエストの遅延やスロットリングが発生し、システム全体のパフォーマンスが低下します。
- RCU：DynamoDBで読み取るリクエスト数を処理する能力（1秒あたり）。
- WCU：DynamoDBに書き込むリクエスト数を処理する能力（1秒あたり）。
- 高トラフィックなアプリケーションでは、これらをスケールアップすることが必須です。
2. Lambdaの同時実行制限
- AWS Lambdaは、デフォルトで同時に実行できる関数の数に制限があります。大量のリクエストがあると、同時実行制限に達し、処理が遅延します。これを解決するためには、トラフィックを調整できる仕組み（例：Amazon SQS）を導入して、Lambdaの処理負荷を分散させることが重要です。
3. Amazon SQS（Simple Queue Service）
- SQSは、メッセージングサービスで、リクエストのバッファリングに使用できます。Lambdaにリクエストが集中しすぎるのを防ぐために、SQSキューを使ってリクエストを順番に処理できます。これにより、同時実行数を制御し、システムの安定性を保つことができます。
4. 非同期処理の管理
- 非同期処理は、システムが並行してタスクを実行する能力を向上させます。特に大量のアップロードを処理する際に、SQSなどでリクエストを一時的に保管し、Lambdaがそれを順次処理することで、急激な負荷に耐えられるようにします。
これらの知識を駆使して、アプリケーションのスケーラビリティと可用性を向上させることが、システムのパフォーマンス向上に不可欠です。
実践
略
一問道場
問題 #257
トピック 1
メディアストレージアプリケーションが、ユーザーの写真をAmazon S3にアップロードし、AWS Lambda関数によって処理されています。アプリケーションの状態はAmazon DynamoDBテーブルに保存されています。ユーザーから、一部のアップロード写真が正常に処理されていないという報告がありました。アプリケーション開発者がログを調査した結果、何千人ものユーザーが同時に写真をアップロードした際に、Lambdaの同時実行制限やDynamoDBのデータ保存時のパフォーマンスの問題が原因で、写真処理に問題が発生していることが分かりました。
アプリケーションのパフォーマンスと信頼性を向上させるために、ソリューションアーキテクトはどのようなアクションを取るべきでしょうか？（2つ選んでください）
選択肢
A. DynamoDBテーブルのRCU（読み取りキャパシティーユニット）を評価して調整する。
B. DynamoDBテーブルのWCU（書き込みキャパシティーユニット）を評価して調整する。
C. Amazon ElastiCacheレイヤーを追加して、Lambda関数のパフォーマンスを向上させる。
D. Amazon Simple Queue Service（Amazon SQS）キューと再処理ロジックをAmazon S3とLambda関数の間に追加する。
E. S3 Transfer Accelerationを使用して、ユーザーに低遅延を提供する。
解説
- B. DynamoDBテーブルのWCUを評価して調整する
- D. SQSキューと再処理ロジックを追加する
理由：
- B. DynamoDBのWCU調整：
- DynamoDBでの**書き込みキャパシティユニット（WCU）**が不足している場合、同時に多くのユーザーが写真をアップロードしていると、書き込みパフォーマンスが低下します。WCUを増加させることで、データ保存のパフォーマンスを向上させ、Lambdaが処理する際に遅延を減少させます。
- D. SQSの導入：
- *Amazon SQS（Simple Queue Service）**を使用して、アップロードされた写真をキューに入れて処理を管理することができます。これにより、Lambdaの同時実行制限を緩和し、SQSがバッファーとして機能して、Lambda関数が順番に処理できるようになります。この方法でトラフィックの急増を効率的に処理できます。
これらの対策により、アプリケーションのパフォーマンスと信頼性が向上し、同時処理能力や書き込みパフォーマンスの問題を解決することができます。
258-AWS SAP AWS 「理論・実践・一問道場」AWS Amplify
理論
AWS AmplifyとAWS Transfer Familyの比較表を以下に示します。どちらもAWSのサービスですが、用途や機能が異なります。
特長 | AWS Amplify | AWS Transfer Family |
目的 | フルスタックアプリケーションの開発とホスティング | ファイル転送（SFTP, FTPS, FTP）サービス |
主な用途 | モバイル・ウェブアプリケーションの構築とホスティング | セキュアなファイル転送をAWSに統合 |
データ保存 | Amazon S3やDynamoDBとの統合 | Amazon S3と統合（ファイルストレージ） |
認証 | Amazon Cognitoによるユーザー認証 | IAMロールとアクセス制御 |
API & バックエンド | AWS AppSyncやLambdaを使ったバックエンドサービス | 利用なし（ファイル転送に特化） |
スケーラビリティ | 自動スケーリング、フルスタックサポート | スケーラブルなファイル転送サービス |
主な利点 | フルスタック開発、簡単なデプロイと管理 | 既存のファイル転送プロトコルのサポート |
使用シナリオ | モバイルやウェブアプリの開発、ホスティング | セキュアなファイル転送が必要な場合 |
要点:
- AWS Amplifyは、アプリケーション開発とホスティングを支援するサービスで、フルスタックの開発を加速します。
- AWS Transfer Familyは、FTP、SFTP、FTPSなどのプロトコルを使用して、セキュアなファイル転送をサポートするサービスです。
1. AWSへのアプリケーション移行
オンプレミスのアプリケーションをAWSに移行する際、AWSが提供するさまざまな移行サービスを活用できます。AWS Application Migration Service (旧称: Server Migration Service) は、物理または仮想サーバをAWSクラウドに移行するための自動化されたサービスで、最小の手間で迅速に移行を完了させることができます。
2. Auto Scalingとロードバランシング
AWSのAuto Scalingは、トラフィックや負荷に応じて自動的にインスタンスの数を増減させることで、高可用性とスケーラビリティを実現します。これにより、サーバーの過負荷やダウンタイムを防ぎ、スムーズなユーザー体験を提供できます。また、Application Load Balancerはリクエストを複数のEC2インスタンスに分散させ、パフォーマンスを最適化します。
3. ファイルの保存と管理
アプリケーションでのファイル保存には、Amazon S3が広く利用されます。S3はスケーラブルで高可用性があり、オブジェクトストレージサービスとして大容量のデータを効率的に保存できます。ファイルをS3に保存することにより、オンプレミスのファイルサーバを管理する負担を軽減し、可用性と耐障害性を高めることができます。
4. ユーザー認証と管理
ユーザー認証には、Amazon Cognitoが便利です。Cognitoはユーザーのサインアップ、サインイン、アクセス制御を簡単に管理できるサービスで、アプリケーションに組み込むことで、認証を迅速に実装できます。また、AWS IAM Identity Center (AWS Single Sign-On) を使って、統一的なサインイン機能を提供することもできます。
5. 静的ウェブサイトの構築
AWSでは、静的コンテンツを提供するために、Amazon S3を使って静的ウェブサイトをホスティングできます。また、AWS Amplifyを利用すると、フロントエンドアプリケーションの開発、ホスティング、認証機能の統合が簡単に行え、迅速な開発が可能です。さらに、Amazon CloudFrontを利用すれば、静的ウェブサイトをグローバルに配信し、低遅延でユーザーに提供できます。
6. アプリケーション開発の加速
AWSのツールを活用することで、アプリケーションの開発と運用が加速されます。例えば、AWS Amplifyを使うことで、フロントエンドとバックエンドの開発が迅速に進み、デプロイ作業も簡単に行えます。これにより、アプリケーションの開発が加速し、ビジネスの変化に迅速に対応できます。
この問題では、アプリケーションの移行とその後のスケーリング、認証、ストレージ管理に関する選択肢が提示されています。最小限の運用オーバーヘッドでこれらの要件を満たすためには、AWSのマネージドサービスを活用して、アプリケーションの移行と管理を簡素化し、ユーザー認証やファイル保存を効率的に行うことが重要です。
実践
略
一問道場
Question #258
トピック 1
ある企業がオンプレミスのデータセンターでアプリケーションを運用しています。このアプリケーションでは、ユーザーがメディアファイルをアップロードできる機能を提供しています。ファイルはファイルサーバに保存されますが、アプリケーションサーバが過剰に負荷がかかっており、その結果、データのアップロードが時々失敗しています。企業はファイルサーバに新しいストレージを頻繁に追加していますが、これらの課題を解決するためにアプリケーションをAWSに移行したいと考えています。アメリカとカナダのユーザーがこのアプリケーションにアクセスしており、アプリケーションにファイルをアップロードできるのは認証されたユーザーのみである必要があります。企業はアプリケーションをリファクタリングすることを検討しており、アプリケーション開発を加速させる必要があります。
最小の運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか？
A. AWS Application Migration Service を使用してアプリケーションサーバを Amazon EC2 インスタンスに移行し、EC2 インスタンス用に Auto Scaling グループを作成します。アプリケーションロードバランサーを使ってリクエストを分散し、アプリケーションを変更して、ファイルを Amazon S3 に保存します。ユーザー認証には Amazon Cognito を使用します。
B. AWS Application Migration Service を使用してアプリケーションサーバを Amazon EC2 インスタンスに移行し、EC2 インスタンス用に Auto Scaling グループを作成します。アプリケーションロードバランサーを使ってリクエストを分散し、AWS IAM Identity Center（AWS Single Sign-On）を設定してユーザーにアプリケーションへのサインイン機能を提供します。アプリケーションを変更して、ファイルを Amazon S3 に保存します。
C. メディアファイルのアップロード用に静的ウェブサイトを作成し、静的アセットを Amazon S3 に保存します。AWS AppSync を使って API を作成し、AWS Lambda リゾルバを使ってメディアファイルを Amazon S3 にアップロードします。ユーザー認証には Amazon Cognito を使用します。
D. AWS Amplify を使ってメディアファイルのアップロード用の静的ウェブサイトを作成し、Amplify Hosting を使って Amazon CloudFront 経由でウェブサイトを配信します。アップロードされたメディアファイルは Amazon S3 に保存します。ユーザー認証には Amazon Cognito を使用します。
解説
会社は、メディアファイルのアップロード用の静的ウェブサイトを作成するためにAWS Amplifyを使用するべきです。会社は、Amplify Hostingを使用して、ウェブサイトをAmazon CloudFront経由で配信するべきです。アップロードされたメディアファイルは、Amazon S3に保存され、ユーザー認証にはAmazon Cognitoを使用します。このソリューションは、最も運用負荷が少ない方法で要件を満たします。なぜなら、AWS Amplifyはフルスタックアプリケーションを簡単に構築、展開、ホストできる完全なソリューションを提供し、AWSのサービスを活用する柔軟性があり、クラウドの専門知識がなくても利用できます。
AWS Amplifyを使用することで、アプリケーションをサーバーレスアーキテクチャにリファクタリングでき、運用の複雑さとコストを削減できます。AWS Amplifyは次の特徴と利点を提供します：
- Amplify Studio：フロントエンドUIとバックエンドを含むフルスタックアプリを視覚的に構築し、展開できるインターフェース。
- Amplify CLI：数コマンドでアプリのバックエンドを構成および管理できるローカルツールチェーン。
- Amplify Libraries：クラウド対応のモバイルおよびウェブアプリを構築するためのオープンソースのクライアントライブラリ。
- Amplify UI Components：機能豊富なアプリを迅速に構築するためのクラウド接続コンポーネントを持つオープンソースのデザインシステム。
- Amplify Hosting：迅速で安全、かつ信頼性の高い静的およびサーバーサイドレンダリングアプリのためのフルマネージドCI/CDとホスティング。
AWS Amplifyを使用してメディアファイルのアップロード用静的ウェブサイトを作成することで、Amplify Studioを活用してピクセル完璧なUIを視覚的に構築し、数回のクリックでクラウドバックエンドに接続できます。Amplify Hostingを使用して、Amazon CloudFrontを通じてウェブサイトを配信することで、AWSのコンテンツ配信ネットワーク（CDN）を利用し、世界中の何百もの拠点から高速で安全な配信が可能になります。アップロードされたメディアファイルは、Amazon S3に保存することで、スケーラブルで耐久性が高く、コスト効果の高いオブジェクトストレージサービスの利点を享受できます。さらに、Amazon Cognitoを使用してユーザー認証を行うことで、ユーザーサインアップ、サインイン、およびアクセス制御をスケーラブルに追加でき、数百万のユーザーをサポートする完全にマネージドなサービスを利用できます。
他の選択肢が不適切な理由は以下の通りです：
- AWS Application Migration Serviceを使用してアプリケーションサーバをAmazon EC2インスタンスに移行する方法は、アプリケーションをリファクタリングするものではなく、開発を加速するわけでもありません。AWS MGNは、物理サーバや仮想マシン（VM）をAWSに移行するサービスですが、この方法では過負荷やデータアップロード失敗の問題を解決できません。また、サーバーレスアーキテクチャに比べて運用負荷やコストが削減されるわけでもありません。
- メディアファイルのアップロード用に静的ウェブサイトを作成し、AWS AppSyncを使ってAPIを作成する方法は、AWS Amplifyを使用するよりも設定や管理が複雑になります。AWS AppSyncは柔軟なAPIを作成するサービスですが、Amplify StudioやAmplify Hostingのような簡単な設定ができません。また、Amazon Cognitoのような認証機能も提供されません。
- *AWS IAM Identity Center (AWS Single Sign-On)**を使用してアプリケーションにサインインできるようにする方法は、Webやモバイルアプリのエンドユーザー認証には適していません。AWS SSOは複数のAWSアカウントやビジネスアプリケーションのアクセス管理に特化したサービスで、エンドユーザーの認証にはAmazon Cognitoの方が適しています。
以上が、この選択肢が最適な理由です。
259-AWS SAP AWS 「理論・実践・一問道場」EC2ログの管理
理論
1. スケーラブルなアーキテクチャの基本
クラウドでのスケーリング、特にオートスケーリングにおいて重要なのは、リソース（EC2インスタンス）が動的に増減することです。スケールアウト時にはインスタンスが増え、スケールイン時には減少します。これにより、インスタンスの状態やローカルストレージが変わるため、ローカルストレージに依存したデータ管理は不安定になります。
2. ログの管理と永続化
スケーリングイベントによってインスタンスが削除されると、そのインスタンスに保存されていたログも消失してしまいます。このため、ログを外部に永続的に保存することが必須です。これを実現するために、以下のような手法があります：
- Amazon CloudWatch Logs: EC2インスタンスやアプリケーションログをCloudWatch Logsに送信することで、インスタンスのスケーリングに依存せず、ログを中央で管理・保存できます。これにより、インスタンスが削除されてもログが失われず、後で分析や監視が可能になります。
- Amazon S3: ALBのアクセスログやアプリケーションログをS3に保存する方法です。S3は非常に高い耐久性（11 9’s）を提供し、ログを長期にわたって保存できます。S3に保存したログは、どのインスタンスがスケールインしてもアクセス可能です。
3. 耐障害性と可用性
AWSでは、インフラをスケールさせるためにリソースが頻繁に変更されるため、データの耐障害性と可用性を確保するための設計が求められます。スケールインによりインスタンスが削除されても、外部のログストレージ（CloudWatch LogsやS3）に保存されていれば、ログは失われません。
- 耐障害性: ログがインスタンスに依存しない外部のストレージサービス（CloudWatch LogsやS3）に保存されていれば、インスタンスの障害やスケーリングに関わらず、ログデータは安全に保持されます。
- 可用性: 分散型のストレージ（例えばCloudWatchやS3）を使用することで、ログの可用性を高め、スケールに対応したシステム全体でログの分析が可能になります。
実践
略
一問道場
質問 #259
トピック 1
ある会社は、Amazon EC2インスタンスにデプロイされたアプリケーションを、アプリケーションロードバランサー（ALB）の背後に配置しています。インスタンスはオートスケーリンググループの一部です。このアプリケーションは予測不可能なワークロードを持ち、頻繁にスケールインおよびスケールアウトします。会社の開発チームは、アプリケーションのパフォーマンスを改善する方法を見つけるために、アプリケーションログを分析したいと考えています。しかし、インスタンスがスケールインした後、ログはもはや利用できません。
スケールインイベント後に開発チームがアプリケーションログを表示できるようにするソリューションはどれですか？
- A. ALBのアクセスログを有効にし、ログをAmazon S3バケットに保存する
- B. EC2インスタンスを設定して、統合されたCloudWatchエージェントを使用してAmazon CloudWatch Logsにログを公開する
- C. オートスケーリンググループを変更して、ステップスケーリングポリシーを使用する
- D. アプリケーションにAWS X-Rayトレーシングを組み込む
解説
問題:
アプリケーションのEC2インスタンスがスケーリングされるたびに、ログが失われてしまいます。これを防ぐ方法として、最適な選択肢を選ぶ必要があります。
正しい選択肢:
B. EC2インスタンスがCloudWatch Logsにログを送信する設定をする
解説:
EC2インスタンスがスケーリングイン（インスタンスが削除される）しても、インスタンス上のログが失われないようにするためには、CloudWatch Logs にログを送信する方法が適しています。
- CloudWatch Logs は、インスタンスがスケーリングインされてもログがクラウドに保存され続けるため、後で確認できます。
- CloudWatch エージェントをEC2インスタンスに設定し、ログをリアルタイムでCloudWatchに送信することが可能です。
これにより、スケーリングイン後でも、ログが失われることなくアクセス可能になります。
他の選択肢:
- A. ALBのアクセスログを有効にし、ログをS3に保存する
- これは、ALBが生成するアクセスログをS3に保存する方法です。これもログを保存する手段の一つですが、アプリケーションログそのものを分析することが目的であれば、ALBのログではなく、アプリケーションのログが必要です。ALBのログはHTTPリクエストに関する情報を記録しますが、アプリケーションの内部ログ（エラーやパフォーマンス関連のログなど）は含まれません。
- C. Auto Scalingグループでステップスケーリングポリシーを使用する
- スケーリングポリシーの設定は、ログの永続化には直接影響しません。スケーリングのタイミングやインスタンス数の調整に関するものです。
- D. アプリケーションにAWS X-Rayトレースを組み込む
- X-Rayはアプリケーションのトレースやパフォーマンスの分析を行いますが、アプリケーションログの保存とは関係ありません。X-Rayはパフォーマンス向上に寄与するツールですが、ログ永続化の解決策ではありません。
結論:
アプリケーションログの永続化を解決するには、B. EC2インスタンスがCloudWatch Logsにログを送信する設定をする が最適な選択です。
260-AWS SAP AWS 「理論・実践・一問道場」CORSエラー
理論
CORSエラーの解決方法
CORS（クロスオリジンリソースシェアリング）エラーは、異なるドメイン間でリソースを共有しようとしたときに発生します。例えば、
www.example.com という静的サイトから別のドメインのAPI（api.example.com）にリクエストを送る場合、ブラウザはセキュリティ上、リクエストをブロックします。解決方法
CORSエラーを解決するためには、API側でリクエスト元ドメイン（例：
www.example.com）を明示的に許可する設定を行う必要があります。これを行う方法は次の通りです：- API Gateway でCORS設定を有効にし、
Access-Control-Allow-Originヘッダーを設定する。
- Lambda関数のレスポンスで
Access-Control-Allow-Originヘッダーを設定する。
- S3バケットにCORS設定を追加する（静的ウェブサイトホスティングの場合）。
これらの設定により、ブラウザはCORSエラーを解消し、リクエストを正常に処理できるようになります。
以下は、上記の内容を自然な日本語に訳したものです。
例として、前提のコードが以下のようになっています：
この場合、
https://api.example.com のレスポンスヘッダーには、次のような情報が含まれている必要があります：もしこのレスポンスヘッダーが含まれていない場合、ブラウザは前端のスクリプトがAPIのレスポンスデータにアクセスすることを拒否します。その結果、CORS（クロスオリジンリソースシェアリング）エラーが発生します。
- CloudFront：
CloudFrontがリクエストを適切なCORSヘッダーと共に転送するように設定します。CloudFrontはリクエストをオリジンサーバー（API GatewayやS3）に転送するだけなので、オリジンサーバーからの応答が正しいCORSヘッダーを含んでいることを確認する必要があります。
- API Gateway：
API GatewayでCORSを有効にし、レスポンスに
Access-Control-Allow-Origin: https://www.example.comを設定します。これにより、他のドメインからのリクエストが許可されるようになります。- S3：
S3のCORS設定を構成し、
www.example.comからのリクエストを許可します。S3にホストされている静的ウェブサイトのリソースに対して、他のドメインからのアクセスを許可するための設定です。これらの設定を行うことで、CORSエラーを回避し、正しく跨域リクエストを処理できるようになります。
実践
略
一問道場
会社は、ユーザー向けの登録フォームを含む認証なしの静的ウェブサイト（www.example.com）を運営しています。このウェブサイトはAmazon S3でホスティングされ、コンテンツ配信ネットワークとしてAmazon CloudFrontを使用し、AWS WAFが設定されています。登録フォームが送信されると、ウェブサイトはAmazon API GatewayのAPIエンドポイントを呼び出し、AWS Lambda関数がペイロードを処理して外部APIに転送します。
テスト中、ソリューションアーキテクトはクロスオリジンリソースシェアリング（CORS）エラーに直面しました。ソリューションアーキテクトは、CloudFrontディストリビューションのオリジンにAccess-Control-Allow-Originヘッダーがwww.example.comに設定されていることを確認しました。
このエラーを解決するために、ソリューションアーキテクトは何をすべきでしょうか？
A. S3バケットのCORS設定を変更し、AllowedOrigin要素にwww.example.comのルールを追加する。
B. AWS WAFでCORS設定を有効にし、Web ACLルールでAccess-Control-Allow-Originヘッダーをwww.example.comに設定する。
C. API Gateway APIエンドポイントでCORS設定を有効にし、APIエンドポイントが返すすべてのレスポンスにAccess-Control-Allow-Originヘッダーをwww.example.comに設定するように構成する。
D. Lambda関数でCORS設定を有効にし、関数の戻りコードにAccess-Control-Allow-Originヘッダーをwww.example.comに設定するようにする。
解説
正解は C です。
解説
CORSエラーは、異なるオリジン（ドメイン）間でリソースを共有する際に発生します。リクエストが送信されるサーバー（この場合はAPI Gateway）は、リクエスト元のオリジンを許可する必要があります。API Gatewayは、CORS（クロスオリジンリソース共有）を設定することで、他のオリジンからのリクエストを許可できます。
選択肢 C の内容は以下の通りです：
- API GatewayでCORS設定を有効にする：API Gatewayエンドポイントが、リクエスト元のオリジンを許可する
Access-Control-Allow-Originヘッダーを含むレスポンスを返すように設定します。これにより、ウェブサイトからAPI Gatewayを呼び出す際に、CORSエラーを解決できます。
他の選択肢が不正解な理由：
- A：S3のCORS設定は静的コンテンツに関連しますが、API GatewayのCORS設定が問題の根本的な原因です。
- B：AWS WAFはCORS設定を管理する機能を提供していません。CORSの設定はS3やAPI Gatewayで行います。
- D：Lambda関数内ではCORS設定を行いません。CORS設定はAPI GatewayまたはS3側で行います。
従って、API GatewayでCORS設定を有効にするのが正解です。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/174d7ae8-88e2-80e8-ab71-e0fa68a28992
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
