16-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

161-AWS SAP AWS 「理論・実践・一問道場」NLB ALBタイプターゲットグループ

理論

AWSを使用したオンプレミスとクラウド間のトラフィック管理の基本

オンプレミスのデータセンターとAWSクラウド間でトラフィックを安全かつ効率的に管理することは、多くの企業にとって重要な課題です。この課題に対応するには、ネットワーク構成の適切な設計とAWSのロードバランサーの活用が鍵となります。本記事では、このテーマに関連する重要な知識を解説します。

1. ロードバランサーの種類と役割

AWSには主に3種類のロードバランサーがあります。それぞれの特徴を理解することで、要件に応じた最適なソリューションを設計できます。

Application Load Balancer（ALB）

特徴: HTTP/HTTPSトラフィックを処理し、パスベースやホストベースのルーティングをサポート。アプリケーション層（レイヤー7）に特化。
主な用途: Webアプリケーション、APIバックエンド。

Network Load Balancer（NLB）

特徴: 静的IPアドレスを提供し、TCPトラフィックを高速かつ低レイテンシーで処理。ネットワーク層（レイヤー4）に特化。
主な用途: 高スループットが求められるシステム、オンプレミスとの接続が必要な環境。

Gateway Load Balancer（GWLB）

特徴: セキュリティアプライアンスやネットワーク機能を提供するサードパーティ製品をインラインでデプロイするための専用ロードバランサー。
主な用途: サードパーティのファイアウォールやIPS/IDSソリューション。

2. 静的IPアドレスの必要性

オンプレミスのファイアウォールやネットワークアプライアンスは、許可リスト（Allow List）に基づいてトラフィックを制御することが一般的です。このため、静的IPアドレスが必要となる場合があります。

ALBの制約 ALBは動的IPアドレスを使用するため、オンプレミスのファイアウォール設定に直接使用するのは困難です。解決策として、NLBを介して静的IPアドレスを提供する構成が推奨されます。

3. NLBを使用したALBとの統合

NLBとALBを統合することで、静的IPアドレスを使用しつつ、ALBの高度なルーティング機能を維持することが可能です。具体的には以下の手順を実行します：

NLBを作成

複数のアベイラビリティゾーンにまたがる静的IPアドレスを設定します。

ALBタイプのターゲットグループを作成

NLBがリクエストをALBに転送できるように設定します。

オンプレミスのファイアウォール設定を更新

NLBの静的IPアドレスを許可リストに追加します。

クライアント接続をNLBに更新

これにより、トラフィックはNLBを経由してALBにルーティングされます。

4. セキュリティと耐障害性の考慮

セキュリティ

VPCセキュリティグループやネットワークACLでトラフィックを制御します。
AWS WAFを活用してアプリケーション層の攻撃を防ぎます。

耐障害性

複数のアベイラビリティゾーンにまたがるリソースを配置します。
Auto ScalingグループでEC2インスタンスを動的にスケールします。

5. まとめ

オンプレミスからAWSへのトラフィック管理を最適化するには、AWSのロードバランサーを正しく活用することが重要です。特に、NLBを使用して静的IPアドレスを提供し、ALBと統合する構成は、効率的かつ安全なネットワーク設計の基本となります。このアプローチを用いることで、オンプレミスの既存システムとAWSクラウドをシームレスに統合することが可能です。

実践

略

一問道場

解説

問題の解説

背景

オンプレミスのファイアウォールでIPアドレスの許可リスト（Allow List）を設定する必要がある環境で、AWS Direct Connectを使用してAWS内のアプリケーションにアクセスしています。現在、ALBが動的IPアドレスを使用しているため、静的IPアドレスが必要です。

要件

静的IPアドレスを使用してオンプレミスからAWSリソースにアクセス可能にする。

ALBのパスベースルーティングなどの機能を維持する。

選択肢の評価

A. ALBに静的IPアドレスを設定

→ ALBは静的IPアドレスをサポートしていないため、不適切。

B. NLBを作成し、ALBタイプのターゲットグループを追加

→ NLBで静的IPアドレスを提供し、ALBの高度なルーティング機能を維持できるため、適切。

C. NLBのみを使用し、ALBを削除

→ ALBのパスベースルーティングが必要なため、不適切。

D. GWLBを使用

→ GWLBは主にセキュリティアプライアンスを挿入するための用途であり、不適切。

正解

B. NLBを作成し、ALBタイプのターゲットグループを追加

→ 静的IPアドレスの提供とALBのルーティング機能を両立でき、要件を満たします。

162-AWS SAP AWS 「理論・実践・一問道場」WAF

理論

AWS WAFとALB/CloudFrontの適用ポイント

1. WAFの適用先

CloudFrontに適用:

グローバルスコープでトラフィックを早期ブロック。
不要なトラフィックをALBに到達させず、運用コストを削減。

ALBに適用:

アプリケーション層での詳細なトラフィック制御。
リージョン限定の管理に有効。

2. ALBを直接公開しない方法

CloudFront経由:

ALBのセキュリティグループでCloudFront IPのみ許可。
WAFはCloudFrontに適用し、攻撃トラフィックをフィルタリング。

3. 結論

CloudFrontにWAFを適用し、ALBをCloudFront経由で保護する設計が最適。これにより、セキュリティ強化と運用負荷軽減を同時に実現できます。

実践

略

一問道場

質問 #162

トピック 1

ある企業は、インターネットに接続された Application Load Balancer (ALB) の背後にあるプライベートサブネット内の Amazon EC2 インスタンス群でアプリケーションを実行しています。

ALB は Amazon CloudFront ディストリビューションのオリジンとして機能しています。

CloudFront ディストリビューションには、さまざまな AWS 管理ルールを含む AWS WAF Web ACL が関連付けられています。

企業は、インターネットトラフィックが直接 ALB にアクセスするのを防ぐソリューションを必要としています。

最小限の運用オーバーヘッドでこの要件を満たすソリューションを選択してください。

選択肢

A. 既存の Web ACL と同じルールを含む新しい Web ACL を作成し、新しい Web ACL を ALB に関連付ける。

B. 既存の Web ACL を ALB に関連付ける。

C. ALB のセキュリティグループに、CloudFront の AWS 管理プレフィックスリストからのトラフィックを許可するルールを追加する。

D. ALB のセキュリティグループに、さまざまな CloudFront IP アドレス範囲のみを許可するルールを追加する。

解説

問題の解説

この問題では、インターネットから直接ALBにアクセスされないようにする方法を問われています。

要件

アプリケーションはALBを通じてトラフィックを処理。

ALBの前にCloudFrontとAWS WAFが設定済み。

ALBへの直接アクセスを防ぐ必要がある。

運用負荷が低いソリューションが求められる。

選択肢の評価

A: 新しいWeb ACLを作成し、ALBに関連付ける

非効率的: 同じルールを複製する必要があり、運用負荷が増加。

B: 既存のWeb ACLをALBに関連付ける

部分的解決: WAFで制御は可能だが、CloudFrontで既に適用しているため、冗長。

C: ALBのセキュリティグループにCloudFrontのマネージドプレフィックスリストを許可

適切: AWSが管理するCloudFrontのIP範囲のみを許可。運用負荷が少なく、セキュリティ的に優れている。

D: ALBのセキュリティグループにCloudFront IPアドレス範囲を手動で許可

運用負荷が高い: CloudFrontのIP範囲は定期的に更新されるため、手動管理が必要。

最適解

C: ALBのセキュリティグループにCloudFrontのマネージドプレフィックスリストを許可 CloudFront経由のみでアクセスを許可し、ALBの直接アクセスを防ぐ運用コストが低いソリューション。

163-AWS SAP AWS 「理論・実践・一問道場」in transitの暗号化とAUTHトークン

理論

1. Amazon ElastiCache for Redis - 暗号化

Amazon ElastiCache for Redisでは、暗号化を使用して、データの保護を強化できます。暗号化には2種類の方法があります：

暗号化 at rest: これは、保存中のデータ（ディスク上のデータ）を暗号化する方法です。データがディスクに書き込まれる際に自動的に暗号化されます。これにより、ストレージのセキュリティが向上します。

暗号化 in transit: これは、ネットワークを介して送受信されるデータを暗号化する方法です。Redisのクライアントとサーバー間で転送されるデータが、インターネットや内部ネットワークを通じて盗聴されるのを防ぎます。これにより、データが送信中に改竄されたり盗聴されたりするリスクを軽減できます。

2. 認証（AUTH）

ElastiCache for Redisでは、認証を設定してキャッシュへのアクセスを制限できます。これを実現するために、AUTHトークンを使用します。このトークンは、Redisに接続する際に使用され、ユーザーが正当なアクセス権を持っているかを確認する役割を果たします。

AUTHトークンの管理: AUTHトークンはセキュリティを向上させるために必要で、Redisクライアントは接続時にこのトークンを提供し、正当なアクセス者であることを証明します。これにより、無許可のアクセスが防止されます。

3. AWS Secrets ManagerとAWS Systems Manager Parameter Store

AWS Secrets Manager: セキュアにシークレット（例えば、データベースの認証情報、APIキーなど）を管理するサービスです。Secrets Managerは、シークレットを暗号化して保管し、必要に応じてアプリケーションにアクセスさせます。トークンやパスワードをSecrets Managerに保管し、アプリケーションで動的に利用するケースに最適です。

AWS Systems Manager Parameter Store: シークレットや構成データを管理できるAWSサービスです。Parameter Storeには、テキストデータやパスワード、認証情報を安全に保存できます。Parameter Storeには暗号化されたパラメータを格納する機能もあり、機密情報の取り扱いに向いています。

4. SSL証明書

SSL/TLS証明書は、データの転送中の暗号化を提供するために使用されます。Redisクラスターとそのクライアント間で安全な通信を行うためにSSL/TLS証明書を使用することができます。証明書は、通信相手の認証、通信の暗号化、およびデータの整合性を提供します。

5. 運用管理のベストプラクティス

セキュリティの最小化: クラスター設定や認証情報は、セキュリティの観点から最小限のアクセス権で管理し、必要なときにのみアクセスできるようにします。例えば、認証トークンやSSL証明書を動的に取得できるように管理することは、運用の柔軟性を高めるとともにセキュリティを強化します。

自動化と管理の効率化: AWSのSecrets ManagerやSystems Managerを使用して、アプリケーションの認証情報や構成を動的に管理することにより、運用の負担を軽減し、変更があった場合の管理コストを削減できます。

まとめ

この問題の本質は、Redisクラスターの暗号化 in transitと認証を適切に設定し、セキュリティを強化する方法にあります。AWSサービス（Secrets Manager、Systems Manager Parameter Store）を使用して認証情報を安全に管理し、エンドツーエンドで暗号化を実現することが重要です。

実践

略

一問道場

問題 #163

ある会社は、Amazon ElastiCache for Redis クラスターをキャッシュ層として使用しているアプリケーションを運用しています。最近のセキュリティ監査により、会社はElastiCacheにおいて暗号化を有効にしていますが、転送中の暗号化を設定していないことが判明しました。また、ユーザーは認証なしでキャッシュにアクセスできる状態です。

ソリューションアーキテクトは、ユーザー認証を要求し、エンドツーエンドの暗号化を確保するための変更を行う必要があります。

この要件を満たすソリューションはどれですか？

A. AUTHトークンを作成し、AWS Systems Manager Parameter Storeに暗号化されたパラメータとして保存します。新しいクラスターを作成し、AUTHを有効にして転送中の暗号化を設定します。アプリケーションを更新して、必要に応じてAUTHトークンをParameter Storeから取得し、認証に使用します。

B. AUTHトークンを作成し、AWS Secrets Managerにトークンを保存します。既存のクラスターを更新してAUTHトークンを使用し、転送中の暗号化を有効にします。アプリケーションを更新して、必要に応じてSecrets ManagerからAUTHトークンを取得し、認証に使用します。

C. SSL証明書を作成し、AWS Secrets Managerに証明書を保存します。新しいクラスターを作成し、転送中の暗号化を設定します。アプリケーションを更新して、必要に応じてSecrets ManagerからSSL証明書を取得し、証明書を使って認証します。

D. SSL証明書を作成し、AWS Systems Manager Parameter Storeに暗号化された高度なパラメータとして証明書を保存します。既存のクラスターを更新して転送中の暗号化を設定します。アプリケーションを更新して、必要に応じてParameter StoreからSSL証明書を取得し、証明書を使って認証します。

解説

この問題の解説を以下にまとめます。

要件

認証を有効にする: 現在、ElastiCache for Redisのキャッシュにアクセスするユーザーは認証なしでアクセスできており、セキュリティリスクとなっています。

in transitの暗号化を有効にする: データが転送中に暗号化されていないため、通信経路でのデータ漏洩のリスクがあります。

解決策

ElastiCache for Redisでは、認証と暗号化 in transitの両方を設定できます。これにより、キャッシュのセキュリティが強化されます。

各選択肢の分析

選択肢A:

AUTHトークンを作成して、AWS Systems Manager Parameter Storeに保存し、新しいElastiCacheクラスターでAUTHを設定します。
これにより認証は実現できますが、Parameter Storeを使用して保存することは暗号化管理の面でAWS Secrets Managerほど適切ではありません。Secrets Managerは機密情報を管理するために最適化されており、認証情報に最適です。
暗号化in transitに関する設定が記載されていないため、不完全な解決策です。

選択肢B (正解):

AWS Secrets Managerに保存したAUTHトークンを使用し、ElastiCacheで認証を設定します。Secrets Managerは機密情報（トークンなど）の管理に特化しているため、より安全です。
in transitの暗号化を有効にして、転送中のデータを保護します。
この選択肢は要件を満たし、認証と暗号化の両方を適切に設定するため、最も効果的です。

選択肢C:

SSL証明書を使用し、Secrets Managerに保存しますが、SSL証明書は認証トークンの代わりには適切ではありません。SSL証明書は主にサーバーとクライアント間で暗号化を提供するためのもので、キャッシュ認証に使用するのには適しません。
また、SSL証明書は認証を提供するものではないため、認証要件を満たしません。

選択肢D:

SSL証明書をSystems Manager Parameter Storeに保存し、認証に使用する点が問題です。
Parameter Storeは機密情報の格納に使えますが、Secrets Managerに比べてセキュリティが劣ります。また、SSL証明書は認証の目的には使用できません。

結論

選択肢Bは、認証とin transitの暗号化の両方を適切に設定する方法を提供しており、最も効果的な解決策です。

164-AWS SAP AWS 「理論・実践・一問道場」Spot起動失敗

理論

Amazon EC2 スポットインスタンスを使用したワークロードの信頼性を向上させる方法についてです。特に、インスタンスの起動失敗とシステム遅延の問題に関連しています。

信頼性向上の要素

スポットインスタンスの中断リスク: スポットインスタンスはAWSの余剰キャパシティを利用するため、キャパシティが必要になった場合にインスタンスが中断されることがあります。このため、アプリケーションの信頼性を確保するには、インスタンス中断時の回復方法や代替手段が重要です。

Auto Scalingの役割: Auto Scalingはインスタンス数の自動的な増減を管理しますが、スポットインスタンスに依存している場合、その中断リスクがシステムの遅延やインスタンス起動失敗の原因になります。信頼性向上には、インスタンスの選択肢を柔軟にする必要があります。

解決策

属性ベースのインスタンスタイプ選択

属性ベースのインスタンスタイプ選択を使用することで、Auto Scalingグループは利用可能な最適なインスタンスタイプを選択できます。これにより、特定のインスタンスタイプが利用できない場合でも他のインスタンスタイプに切り替えが可能となり、インスタンスの起動失敗を避けることができます。これにより、スポットインスタンスの中断による影響も減少します。

実践

略

一問道場

問題 #164

トピック 1

ある企業は、Amazon EC2スポットインスタンスを使用して計算ワークロードを実行しています。これらのインスタンスは、オートスケーリンググループ内にあり、起動テンプレートでは2つのプレースメントグループと単一のインスタンスタイプを使用しています。最近、監視システムがオートスケーリングインスタンスの起動失敗を報告し、システムユーザーの待機時間が長くなることと相関していることがわかりました。この企業は、ワークロードの全体的な信頼性を向上させる必要があります。

どのソリューションがこの要件を満たしますか？

A. 起動テンプレートを起動構成に置き換え、属性ベースのインスタンスタイプ選択を使用するオートスケーリンググループを設定する。

B. 新しい起動テンプレートバージョンを作成し、属性ベースのインスタンスタイプ選択を使用する。オートスケーリンググループを新しい起動テンプレートバージョンを使用するように設定する。

C. 起動テンプレートのオートスケーリンググループを更新して、プレースメントグループの数を増やす。

D. 起動テンプレートを更新して、より大きなインスタンスタイプを使用する。

解説

この問題では、Amazon EC2のスポットインスタンスを使っているワークロードの信頼性を向上させる方法についての選択肢を問われています。具体的には、スポットインスタンスが中断されたり、インスタンス起動に失敗することでシステムに遅延が生じている問題に対処するための最適な解決策を選ぶ必要があります。

各選択肢の評価

A. Launch ConfigurationでAuto Scalingグループを属性ベースのインスタンスタイプ選択に変更

Launch Configurationを使用する代わりに、Launch Templateを使うことが推奨されているため、この選択肢は不適切です。

Launch Templateはインスタンスタイプの選択やAuto Scalingグループの設定においてより柔軟で最新の方法です。

B. 新しいLaunch Templateバージョンを作成して、Auto Scalingグループで新しいバージョンを使用する

Launch Templateのバージョンを更新して、属性ベースのインスタンスタイプ選択を導入する方法が最適です。これにより、Auto Scalingグループが最適なインスタンスタイプを自動的に選択できるようになり、インスタンス起動の失敗を避けられます。

C. プレースメントグループの数を増加させる

プレースメントグループを増やすことによってインスタンスが複数の障害ドメインに分散され、冗長性が高まります。しかし、スポットインスタンスの中断リスクに対して直接的な解決策にはなりません。

プレースメントグループの数を増加させても、スポットインスタンスが中断された場合の影響を完全に解消することはできません。

D. より大きなインスタンスタイプに変更する

インスタンスタイプを変更することでパフォーマンスが向上するかもしれませんが、スポットインスタンスの中断問題には対応できません。インスタンスタイプを変更しても、インスタンスが中断されるリスクを回避することはできません。

最適な解決策

最も適切な解決策は、B. 新しいLaunch Templateバージョンを作成して、Auto Scalingグループで新しいバージョンを使用するです。

この方法では、Auto Scalingグループが属性ベースのインスタンスタイプ選択を使ってインスタンスを起動し、インスタンス起動の失敗を避けることができます。これにより、利用可能なインスタンスタイプを柔軟に選べるため、スポットインスタンスが中断されても他のインスタンスタイプに切り替えが可能となり、信頼性が向上します。

結論

スポットインスタンスの中断リスクを軽減するためには、インスタンスタイプの柔軟な選択が重要です。そのため、属性ベースのインスタンスタイプ選択を導入することで、より安定したワークロード運用が実現できます。

165-AWS SAP AWS 「理論・実践・一問道場」APIとファイルGETWAY

理論

1. Amazon S3 APIの利用

Amazon S3は、データをオブジェクト形式で保存するためのサービスで、S3 APIを利用してデータを保存、取得、管理できます。特に、大量のデータを効率的に扱うためには、APIを直接利用することが重要です。

2. ローカルアクセスとクラウド間の連携

アプリケーションが生成したデータをローカルで保持する必要がある一方で、そのデータを迅速にAmazon S3にアップロードして、ユーザーがダウンロードできる状態にする必要があります。ローカルで生成したデータを迅速にクラウドに移動させる仕組みが必要です。

3. Amazon S3 File Gateway

Amazon S3 File Gatewayは、オンプレミスのファイルシステムとS3をシームレスに統合するサービスです。これにより、オンプレミスのサーバーからS3へのデータの転送が簡素化され、ローカルとクラウドのファイルシステムの同期が取れるようになります。

4. Amazon FSx for Lustre

FSx for Lustreは、非常に高性能なファイルシステムを提供しますが、一般的なファイルストレージや軽量なデータ処理には過剰な性能を発揮してしまうことがあります。そのため、ファイルの保存と管理が重要なシナリオにおいては、S3 File Gatewayのほうが適している場合が多いです。

5. AWS DataSync

AWS DataSyncはデータ転送の自動化ツールであり、大量のデータを迅速に移行したり同期したりするために使用されます。ただし、ファイルをローカルで生成しながら直接クラウドにアップロードするというシンプルなユースケースでは、AWS S3 File Gatewayがより適切です。

まとめ

オンプレミスとAmazon S3をシームレスに連携させるためには、Amazon S3 File Gatewayが最も適しており、簡単な設定で効果的に利用できます。

実践

略

一問道場

ある企業が、ドキュメント処理ワークロードをAWSに移行しています。この企業は、Amazon S3 APIを使用してドキュメントを保存、取得、変更するように多くのアプリケーションを更新しました。処理サーバーは、1秒あたり約5つのドキュメントを生成しています。処理が完了すると、顧客はAmazon S3から直接ドキュメントをダウンロードできます。

移行中に、企業は、処理サーバーが即座にS3 APIをサポートできないことを発見しました。サーバーはLinux上で動作しており、サーバーが生成するファイルに対して高速なローカルアクセスが必要です。サーバーが処理を終了した後、ファイルは30分以内に公開され、ダウンロード可能でなければなりません。

この要件を最小の労力で満たすための解決策はどれですか？

A. アプリケーションをAWS Lambda関数に移行し、AWS SDK for Javaを使用してファイルを生成、変更、およびアクセスし、直接Amazon S3に保存します。

B. Amazon S3 File Gatewayをセットアップし、ドキュメントストアにリンクされたファイル共有を構成します。ファイル共有をAmazon EC2インスタンスにNFSでマウントし、Amazon S3で変更が発生した場合、RefreshCache API呼び出しを実行してS3 File Gatewayを更新します。

C. Amazon FSx for Lustreを設定し、インポートおよびエクスポートポリシーを構成します。新しいファイルシステムをS3バケットにリンクし、Lustreクライアントをインストールして、ドキュメントストアをAmazon EC2インスタンスにNFSでマウントします。

D. AWS DataSyncを設定してAmazon EC2インスタンスに接続し、タスクを構成して生成されたファイルをAmazon S3と同期します。

解説

この問題の解説を簡潔に説明します。

要件：

ドキュメント処理サーバーが生成するファイルをAmazon S3に保存する必要がありますが、サーバーはS3 APIを直接サポートしていません。

サーバーはローカルでファイルに迅速にアクセスする必要があり、処理後は30分以内にファイルが公開される必要があります。

解決策：

選択肢 B が最適です。

B. Amazon S3 File Gatewayを設定し、ファイル共有を構成して、ドキュメントストアにリンクします。ファイル共有をAmazon EC2インスタンスにNFSでマウントし、Amazon S3で変更が発生した際にRefreshCache API呼び出しを行います。

理由：

Amazon S3 File Gatewayは、オンプレミスの環境とAmazon S3をシームレスに統合するためのサービスです。これを使用することで、ローカルでファイルを操作し、S3に格納されたファイルと同期を取ることができます。

NFS（Network File System）を使用して、EC2インスタンスからファイルをアクセスできるようにします。これにより、Linuxサーバーがローカルファイルシステムを使用してファイルを処理し、その後S3に保存できます。

RefreshCache APIを使って、ファイルの変更をS3 File Gatewayで反映させることができ、ファイルを迅速に公開できます。

その他の選択肢：

A: AWS Lambdaを使用する提案ですが、AWS Lambdaはステートレスな環境であり、ファイルをローカルで迅速に操作するには適していません。また、Lambdaの処理にはオーバーヘッドがあるため、パフォーマンスが低下する可能性があります。

C: Amazon FSx for Lustreは高パフォーマンスなファイルシステムを提供しますが、ドキュメント処理のようなシンプルなユースケースにはオーバースペックです。また、S3と連携させるのに追加の構成が必要です。

D: AWS DataSyncはファイルの同期を自動化するサービスですが、ファイル生成と即時アップロードの要件に対しては、S3 File Gatewayの方が簡便で適しています。

結論：

Amazon S3 File Gatewayを使用することにより、ローカルでの迅速なファイル操作とS3への簡単な同期が可能になり、要件を最も効果的に満たすことができます。

166-AWS SAP AWS 「理論・実践・一問道場」削除整合性

理論

1. 分散システムにおけるデータ整合性

分散システムは、複数のコンポーネントが協調して動作するため、データの一貫性（整合性）を維持するのが難しくなります。特に、データが複数の場所に保存されている場合（例えば、DynamoDBと他のストレージサービスに保存されている場合）、そのデータを削除したり更新したりするときに、整合性をどのように保つかが重要な課題です。

最終的整合性は、データが全てのシステムに伝播され、最終的に一貫性が保たれることを意味します。しかし、即時の整合性が必要な場合、どのように効率的にデータの削除や更新を反映させるかを設計することが求められます。

2. イベント駆動型アーキテクチャとその利点

本質的なアーキテクチャ的なアプローチとして、イベント駆動型アーキテクチャが挙げられます。イベント駆動型システムでは、各マイクロサービスが独立して動作し、状態の変更（イベント）をトリガーとして、他のサービスが適切に反応します。

イベントは状態の変化を示し、それをトリガーとしてサービス間の連携を行います。このアーキテクチャのメリットは、システム間の結合度を低く保ちながら、状態同期を効率的に行える点です。

例えば、ユーザー情報の削除イベントが発生した場合、それを通知するメカニズム（SNSやEventBridgeなど）を使用して、他のマイクロサービスがそのイベントを受け取って自動的に処理を実行します。これにより、各サービスは独自にデータを管理しつつ、必要な時にデータの変更を即座に反映できます。

3. 削除処理の即時性と一貫性

ユーザー情報削除の要求に対して、即座にそのデータを削除する必要がある場合、その削除処理を複数のサービス間で同期させるための手段を考える必要があります。特にプライバシーやセキュリティの観点から、削除漏れや遅延が発生することは許容されません。

削除の即時反映: 一度削除操作が行われたら、関連するすべてのマイクロサービスでその情報が即座に消去されることが求められます。この要件は、特に個人情報の削除やデータプライバシー法に基づいて重要な要素となります。

4. AWSサービスの役割と選択肢

AWSは、イベント駆動型アーキテクチャを実現するための様々なサービスを提供しています。以下にそれらの役割を説明します。

DynamoDB Streams: DynamoDBのデータ変更をリアルタイムでキャプチャし、これを他のサービスに通知することで、削除イベントを他のシステムに即座に伝え、データの一貫性を確保します。

SNS（Simple Notification Service）: SNSは、発生したイベントを複数の購読者（マイクロサービス）に通知するメッセージブローカーです。複数のサービスがこの通知を受けて処理を行い、データの削除を反映します。

EventBridge: より柔軟で複雑なイベントルールを作成できるサービスで、削除イベントをカスタムイベントバスを使ってシステム全体に伝達することが可能です。

5. 「即時削除」の要件を満たすためのアーキテクチャ的選択

本質的な考え方として、削除処理の即時性とデータの整合性を保証するために、以下の要素が重要です。

リアルタイムでのイベント通知: ユーザー削除イベントを即座に他のサービスに通知すること。これにより、削除されたデータの情報が即座に他のサービスにも伝わり、削除処理が行われます。

非同期処理の活用: 削除イベントは非同期に処理されることが多いため、削除の通知が他のサービスに伝わった後、各サービスはそれを受けて非同期に削除処理を実行します。この方式により、負荷を分散しつつ、全体の一貫性を保つことができます。

結論

本質的な理解は、データ整合性を保ちつつ、複数のサービス間で即座にデータの削除を反映させるためには、イベント駆動型のアーキテクチャを採用し、AWSのサービスをうまく組み合わせることが必要であるという点です。削除処理のリアルタイム性を担保し、セキュリティやプライバシーの観点からも適切な処理が行えるように設計することが求められます。

実践

略

一問道場

問題 #166の要点

配送会社がAWSクラウドでサーバーレスソリューションを運用しています。このソリューションは、ユーザーデータ、配送情報、過去の購入履歴を管理しています。ソリューションは複数のマイクロサービスで構成されています。中央のユーザーサービスは、機密データをAmazon DynamoDBテーブルに保存します。他の複数のマイクロサービスは、機密データの一部をさまざまなストレージサービスにコピーして保存します。

会社は、リクエストに応じてユーザー情報を削除できる機能を必要としています。中央のユーザーサービスがユーザーを削除した際、他のすべてのマイクロサービスは、即座にそのデータのコピーを削除しなければなりません。

この要件を満たすソリューションはどれですか？

A. DynamoDBテーブルでDynamoDB Streamsを有効にし、DynamoDBストリームにAWS Lambdaトリガーを作成して、ユーザー削除に関するイベントをAmazon Simple Queue Service（Amazon SQS）キューに投稿します。各マイクロサービスはキューをポーリングして、DynamoDBテーブルからユーザーを削除します。

B. DynamoDBテーブルでDynamoDBイベント通知を設定し、Amazon Simple Notification Service（Amazon SNS）トピックをDynamoDBイベント通知のターゲットとして作成します。各マイクロサービスはSNSトピックにサブスクライブし、DynamoDBテーブルからユーザーを削除します。

C. 中央のユーザーサービスがユーザーを削除する際に、カスタムのAmazon EventBridgeイベントバスにイベントを投稿するように設定します。各マイクロサービスは、ユーザー削除イベントパターンに一致するEventBridgeルールを作成し、マイクロサービス内のロジックを呼び出して、DynamoDBテーブルからユーザーを削除します。

D. 中央のユーザーサービスがユーザーを削除する際に、Amazon Simple Queue Service（Amazon SQS）キューにメッセージを投稿するように設定します。各マイクロサービスはSQSキューでイベントフィルターを作成し、DynamoDBテーブルからユーザーを削除します。

167-AWS SAP AWS 「理論・実践・一問道場」HTTP/HTTPSベースの処理ALBに固定IP

理論

1. IPアドレスの提供方法

Elastic IPアドレス（EIP）や静的IPアドレスは、特定のAWSサービスに対して外部顧客がアクセスできるようにするために使用されます。特に、Network Load Balancer（NLB） や AWS Global Accelerator は、外部顧客に提供するために静的なIPアドレスを割り当てる方法をサポートしています。

一方で、Application Load Balancer（ALB）には静的IPアドレスを直接割り当てることはできません。ALBはDNSベースでトラフィックを管理します。

2. AWS Global Accelerator

AWS Global Acceleratorは、グローバルなアプリケーションのパフォーマンスを向上させるためのサービスです。アクセラレーターを利用することで、静的なIPアドレスを提供でき、トラフィックの最適化やリージョン間のアクセスを効率化します。

顧客には、Global Acceleratorが提供する静的IPアドレスを利用することで、複数のリージョンにまたがるサービスにアクセスすることが可能になります。

WAFの機能を保留したまま固定IPを外部に提供する場合には便利です

実践

略

一問道場

問題 #167

トピック 1

ある企業が、VPC内でウェブアプリケーションを運用しています。ウェブアプリケーションは、Application Load Balancer（ALB）の背後にある一群のAmazon EC2インスタンスで動作しています。ALBはAWS WAFを使用しています。

外部の顧客がウェブアプリケーションに接続する必要があります。企業は、すべての外部顧客にIPアドレスを提供しなければなりません。

最小の運用負担でこの要件を満たす解決策はどれですか？

A. ALBをNetwork Load Balancer（NLB）に置き換え、NLBにElastic IPアドレスを割り当てる。

B. Elastic IPアドレスを割り当て、そのElastic IPアドレスをALBに割り当て、顧客にElastic IPアドレスを提供する。

C. AWS Global Accelerator標準アクセラレーターを作成し、ALBをアクセラレーターのエンドポイントとして指定する。アクセラレーターのIPアドレスを顧客に提供する。

D. Amazon CloudFrontディストリビューションを設定し、ALBをオリジンとして設定する。ディストリビューションのDNS名をピンして、ディストリビューションの公開IPアドレスを取得し、そのIPアドレスを顧客に提供する。

解説

正解は C. AWS Global Accelerator標準アクセラレーターを作成し、ALBをアクセラレーターのエンドポイントとして指定する。アクセラレーターのIPアドレスを顧客に提供する。

解説:

AWS Global Acceleratorは、インターネットトラフィックのグローバルな最適化を提供します。これにより、外部の顧客に対して静的IPアドレスを提供し、複数のリージョンでトラフィックを最適化できます。アクセラレーターのIPアドレスを提供することで、ALB（アプリケーションロードバランサー）の背後にあるEC2インスタンスにアクセスできます。これにより、顧客に静的IPアドレスを提供し、最小の運用負担で要求を満たすことができます。

他の選択肢は次のように不適切です:

A: NLBにElastic IPアドレスを割り当てることはできますが、ALBの機能（HTTP/HTTPSベースの処理やWAFのサポートなど）を提供することはできません。

B: ALB自体にはElastic IPアドレスを直接割り当てることはできません。

D: CloudFrontはIPアドレスを提供しません。CloudFrontはDNS名を提供し、通常はユーザーにIPアドレスを直接提供する方法としては使われません。

そのため、最適な解決策はCです。

168-AWS SAP AWS 「理論・実践・一問道場」AWS Control Tower

理論

AWS Control Towerは、複数のAWSアカウントを管理し、組織全体にわたるセキュリティとガバナンスを確保するためのサービスです。主に以下の機能を提供します：

ランディングゾーン: 新しいAWSアカウントを安全にセットアップするためのベストプラクティスを提供します。これには、AWS Organizationsの設定や、必要なアカウント管理のためのベースラインが含まれます。

ガードレール: AWS Control Towerは、組織のポリシーに従ったリソース管理を支援するために、「ガードレール」と呼ばれる管理制御を提供します。これにより、リソースの作成、変更、削除に対する制限が強化され、企業のセキュリティポリシーを実行できます。

SCP（Service Control Policies）: AWS Organizations内でサービスへのアクセスを制御するポリシーを設定できます。これにより、特定のアクション（例：EBSの暗号化）に対するアクセス制限を設けることができます。

EBS暗号化: Amazon EBSの暗号化は、データを保存する際のセキュリティ対策の一環として重要です。EBSボリュームの暗号化は、データを保護し、規制遵守を助けます。AWSでは、EBSの暗号化を強制するためにAWS ConfigやAWS Organizationsを利用できます。

実践

略

一問道場

問題 #168

トピック 1

ある企業が開発用のAWSアカウントをいくつか持っており、現在の本番アプリケーションをAWSに移行する予定です。企業は、現在の本番アカウントと将来の本番アカウントに対してAmazon Elastic Block Store（Amazon EBS）の暗号化を強制する必要があります。企業は、組み込みのブループリントとガードレールを含むソリューションを必要としています。

これらの要件を満たすために必要なステップの組み合わせはどれですか？（3つ選んでください。）

A. AWS CloudFormation StackSetsを使用して、本番アカウントにAWS Configルールをデプロイする。

B. 既存の開発者アカウントで新しいAWS Control Towerランディングゾーンを作成し、アカウント用のOUを作成する。次に、本番アカウントと開発アカウントをそれぞれ本番OUと開発OUに追加する。

C. 企業の管理アカウントで新しいAWS Control Towerランディングゾーンを作成し、本番アカウントと開発アカウントをそれぞれ本番OUと開発OUに追加する。

D. 既存のアカウントをAWS Organizationsに招待して、SCPを作成し、コンプライアンスを確保する。

E. 管理アカウントでEBS暗号化を検出するガードレールを作成する。

F. 本番OUでEBS暗号化を検出するガードレールを作成する。

解説

この問題は、企業がAWS環境内でEBSの暗号化を強制するために必要な手順を選択する問題です。要件に基づいて、必要なステップを分析します。

選択肢の分析:

A. AWS CloudFormation StackSetsを使用して、本番アカウントにAWS Configルールをデプロイする。

分析: CloudFormation StackSetsは複数のアカウントやリージョンにリソースを展開できるツールです。AWS Configを使用してEBS暗号化の監視を行うルールをデプロイすることは可能ですが、暗号化を強制する手段としては直接的ではないため、必須とは言えません。

B. 既存の開発者アカウントで新しいAWS Control Towerランディングゾーンを作成し、アカウント用のOUを作成する。次に、本番アカウントと開発アカウントをそれぞれ本番OUと開発OUに追加する。

分析: AWS Control Towerは複数のアカウントを管理し、ガードレールを適用するためのサービスです。しかし、開発者アカウントではなく、管理アカウントでControl Towerをセットアップするべきです。したがって、このステップは誤りです。

C. 企業の管理アカウントで新しいAWS Control Towerランディングゾーンを作成し、本番アカウントと開発アカウントをそれぞれ本番OUと開発OUに追加する。

分析: AWS Control Towerを使用して、ガードレールを設定してコンプライアンスを確保するためのステップです。管理アカウントでControl Towerをセットアップし、アカウントを適切な組織単位（OU）に追加することは正しいアプローチです。

D. 既存のアカウントをAWS Organizationsに招待して、SCPを作成し、コンプライアンスを確保する。

分析: AWS OrganizationsでService Control Policies (SCP)を使用して、アカウントに対して暗号化ポリシーを強制することは可能です。これにより、SCPを利用してコンプライアンスを確保できます。

E. 管理アカウントでEBS暗号化を検出するガードレールを作成する。

分析: Control Towerでは、ガードレールを使ってAWS環境のポリシーを管理します。EBS暗号化を強制するガードレールを作成することは、この問題の要件に合っています。

F. 本番OUでEBS暗号化を検出するガードレールを作成する。

分析: 本番OUに対してガードレールを設定することは、EBS暗号化の適用を強制するために正しいアプローチです。

正解の組み合わせ:

C. 企業の管理アカウントで新しいAWS Control Towerランディングゾーンを作成し、本番アカウントと開発アカウントをそれぞれ本番OUと開発OUに追加する。

D. 既存のアカウントをAWS Organizationsに招待して、SCPを作成し、コンプライアンスを確保する。

これらのステップは、企業の要件である「EBS暗号化を強制する」ための正しい手順を網羅しています。

169-AWS SAP AWS 「理論・実践・一問道場」レプリカとスナップショット

理論

スナップショットとレプリカは、データ保護やシステムの耐障害性を向上させるための重要な手法ですが、それぞれ異なる目的と動作を持っています。以下にその違いを説明します。

1. スナップショット

スナップショットは、特定の時点でのデータの完全なコピーを保存するものです。AWSでは、主にEBSスナップショットやRDSスナップショットを使用します。

目的: スナップショットは主にバックアップ目的で使用され、特定の時点に戻るための復旧手段として機能します。スナップショットを使うことで、データが失われた場合や、システムが壊れた場合に、その時点の状態に復元できます。

動作: スナップショットは、通常、保存したい時点のデータを「キャプチャ」し、保存します。AWSのEBSスナップショットは、差分バックアップ（変更された部分のみ保存）を行うため、効率的に保存できます。

利点:

短期間で復元可能（復元ポイントが明確）。
低コスト（変更されたデータのみ保存するため）。
他のリージョンに複製して災害復旧にも使用できる。

欠点:

リアルタイムでのデータ変更反映はされないため、最新データにすぐアクセスしたい場合には適していません。

2. レプリカ

レプリカは、データをリアルタイムで他の場所にコピーし、常に同期を取る方法です。AWSのRDSのリードレプリカやクロスリージョンリードレプリカが典型的な例です。

目的: レプリカは主に可用性の向上と、読み取りトラフィックの分散、障害発生時の迅速なフェイルオーバーを目的とします。レプリカは、常にプライマリ（元）のデータベースと同期し、同じデータをリアルタイムで保持します。

動作: レプリカは、元のデータベースで発生した変更（書き込み操作）を即座に反映します。これにより、データベースの負荷分散や、障害時の迅速な切り替えが可能になります。

利点:

リアルタイムで同期され、常に最新のデータを保持。
読み取り専用のレプリカを利用することで、読み取り負荷の分散が可能。
障害発生時に迅速なフェイルオーバーが可能（特にクロスリージョンレプリカ）。

欠点:

書き込み操作は元のデータベースに集中するため、レプリカ側では書き込みはできません（読み取り専用）。
他のリージョンにレプリカを作成すると、レイテンシが発生する可能性があり、完全なリアルタイム性を確保するのは難しい場合もあります。

スナップショットとレプリカの主な違い

特徴	スナップショット	レプリカ
目的	データのバックアップ、災害復旧	高可用性、負荷分散、リアルタイム同期
同期性	特定の時点の静的なコピー	リアルタイムまたはほぼリアルタイムのデータ同期
更新頻度	変更があった場合に手動でスナップショットを取る	元データベースの変更が即座にレプリカに反映される
可用性	復元ポイントが指定された時点のもの	障害発生時に即座に切り替えが可能
使用例	バックアップ、データの保護、特定時点への復元	可用性の向上、フェイルオーバー、読み取り負荷の分散
コスト	比較的低い（保存した時点の差分のみ）	常にデータが同期されるため、追加リソース（別のインスタンス）を必要とする

まとめ

スナップショットはバックアップやデータ保護の手段であり、特定の時点に戻すことができます。

レプリカは、高可用性や負荷分散を目的とし、リアルタイムでデータが同期され、フェイルオーバーに利用されます。

用途に応じてスナップショットとレプリカを使い分けることが重要です。

実践

略

一問道場

問題 #169

トピック 1

ある企業が、Amazon EC2インスタンス2台を使用して、アプリケーションロードバランサー(ALB)の背後で状態を保持する重要なWebアプリケーションを実行しています。企業は、Amazon RDS for MySQLデータベースをホストしています。企業は、Amazon Route 53でアプリケーションのDNSレコードを管理しています。

ソリューションアーキテクトは、アプリケーションの耐障害性を改善するためのソリューションを推奨する必要があります。

このソリューションは、次の目的を満たす必要があります：

アプリケーション層：RPO（復旧時点目標）2分、RTO（復旧時間目標）30分

データベース層：RPO（復旧時点目標）5分、RTO（復旧時間目標）30分

企業は、既存のアプリケーションアーキテクチャに大きな変更を加えたくありません。また、フェイルオーバー後の最適なレイテンシを保証する必要があります。

どのソリューションがこれらの要件を満たしますか？

A. EC2インスタンスをAWS Elastic Disaster Recoveryを使用して構成し、RDS DBインスタンスのクロスリージョンリードレプリカを作成します。2番目のAWSリージョンにALBを作成し、AWS Global Acceleratorエンドポイントを作成して、そのエンドポイントをALBに関連付けます。DNSレコードをGlobal Acceleratorエンドポイントを指すように更新します。

B. EC2インスタンスをAmazon Data Lifecycle Manager(Amazon DLM)を使用してEBSボリュームのスナップショットを取得するように構成します。RDSの自動バックアップを構成し、バックアップの複製を別のAWSリージョンに作成します。2番目のリージョンにALBを作成し、AWS Global Acceleratorエンドポイントを作成して、そのエンドポイントをALBに関連付けます。DNSレコードをGlobal Acceleratorエンドポイントを指すように更新します。

C. EC2インスタンスとRDS DBインスタンスのバックアッププランをAWS Backupで作成します。バックアップの複製を別のAWSリージョンに作成します。2番目のリージョンにALBを作成し、ALBの前にAmazon CloudFrontディストリビューションを構成します。DNSレコードをCloudFrontを指すように更新します。

D. EC2インスタンスをAmazon Data Lifecycle Manager(Amazon DLM)を使用してEBSボリュームのスナップショットを取得するように構成します。RDS DBインスタンスのクロスリージョンリードレプリカを作成します。2番目のAWSリージョンにALBを作成し、AWS Global Acceleratorエンドポイントを作成して、そのエンドポイントをALBに関連付けます。

解説

この問題においては、レプリカを使用する方が適しています。理由は以下の通りです。

問題の要件:

アプリケーション層 (RPO: 2分、RTO: 30分)

データベース層 (RPO: 5分、RTO: 30分)

高可用性と迅速なフェイルオーバーを求めている。

既存のアーキテクチャには大きな変更を加えたくない。

レプリカが適している理由:

リアルタイムのデータ同期 (RPOの短縮)

レプリカは、データのリアルタイム同期を提供するため、アプリケーションやデータベースがダウンした場合でも、レプリカに即座に切り替えることができます。これにより、データの損失を最小限に抑え（RPOを短縮）、システムの可用性を高めます。

特にデータベース層において、RPOが5分という要件があるため、クロスリージョンリードレプリカを使用することで、フェイルオーバー時のデータ損失を最小限に抑えることができます。

RTOの短縮

クロスリージョンのレプリカを利用すると、RTOが30分の要件を満たすために、迅速にフェイルオーバーを実施できます。新しいリージョンでレプリカが即座に読み取りを提供できるため、アプリケーションの復旧が早く、全体のダウンタイムを短縮できます。

変更が少ない

現行のインフラに大きな変更を加えることなく、レプリカを追加するだけで、高可用性を実現できます。これは、既存アーキテクチャに最小限の影響を与えつつ、災害復旧計画を強化できるため、要件に適しています。

スナップショットの問題点:

スナップショットはバックアップ目的で使用されるものであり、リアルタイムのデータ同期を提供しません。したがって、RPOが長くなり、最悪のケースでデータ損失が発生する可能性があります。

RTOが30分の場合でも、スナップショットを復元するには時間がかかるため、完全な復旧に30分以上かかる可能性があります。

まとめ:

レプリカ (特にクロスリージョンリードレプリカ) を使用することで、RPOが短縮され、RTOの要件も満たしやすくなるため、この問題に最適です。

スナップショットはバックアップ用途には適しているものの、フェイルオーバー時の迅速な復旧には不向きです。

170-AWS SAP AWS 「理論・実践・一問道場」Trusted AdvisorとCompute Optimizer

理論

AWS Trusted Advisor の推薦事項

低利用のEC2インスタンス: 使用率が低いインスタンスを停止または削減。

未使用のEBSボリューム: 使用されていないボリュームの削除。

セキュリティグループ設定: 不適切なセキュリティ設定の修正。

AWS Compute Optimizer の推薦事項

インスタンスタイプの最適化: 使用率に基づき最適なインスタンスタイプを提案。

リソース過剰/不足の検出: 不要なリソースを削減し、必要なリソースを追加する提案。

本質的知識: EC2インスタンスの最適化とコスト最適化

AWS EC2インスタンスのコスト最適化とパフォーマンスの最適化は、効率的なクラウドリソースの使用を確保するために非常に重要です。AWSには、EC2インスタンスを適切にサイズ設定し、コストを最適化するためのさまざまなツールと方法が用意されています。

1. CPU、メモリ、ネットワークのモニタリング

EC2インスタンスの最適化を行うためには、リソース使用率をモニタリングすることが基本です。特に、以下のリソースをトラッキングする必要があります：

CPU使用率：インスタンスが十分にリソースを使用しているか、過負荷になっていないかを確認。

メモリ使用率：EC2インスタンスのメモリリソースが適切に使用されているかを監視。

ネットワーク使用率：ネットワークのトラフィックが過剰でないか、または十分でないかを監視。

2. AWS Compute Optimizer

AWS Compute Optimizerは、EC2インスタンスのパフォーマンスとコストを最適化するために、インスタンスの最適なサイズを提案するサービスです。Compute Optimizerは、インスタンスの過剰または不足しているリソースを評価し、必要に応じてインスタンスの種類やサイズを変更する提案を行います。

特に、CPU、メモリ、ネットワークの使用率に基づいて最適化されたインスタンスの選定を行い、リソースの無駄を減らし、コストを削減する手助けをします。

3. AWS Trusted Advisor

AWS Trusted Advisorは、AWSの最適化、セキュリティ、コスト削減に関する推奨事項を提供するサービスです。その中に「低利用のAmazon EC2インスタンス」に関するレポートもあります。これにより、使われていない、または低利用のインスタンスを発見し、不要なコストを削減することができます。

このツールはコスト管理の一環として利用し、リソースの使用率が低いインスタンスを適切にサイズ変更または停止することを推奨します。

4. CloudWatchとエージェントによるメモリのモニタリング

Amazon CloudWatchは、AWSリソースとアプリケーションの監視を行うサービスです。EC2インスタンスのCPU使用率やネットワークのトラフィックに加えて、メモリの使用状況をモニタリングすることが重要です。デフォルトでは、CloudWatchはメモリのメトリクスを収集しませんが、CloudWatchエージェントをインストールすることで、EC2インスタンスのメモリ使用状況を追跡できます。

メモリ使用率が高すぎる場合、インスタンスのサイズを変更する必要があるかもしれません。逆に、リソースが余っている場合には、インスタンスをスケールダウンできます。

5. EC2インスタンスセービングプラン

EC2インスタンスセービングプランは、長期間にわたるインスタンスの使用を前提に割引を受けられるプランです。特定のリージョンやインスタンスファミリーに対して、長期的な契約を結び、コスト削減を図ることができます。

ただし、セービングプランはリソースの最適化とは直接関係ありませんが、最適化後に、実際に使用するインスタンスに対してコストを削減する手段となります。

結論：

EC2インスタンスの最適化を進めるためには、まずはリソースの使用状況を監視し、必要なインスタンスのサイズを把握することが重要です。その後、Compute OptimizerやAWS Trusted Advisorを活用して、最適なインスタンスの選定を行い、リソースの無駄をなくします。また、メモリやCPUの監視にはCloudWatchエージェントを使うことで、より詳細なモニタリングが可能になります。