type
status
date
slug
summary
tags
category
icon
password

321-AWS SAP AWS 「理論・実践・一問道場」ec2-instance-connect:SendSSHPublicKey

理論

AWS EC2 Instance Connectは、SSH接続を安全かつ効率的に管理するためのサービスです。これにより、従来のSSHキーの管理から解放され、接続履歴をAWS CloudTrailで記録できます。
主なポイント:
  • SSHキーの管理不要: EC2 Instance Connectでは、事前にSSHキーを設定する必要がありません。接続時に一時的な公開鍵を生成し、インスタンスに送信することで、セキュアな接続を確立します。
  • CloudTrailによる監査: 接続試行や成功した接続は、すべてAWS CloudTrailに記録されます。これにより、誰がいつインスタンスにアクセスしたかを詳細に監査できます。
  • ブラウザベースの接続: AWS Management Consoleから直接インスタンスに接続できるため、SSHクライアントの設定や管理が不要です。これにより、接続手順が簡素化されます。
設定手順の概要:
  1. インスタンスの準備: Amazon Linux 2やUbuntu 16.04以降のインスタンスを使用します。インスタンスにはパブリックIPアドレスが必要です。
  1. セキュリティグループの設定: インスタンスのセキュリティグループで、ポート22（SSH）へのインバウンドトラフィックを許可します。特に、EC2 Instance Connect用のプレフィックスリストを使用することが推奨されます。
  1. IAMポリシーの設定: 接続を行うIAMユーザーまたはロールに、ec2-instance-connect:SendSSHPublicKeyアクションを許可するポリシーをアタッチします。これにより、EC2 Instance Connectを通じてインスタンスに接続できるようになります。
  1. 接続の実行: AWS Management Consoleから対象のインスタンスを選択し、「Connect」ボタンをクリックします。表示される指示に従って接続を確立します。
これらの手順を通じて、EC2 Instance Connectを利用した安全なSSH接続と、接続履歴の監査を実現できます。

実践

略

一問道場

質問 #321
トピック 1
あるリサーチ会社がAWS Cloudで高い需要に対応するため、毎日シミュレーションを実行しています。シミュレーションは、Amazon Linux 2を基盤とした数百のAmazon EC2インスタンスで実行されています。時々、シミュレーションが停止し、クラウドオペレーションエンジニアがEC2インスタンスにSSHで接続して問題を解決する必要があります。会社の方針では、同じSSHキーを使用することはできず、すべての接続はAWS CloudTrailにログとして記録されなければなりません。
ソリューションアーキテクトはどのようにしてこれらの要件を満たすことができますか？
A. 新しいEC2インスタンスを起動し、各インスタンスに個別のSSHキーを生成します。SSHキーをAWS Secrets Managerに保存します。新しいIAMポリシーを作成し、それをエンジニアのIAMロールにアタッチし、GetSecretValueアクションを許可するステートメントを追加します。エンジニアには、SSHクライアントを使用して接続する際にSecrets ManagerからSSHキーを取得するように指示します。
B. AWS Systems Managerドキュメントを作成して、EC2インスタンスでコマンドを実行し、新しい一意のSSHキーを設定します。新しいIAMポリシーを作成し、それをエンジニアのIAMロールにアタッチし、Systems Managerドキュメントを実行するための許可ステートメントを追加します。エンジニアには、ドキュメントを実行してSSHキーを設定し、SSHクライアントを使用して接続するように指示します。
C. 新しいEC2インスタンスを起動し、インスタンスにSSHキーを設定せずに、EC2インスタンス接続を各インスタンスに設定します。新しいIAMポリシーを作成し、それをエンジニアのIAMロールにアタッチし、SendSSHPublicKeyアクションを許可するステートメントを追加します。エンジニアには、EC2コンソールからブラウザベースのSSHクライアントを使用してインスタンスに接続するように指示します。
D. AWS Secrets Managerを設定してEC2 SSHキーを保存します。新しいAWS Lambda関数を作成し、新しいSSHキーを作成して、AWS Systems Manager Session Managerを呼び出してEC2インスタンスにSSHキーを設定します。Secrets ManagerがLambda関数を使用して、毎日自動的にキーをローテーションするように設定します。エンジニアには、SSHクライアントを使用して接続する際にSecrets ManagerからSSHキーを取得するように指示します。

解説

このシナリオでは、AWS CloudTrailにすべての接続を記録し、同じSSHキーを使用せずにEC2インスタンスにアクセスする必要があります。この要件を満たすために、EC2 Instance Connectを利用する方法が適切です。EC2 Instance Connectを使用すると、IAMポリシーによるアクセス制御が可能で、接続リクエストはすべてCloudTrailに記録されます。また、ブラウザベースのSSHクライアントを使用して接続できるため、SSHキーを事前に設定する必要がありません。
選択肢の評価:
  • A. 新しいEC2インスタンスを起動し、各インスタンスに個別のSSHキーを生成し、AWS Secrets Managerに保存します。エンジニアはSecrets ManagerからSSHキーを取得して接続します。この方法では、同じSSHキーを使用しないという要件を満たしますが、CloudTrailに接続を記録するためには、SSH接続のログを適切に設定する必要があります。
  • B. AWS Systems Managerドキュメントを作成して、EC2インスタンスでコマンドを実行し、新しい一意のSSHキーを設定します。エンジニアはドキュメントを実行してSSHキーを設定し、SSHクライアントを使用して接続します。この方法も同様に、SSHキーを個別に設定できますが、CloudTrailへの接続記録の設定が必要です。
  • C. 新しいEC2インスタンスを起動し、インスタンスにSSHキーを設定せず、EC2インスタンス接続を各インスタンスに設定します。エンジニアはEC2コンソールからブラウザベースのSSHクライアントを使用してインスタンスに接続します。この方法では、SSHキーを事前に設定する必要がなく、接続はCloudTrailに記録されます。ただし、EC2 Instance Connectを使用するためには、インスタンスにEC2 Instance Connectがインストールされている必要があります。
  • D. AWS Secrets Managerを設定してEC2 SSHキーを保存し、新しいAWS Lambda関数を作成して、SSHキーを生成し、AWS Systems Manager Session Managerを使用してEC2インスタンスにSSHキーを設定します。Secrets ManagerがLambda関数を使用して、毎日自動的にキーをローテーションします。エンジニアはSSHクライアントを使用して接続する際にSecrets ManagerからSSHキーを取得します。この方法では、SSHキーのローテーションが自動化されますが、CloudTrailへの接続記録の設定が必要です。
推奨される解決策:
C. 新しいEC2インスタンスを起動し、インスタンスにSSHキーを設定せず、EC2インスタンス接続を各インスタンスに設定します。新しいIAMポリシーを作成し、それをエンジニアのIAMロールにアタッチし、SendSSHPublicKeyアクションを許可するステートメントを追加します。エンジニアには、EC2コンソールからブラウザベースのSSHクライアントを使用してインスタンスに接続するように指示します。この方法では、同じSSHキーを使用せず、接続はCloudTrailに記録されます。ただし、インスタンスにEC2 Instance Connectがインストールされていることを確認する必要があります。
 
 

322-AWS SAP AWS 「理論・実践・一問道場」53 Resolver

 

理論

1. Amazon Route 53 Resolverの利用

  • Amazon Route 53 Resolverは、AWS内とオンプレミス環境間でのDNS解決を管理するためのサービスです。特に、オンプレミスのDNSとAWSのDNS解決を統合する際に便利です。
  • 条件付きフォワーディングルールを使用して、VPC内のリソースがオンプレミスのDNSサーバーを通じて特定のドメイン名を解決できるように設定できます。これにより、DNSクエリが正しく解決され、管理が簡単になります。

2. プライベートホストゾーンとNSレコード

  • Amazon Route 53プライベートホストゾーンは、VPC内でDNS解決を管理するために使用されます。プライベートホストゾーンにNSレコードを設定することで、AWSリソースがオンプレミスDNSサーバーを指し、オンプレミスのDNSサーバーにクエリを転送することが可能です。ただし、オンプレミスとAWS間のDNS統合には限界があるため、通常はRoute 53 Resolverを使う方が効果的です。

3. AWS Direct Connectの活用

  • AWS Direct Connectは、オンプレミスのデータセンターとAWS間で専用線接続を提供します。これにより、ネットワークのパフォーマンスが向上し、低遅延で安全な通信が可能になります。AWSとオンプレミス間でのDNS解決が重要な場合、Direct Connectは安定した通信を確保するために有効です。

4. EC2インスタンスを利用したキャッシュDNSサーバー

  • オンプレミスとAWS間でDNSの解決を行うために、VPC内でEC2インスタンスを用いてDNSキャッシュサーバーを運用する方法もあります。しかし、この方法は追加の管理負担が増えるため、条件付きフォワーディングルールを使用したRoute 53 Resolverの方が管理が簡単で効率的です。

5. Active Directoryの統合

  • オンプレミスのActive DirectoryをAWS環境と統合するためには、ドメインコントローラーの構築や信頼関係の設定が必要です。しかし、この方法は比較的高い管理負荷を伴い、DNS解決の要件に対する最も適切な解決策ではありません。

結論

最も管理負担が少なく、効率的にAWSとオンプレミス環境を統合する方法は、Amazon Route 53 Resolverを使用して条件付き転送ルールを設定する方法です。これにより、AWS内のアプリケーションがオンプレミスのActive DirectoryドメインのDNSクエリを解決できるようになります。

実践

略

一問道場

質問 #322
ある会社がモバイルバンキングアプリケーションを、Amazon EC2インスタンスで実行されるVPCに移行しています。バックエンドのサービスアプリケーションはオンプレミスのデータセンターで実行されています。データセンターにはAWS Direct Connect接続がAWSに向けて提供されています。VPCで実行されるアプリケーションは、データセンターにあるオンプレミスのActive Directoryドメインに対してDNSリクエストを解決する必要があります。
最も管理負荷が少ない解決策はどれですか？
A. VPC内で2つのアベイラビリティゾーンにまたがるEC2インスタンスセットを提供し、キャッシュDNSサーバーとして、VPC内のアプリケーションサーバーからのDNSクエリを解決します。
B. Amazon Route 53のプライベートホストゾーンを提供し、NSレコードをオンプレミスのDNSサーバーを指すように設定します。
C. Amazon Route 53 Resolverを使用してDNSエンドポイントを作成し、オンプレミスのデータセンターとVPC間でDNSネームスペースを解決するための条件付き転送ルールを追加します。
D. VPC内に新しいActive Directoryドメインコントローラーを提供し、この新しいドメインとオンプレミスのActive Directoryドメインとの間で双方向の信頼関係を構築します。

解説

このシナリオでは、AWS上のEC2インスタンスがオンプレミスのActive Directoryドメインに対してDNSクエリを解決する必要があります。最も管理負担が少ない解決策は、Amazon Route 53 Resolverを使用して、オンプレミスのDNSサーバーへの条件付きフォワーディングルールを設定する方法です。
選択肢の評価:
  • A. VPC内にキャッシュDNSサーバーを構築する方法です。この方法では、DNSクエリの解決に関する管理が増え、オンプレミスのActive Directoryドメインとの統合が難しくなります。
  • B. Amazon Route 53プライベートホストゾーンを作成し、NSレコードをオンプレミスのDNSサーバーを指すように設定する方法です。しかし、Route 53プライベートホストゾーンはVPC内のリソースに対して名前解決を提供するものであり、オンプレミスのActive Directoryドメインとの統合には適していません。
  • C. Amazon Route 53 Resolverを使用し、条件付きフォワーディングルールを設定して、オンプレミスのDNSサーバーへのクエリを転送する方法です。この方法は、AWSとオンプレミスのネットワーク間でのDNSクエリ解決を容易にし、管理負担を最小限に抑えることができます。
  • D. VPC内に新しいActive Directoryドメインコントローラーを配置し、オンプレミスのActive Directoryドメインとの双方向の信頼関係を構築する方法です。この方法は、Active Directoryの統合に関する管理が増え、DNSクエリ解決の要件を満たすための追加の設定が必要となります。
推奨される解決策:
C. Amazon Route 53 Resolverを使用し、条件付きフォワーディングルールを設定して、オンプレミスのDNSサーバーへのクエリを転送する方法です。この方法は、AWSとオンプレミスのネットワーク間でのDNSクエリ解決を容易にし、管理負担を最小限に抑えることができます。
 
 

323-AWS SAP AWS 「理論・実践・一問道場」Kinesis Data Streams + DynamoDB

 

理論

リアルタイムデータ処理とスキーマレスデータベースに関するAWSのベストプラクティス

1. リアルタイムデータ処理

リアルタイムでデータを収集・処理するシステムは、遅延を最小限に抑え、迅速なデータストリームの処理が求められます。AWSでは以下のサービスが主に使用されます：
  • Amazon Kinesis Data Streams: 高スループットのデータストリームを処理するためのサービス。継続的なデータ収集とリアルタイム処理に最適。
  • Amazon Kinesis Data Firehose: ストリームデータを簡単にデータレイクやデータベースに送信できるサービス。ストリームのバッチ処理や圧縮、変換も可能。
  • Amazon Managed Streaming for Apache Kafka (MSK): Kafkaを利用した分散型ストリーム処理。特にカスタムデータ処理に強みを持つ。

2. スキーマレスデータベース

スキーマレスなデータベースは、柔軟なデータモデルが必要なシステムに適しており、AWSには以下の選択肢があります：
  • Amazon DynamoDB: NoSQLデータベースで、低遅延かつスケーラブル。JSON形式のデータを直接保存可能。
  • Amazon Keyspaces (for Apache Cassandra): Cassandra互換の分散型データベース。スキーマレスで広範囲なデータを扱う場合に適している。

3. 各選択肢の適用例

  • Kinesis Data Streams + DynamoDB: リアルタイムで大量のデータを収集し、スキーマレスデータベースに保存する場合に理想的。例：IoTデバイスやセンサーからのデータ収集。
  • Kinesis Data Firehose + Keyspaces: バッチ形式でデータを処理し、NoSQLデータベースに保存する場合に適している。例：大規模なログデータの保存。
  • MSK + Aurora: 複雑なデータ処理や分散処理が必要な場合に有用。例：トランザクションデータのリアルタイム分析。

実践

略

一問道場

質問 #323
ある会社が環境データを処理しています。この会社は都市のさまざまなエリアから継続的にデータをストリームとして提供するセンサーを設置しました。
データはJSON形式で利用可能です。
会社は、固定スキーマを必要としないデータベースにデータを送信するために、リアルタイムで動作するAWSソリューションを使用したいと考えています。
どのソリューションが最小限の管理作業でこれらの要件を満たすことができますか？
A. Amazon Kinesis Data Firehoseを使用してデータをAmazon Redshiftに送信する。
B. Amazon Kinesis Data Streamsを使用してデータをAmazon DynamoDBに送信する。
C. Amazon Managed Streaming for Apache Kafka (Amazon MSK)を使用してデータをAmazon Auroraに送信する。
D. Amazon Kinesis Data Firehoseを使用してデータをAmazon Keyspaces (for Apache Cassandra)に送信する。

解説

環境データをリアルタイムで処理し、固定スキーマを必要としないデータベースに保存するためのAWSソリューションを検討する際、以下の選択肢があります。
選択肢の評価:
  • A. Amazon Kinesis Data Firehoseを使用してAmazon Redshiftにデータを送信する。
      • Amazon Redshiftはリレーショナルデータベースであり、固定スキーマを必要とします。したがって、スキーマレスデータの保存には適していません。
  • B. Amazon Kinesis Data Streamsを使用してAmazon DynamoDBにデータを送信する。
      • Amazon DynamoDBはスキーマレスのNoSQLデータベースであり、JSON形式のデータを保存できます。Kinesis Data Streamsはリアルタイムデータの取り込みに適しています。この組み合わせは要件を満たします。
  • C. Amazon Managed Streaming for Apache Kafka (Amazon MSK)を使用してAmazon Auroraにデータを送信する。
      • Amazon Auroraはリレーショナルデータベースであり、固定スキーマを必要とします。スキーマレスデータの保存には適していません。
  • D. Amazon Kinesis Data Firehoseを使用してAmazon Keyspaces (for Apache Cassandra)にデータを送信する。
      • Amazon KeyspacesはスキーマレスのNoSQLデータベースであり、JSON形式のデータを保存できます。Kinesis Data Firehoseはリアルタイムデータの取り込みに適しています。この組み合わせも要件を満たします。
推奨される解決策:
  • *B. Amazon Kinesis Data Streamsを使用してAmazon DynamoDBにデータを送信する。**この組み合わせは、リアルタイムでスキーマレスのJSONデータを処理し、保存する要件を満たします。DynamoDBはスケーラブルで高可用性のNoSQLデータベースであり、Kinesis Data Streamsはリアルタイムデータの取り込みに最適です。
 
 

324-AWS SAP AWS 「理論・実践・一問道場」DocumentDB

 

理論

オンプレミスからAWSへの移行におけるデータベースの選択ポイントとベストプラクティス

オンプレミス環境からAWSクラウドへ移行する際、データベースの設計と選択は、アプリケーションのパフォーマンスや可用性に大きな影響を与えます。以下は、特にデータベース移行に関連する重要な知識や考慮点をまとめたものです。

1. データベースの種類の選択

AWSにはさまざまなマネージドデータベースサービスが提供されています。移行元のデータベースやアプリケーションの要件に応じて最適なサービスを選択する必要があります。
データベースタイプ
AWSのサービス例
特徴
適用例
リレーショナル型
Amazon RDS, Amazon Aurora
高可用性とスケーラビリティを持つマネージドリレーショナルDB
既存のSQLベースアプリケーション
NoSQL型
Amazon DynamoDB, Amazon DocumentDB
スキーマレスデータモデル、高速な読み書き、スケーラビリティ
キーバリュー型、ドキュメント型のデータベース
分析用
Amazon Redshift
データウェアハウスとして、大量データのクエリ処理と分析に最適
BIツールやデータ解析
時系列/グラフ型
Amazon Timestream, Amazon Neptune
特定用途向けに最適化されたデータベース
時系列データ、グラフ構造データ

2. 暗号化要件とセキュリティ

クラウド環境でのセキュリティは最優先事項です。特に、移行先のデータベースが暗号化の要件を満たしていることを確認します。
  • 保存時の暗号化
      • AWS Key Management Service (KMS) を使用し、データを保存時に暗号化できます。Amazon RDS、DynamoDB、DocumentDBなどのほとんどのサービスがサポートしています。
  • 転送時の暗号化
      • Transport Layer Security (TLS) を利用して、データの転送中に安全な通信を確保します。AWSの多くのデータベースサービスではデフォルトでTLSが有効です。
  • ネットワークセキュリティ
      • VPC（仮想プライベートクラウド）を利用してプライベートネットワークを構築し、パブリックインターネットからのアクセスを制限します。必要に応じて、VPCエンドポイントを活用することで、AWSリソース間のセキュアな接続を確保できます。

3. スケーラビリティと高可用性

クラウド移行後は、需要の変動に応じたスケーラビリティが重要になります。

Amazon DynamoDB

  • フルマネージド型のNoSQLデータベースで、オンデマンドキャパシティをサポート。トラフィックの増減に応じて自動的にスケールします。
  • 複数リージョンへのレプリケーションが可能で、高い可用性を実現。

Amazon DocumentDB

  • クラスター構造を採用し、複数のインスタンスでデータをレプリケート。
  • ストレージが自動的にスケールし、最大64 TiBまで拡張可能。
  • クラスターエンドポイントを使用することで、高可用性と負荷分散を確保。

Amazon RDS / Aurora

  • リレーショナルデータベースで自動スケールやフェイルオーバー機能を提供。
  • Auroraではサーバーレスオプションもあり、リソース使用量に応じて課金される。

4. AWSにおけるデータベース接続とネットワーク設計

AWS内でデータベースを設計する場合、ネットワーク構成が重要です。
  • VPCエンドポイント
      • Amazon DynamoDBやS3などのサービスにプライベート接続を提供します。
    • インターフェースエンドポイント: DynamoDB APIへのアクセス。
    • ゲートウェイエンドポイント: DynamoDBやS3へのデータアクセス。
  • プライベートサブネットとNATゲートウェイ
      • EC2インスタンスをプライベートサブネットに配置することでインターネット接続を排除し、セキュリティを向上させます。

5. レガシーデータベース移行のステップ

  1. 評価
      • 既存のデータベースとAWSサービス間の互換性を確認します。
      • 必要に応じてデータ変換ツールを使用（例: AWS Schema Conversion Tool）。
  1. 計画
      • ネットワーク設計、セキュリティ設定、スケーリング戦略を決定。
      • 移行時のダウンタイムを最小化するための方法を検討。
  1. 移行
      • AWS Database Migration Service (DMS) を使用してデータを移行。
      • 並行運用テストを実施し、移行の妥当性を確認。
  1. 最適化
      • 移行後のパフォーマンスを監視し、必要に応じて設定を調整。

6. ベストプラクティス

  • データ暗号化を徹底 AWS KMSを利用したキー管理を行い、保存時と転送時の暗号化を有効にします。
  • 監視とロギング Amazon CloudWatchやAWS CloudTrailを活用して、データベースの利用状況とセキュリティを継続的に監視します。
  • コスト最適化 適切なキャパシティ設定と課金モデル（プロビジョンドIOPSやオンデマンドキャパシティ）を選択します。

まとめ

AWSへの移行では、アプリケーション要件に応じたデータベース選択が成功の鍵となります。Amazon DynamoDBやDocumentDBなど、AWSが提供するマネージドサービスを適切に活用することで、高いスケーラビリティ、セキュリティ、コスト効率を実現できます。
 
 
notion image
項目
クラスターエンドポイント
インスタンスエンドポイント
概要
クラスター全体への接続。高可用性と負荷分散。
特定のインスタンスへの接続。
用途
アプリケーションの接続先（プライマリまたはリードレプリカ）。
特定のインスタンス（プライマリやリードレプリカ）への接続。
自動フェイルオーバー
あり。プライマリ障害時に新しいインスタンスに自動切替。
なし。指定したインスタンスに固定接続。
負荷分散
あり。
なし。
主な使用例
アプリケーションの接続、可用性重視。
特定インスタンスへの接続、デバッグ用途。
 

実践

略

一問道場

Question #324
ある企業が、オンプレミスのデータセンターからAWSへレガシーアプリケーションを移行しています。このアプリケーションは、MongoDBをキー・バリュー型データベースとして使用しています。
企業の技術ガイドラインによると、すべてのAmazon EC2インスタンスはインターネット接続のないプライベートサブネット内でホストされなければなりません。さらに、アプリケーションとデータベース間のすべての接続は暗号化されている必要があります。データベースは需要に応じてスケールできる必要があります。
この要件を満たすソリューションはどれですか？
A. Amazon DocumentDB（MongoDB互換）の新しいテーブルを、プロビジョンドIOPSボリュームで作成します。インスタンスエンドポイントを使用してAmazon DocumentDBに接続します。
B. アプリケーション用にオンデマンドキャパシティのAmazon DynamoDBの新しいテーブルを作成します。DynamoDBへの接続にはDynamoDB用のゲートウェイVPCエンドポイントを使用します。
C. アプリケーション用にオンデマンドキャパシティのAmazon DynamoDBの新しいテーブルを作成します。DynamoDBへの接続にはDynamoDB用のインターフェースVPCエンドポイントを使用します。
D. Amazon DocumentDB（MongoDB互換）の新しいテーブルを、プロビジョンドIOPSボリュームで作成します。クラスターエンドポイントを使用してAmazon DocumentDBに接続します。

解説

この問題における要件を満たす最適なソリューションは D です。以下にその理由を説明します：

Dの解説

  • Amazon DocumentDB（MongoDB互換） は、MongoDB互換のデータベースサービスであり、スケーラビリティと暗号化対応が求められています。DocumentDBは、スケーラビリティを確保し、アプリケーションとデータベース間の接続をTLSで暗号化できます。
  • クラスターエンドポイント は、DocumentDBに接続する際に使用される推奨のエンドポイントであり、可用性と負荷分散のために複数のインスタンス（プライマリ、リードレプリカ）を透過的に扱えます。また、プライベートサブネット内で動作し、セキュリティ要件も満たします。

他の選択肢の分析

  • A. インスタンスエンドポイントを使って接続する方法は、特定のインスタンスに直接接続する方法ですが、高可用性や負荷分散の要件には不適切です。クラスターエンドポイントを使用するほうが優れています。
  • B. DynamoDBはキー・バリュー型データベースでスケーラブルですが、MongoDBと直接的に互換性がないため、要件に合いません。また、ゲートウェイVPCエンドポイントはインターネット接続なしでの接続には使えますが、DynamoDBはスケーラビリティの要求を満たすには最適ではありません。
  • C. DynamoDBのインターフェースVPCエンドポイントを使用することは可能ですが、やはりMongoDBと同じような機能を提供するわけではなく、要件に合致しません。

結論

D. Amazon DocumentDB（MongoDB互換）のクラスターエンドポイントを使用することで、暗号化、スケーラビリティ、可用性、プライベートサブネットへの配置の要件をすべて満たすため、この選択肢が最適です。
 
 

325-AWS SAP AWS 「理論・実践・一問道場」DMS

 

理論

1. AWS Database Migration Service (DMS)

AWS DMSは、オンプレミスのデータベースからAWSのデータベースにデータを移行するためのマネージドサービスです。特に、リアルタイムでのデータ移行が可能な変更データキャプチャ（CDC） 機能を提供し、ダウンタイムを最小限に抑えることができます。DMSは、MongoDBからAmazon DocumentDB（MongoDB互換）への移行をサポートしており、移行後も継続的なデータレプリケーションが可能です。

主な特徴：

  • リアルタイムデータ移行：CDCを使用して、データベースの変更をリアルタイムで移行。
  • 最小ダウンタイム：運用中のデータベースに影響を与えずにデータ移行を行う。
  • サポートするデータベース：MongoDBやMySQL、PostgreSQLなど、多くのデータベースに対応。

2. Amazon DocumentDB（MongoDB互換）

Amazon DocumentDBは、MongoDB互換のフルマネージドデータベースサービスです。DocumentDBは、スケーラビリティ、可用性、セキュリティを提供し、MongoDBのアプリケーションをAWS上に簡単に移行できます。DocumentDBは、データの整合性や耐障害性を保証し、パフォーマンスのスケーリングが可能です。

主な特徴：

  • MongoDB互換：MongoDBと同じAPIを使用するため、既存のMongoDBアプリケーションを簡単に移行可能。
  • フルマネージド：インフラ管理が不要で、AWSが運用、スケーリング、バックアップを管理。
  • 暗号化：データの暗号化と、インターネット経由の安全な接続がサポートされている。

3. 変更データキャプチャ（CDC）

変更データキャプチャ（CDC）は、データベース内の変更をリアルタイムで追跡し、それをターゲットシステムに転送する技術です。CDCは、特にデータ移行やデータ同期のシナリオで非常に有用です。DMSはCDCを使用して、オンプレミスのデータベースとAmazon DocumentDBの間で変更を同期しながら移行を行うことができます。

主な利点：

  • リアルタイムのデータ同期：データベースの変更をリアルタイムで反映。
  • 最小限のダウンタイム：データベースの稼働を維持したまま移行が可能。

4. データ移行戦略の選択

データ移行にはいくつかのアプローチがあります。AWS DMSは、特に以下のような要件がある場合に適しています：
  • データベースの移行をリアルタイムで行いたい。
  • 最小限のダウンタイムで移行を完了させたい。
  • 移行後も継続的なデータレプリケーションが必要。
他のアプローチ（例えば、EC2インスタンスの構成やAWS Glueを使用した移行）は、特定のユースケースには有効ですが、MongoDBからDocumentDBへの移行にはDMSが最適です。

結論

MongoDBからAmazon DocumentDB（MongoDB互換）への移行には、AWS DMSを使用した**変更データキャプチャ（CDC）**が最適な戦略です。これにより、データ移行をダウンタイムなしでリアルタイムで実施でき、さらに移行後も継続的なデータ同期を維持することが可能です。

実践

略

一問道場

質問 #325
ある企業が、AWSクラウドでAmazon EC2インスタンス上でアプリケーションを実行しています。このアプリケーションは、レプリカセットを使用したMongoDBデータベースをデータ層として利用しています。MongoDBデータベースは企業のオンプレミスのデータセンターにインストールされており、AWS Direct Connect接続を介してデータセンター環境にアクセス可能です。ソリューションアーキテクトは、このオンプレミスのMongoDBデータベースをAmazon DocumentDB（MongoDB互換）に移行する必要があります。
ソリューションアーキテクトは、どの戦略を選ぶべきですか？
A. EC2インスタンスのフリートを作成し、MongoDB Community Editionをインスタンスにインストールしてデータベースを作成します。オンプレミスのデータセンターで実行されているデータベースと継続的な同期レプリケーションを構成します。
B. AWS Database Migration Service（AWS DMS）レプリケーションインスタンスを作成します。変更データキャプチャ（CDC）を使用して、オンプレミスのMongoDBデータベースのソースエンドポイントを作成します。Amazon DocumentDBデータベースのターゲットエンドポイントを作成します。DMS移行タスクを作成して実行します。
C. AWS Data Pipelineを使用してデータ移行パイプラインを作成します。オンプレミスのMongoDBデータベースとAmazon DocumentDBデータベースのデータノードを定義します。データパイプラインを実行するためのスケジュールされたタスクを作成します。
D. AWS Glueクロウラーを使用してオンプレミスのMongoDBデータベースのソースエンドポイントを作成します。MongoDBデータベースとAmazon DocumentDBデータベース間で継続的な非同期レプリケーションを構成します。

解説

この問題における最適な選択肢は B です。以下にその理由を解説します：

Bの解説

AWS Database Migration Service (DMS) は、オンプレミスのデータベースからAmazon DocumentDBへの移行に適したサービスです。DMSは、変更データキャプチャ（CDC） を使用して、データベースの変更をリアルタイムでキャプチャし、ターゲットに転送します。これにより、ダウンタイムを最小限に抑えながらデータを移行できます。また、DMSはMongoDBからAmazon DocumentDB（MongoDB互換）への移行をサポートしており、移行後に継続的なレプリケーションも可能です。

他の選択肢の分析

  • A. EC2インスタンスにMongoDBをインストールして同期レプリケーションを行う方法は、手動で管理が必要で、スケーラビリティや可用性が低いため、推奨されません。さらに、MongoDBからAmazon DocumentDBへの移行には、この方法では適していません。
  • C. AWS Data Pipelineは、データのETL（抽出、変換、ロード）を行うためのツールですが、継続的なデータのレプリケーションや移行には最適ではありません。特にMongoDBからAmazon DocumentDBへの移行には、CDCやリアルタイムデータ転送に対応したサービスの方が適切です。
  • D. AWS Glueは主にデータの抽出・変換・ロードを行うETLツールですが、MongoDBのようなNoSQLデータベースからAmazon DocumentDBへの移行には、CDCを使用したデータベース移行ツールであるDMSの方が適しています。非同期レプリケーションの構成も難易度が高いため、この選択肢は不適切です。

結論

B. のAWS DMSは、変更データキャプチャ（CDC）を使用して、データベース間のデータ移行を効率的に行い、リアルタイムのレプリケーションにも対応できるため、このシナリオに最も適した方法です。
 
 

326-AWS SAP AWS 「理論・実践・一問道場」AWS Managed Microsoft AD

 

理論

AWS Directory Service for Microsoft Active Directoryの概要と関連技術
  1. AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD):
      • 完全に管理されたサービスで、Windows Server 2019に基づいています。
      • AWS上でActive Directoryドメインを実行し、Microsoftのサービス（SharePointや.NETアプリケーションなど）をサポートします。
      • オンプレミスのActive DirectoryとAWS間で信頼関係を設定し、シームレスに統合できます。
      • 多要素認証（MFA）をRADIUSベースでサポートし、セキュリティ強化が可能です。
  1. Amazon WorkSpaces:
      • AWS上で提供される完全管理型のデスクトップサービスで、ユーザーがリモートで安全に作業できる環境を提供します。
      • Active Directoryの管理やセキュリティ設定を行うために利用できます。
  1. 多要素認証（MFA）:
      • セキュリティ強化のために、ユーザー認証において2段階認証を要求する技術です。
      • AWS Managed Microsoft ADでは、RADIUSを使用してMFAを有効化できます。
  1. AWS Directory Serviceの他のバージョン:
      • AWS Directory Service Simple AD:
        • 基本的なディレクトリサービスを提供し、小規模な環境に適していますが、Microsoft Active Directoryのフル機能を必要とする環境には不向きです。
      • AD Connector:
        • オンプレミスのActive DirectoryとAWS環境を統合するサービスです。既存のオンプレミスADをAWS上で利用する際に使用されます。
要点:
  • AWS Managed Microsoft ADは、企業のニーズに対応できる強力なディレクトリサービスであり、特にActive Directoryの統合やMFAの導入を必要とする環境に最適です。
  • Amazon WorkSpacesを利用して、AWS上でのドメイン参加やセキュリティ設定を行うことができます。

実践

略

一問道場

質問#326
ある企業がアプリケーションをAWSで実行するように再構築しています。企業のインフラストラクチャには複数のAmazon EC2インスタンスが含まれています。企業の開発チームには異なるレベルのアクセスが必要です。企業はすべてのWindows EC2インスタンスがAWSのActive Directoryドメインに参加することを要求するポリシーを実装したいと考えています。企業はさらに、マルチファクター認証（MFA）などの強化されたセキュリティプロセスも実施したいと考えています。企業は可能な限りAWSの管理されたサービスを使用したいと考えています。
この要件を満たすソリューションはどれですか？
A. AWS Directory Service for Microsoft Active Directoryを実装して、Amazon WorkSpaceを起動します。WorkSpaceに接続して、ドメインのセキュリティ設定タスクを実行します。
B. AWS Directory Service for Microsoft Active Directoryを実装して、EC2インスタンスを起動します。EC2インスタンスに接続して、ドメインのセキュリティ設定タスクを実行します。
C. AWS Directory Service Simple ADを実装して、EC2インスタンスを起動します。EC2インスタンスに接続して、ドメインのセキュリティ設定タスクを実行します。
D. AWS Directory Service Simple ADを実装して、Amazon WorkSpaceを起動します。WorkSpaceに接続して、ドメインのセキュリティ設定タスクを実行します。
 

解説

Aが正解の理由は、以下の通りです。
  1. AWS Directory Service for Microsoft Active Directory（AWS Managed Microsoft AD）:
      • これは、完全に管理されたMicrosoft Active Directoryサービスで、Windows Server 2019を基盤にしており、AWS上でディレクトリ対応のワークロード（例えば、Microsoft SharePointや.NET、SQL Serverアプリケーションなど）を実行するために利用されます。
      • これにより、企業はAWSクラウド内でActive Directoryドメインを管理し、Windows EC2インスタンスをそのドメインに参加させることができます。
      • さらに、既存のオンプレミスのMicrosoft Active Directoryと信頼関係を構成することができ、オンプレミスとAWS間での統合が可能です。
  1. MFA（マルチファクター認証）のサポート:
      • AWS Managed Microsoft ADは、RADIUSベースのMFAインフラストラクチャと統合することで、MFAをサポートします。これにより、セキュリティを強化するために、ユーザー認証時に2段階認証を利用できます。
  1. Amazon WorkSpacesの使用:
      • ドメインのセキュリティ設定タスクを実行するために、Amazon WorkSpaceを利用します。WorkSpaceは、完全に管理されたデスクトップコンピューティングサービスで、AWS上で安全にデスクトップ環境を提供します。この環境に接続することで、Windows EC2インスタンスをAWS Active Directoryドメインに参加させるための設定作業を行うことができます。
このように、Aは企業が求める要件を満たす最適なソリューションであるため、正解となります。
他の選択肢に関しては以下の理由で不適切です：
  • Bは、EC2インスタンスを使用する方法ですが、AWS Managed Microsoft ADを利用してドメイン参加やセキュリティ設定を行うことが推奨されます。
  • CとDは、AWS Directory Service Simple ADを使用する方法ですが、Simple ADは、Microsoft Active Directoryのフル機能が必要なケースには適していません。AWS Managed Microsoft ADがより強力で柔軟な機能を提供します。
以上が、Aが正解である理由です。
 
 

327-AWS SAP AWS 「理論・実践・一問道場」ElastiCache for Memcached

 

理論

1. データベースの分離

  • データベースの分離は、異なるタイプのデータ（例えば、製品データとユーザーセッションデータ）を異なるデータベースに格納することで、効率的な管理、パフォーマンス向上、スケーラビリティを実現する手法です。例えば、製品データのような永続的なデータはリレーショナルデータベース（RDSなど）に保存し、一時的なユーザーセッションデータは、スピーディーな読み書きが求められるため、NoSQLデータベース（例えばDynamoDBやElastiCache）に格納することが一般的です。

2. AWSサービスの利用

  • Amazon RDS（Relational Database Service）は、リレーショナルデータベースを管理するためのフルマネージドサービスです。MySQL、PostgreSQL、MariaDB、Oracle、SQL Serverなどのデータベースエンジンをサポートし、バックアップ、パッチ適用、スケーリングなどを簡単に行える特徴があります。RDSは高可用性のためのマルチAZ配置、災害復旧用のリードレプリカ、他リージョンへのレプリケーションをサポートしています。
  • Amazon DynamoDBは、フルマネージドなNoSQLデータベースサービスで、スケーラビリティとパフォーマンスに優れています。特に、スループットやレイテンシーに関して非常に高いパフォーマンスを発揮します。また、グローバルテーブル機能を使用することで、異なるリージョン間でデータの同期とレプリケーションを実現できます。
  • Amazon ElastiCacheは、インメモリキャッシュサービスで、データベースの負荷を減らし、アプリケーションの応答時間を短縮するために使用されます。特に、ユーザーセッションデータや頻繁にアクセスされるデータに適しています。MemcachedまたはRedisエンジンを使用することができます。

3. 災害復旧とリージョン間レプリケーション

災害復旧（Disaster Recovery）は、データセンターの障害や地域的な問題が発生した際に、ビジネス継続性を確保するための戦略です。AWSでは、データベースのリードレプリカを異なるリージョンに配置することで、万が一の障害発生時にも迅速に切り替えてサービスを提供することができます。
  • リージョン間レプリケーション：RDSやDynamoDBなどのAWSサービスでは、複数のリージョンにデータをレプリケートすることで、災害復旧に備えます。これにより、地域的な障害が発生しても、別のリージョンからデータを提供することができ、システムのダウンタイムを最小限に抑えることができます。

4. パフォーマンス最適化

データベースのパフォーマンスを最適化するためには、次の方法が考えられます：
  • キャッシュの利用：頻繁にアクセスされるデータをインメモリでキャッシュすることで、データベースの読み書きの負荷を軽減し、アプリケーションの応答速度を向上させます。
  • データ分割と分散：データを適切に分割（シャーディング）して、アクセスが集中しないように分散することで、スケーラビリティを向上させます。
  • 適切なインデックス設定：データベースのクエリ性能を向上させるために、検索されるデータにインデックスを追加し、効率的な検索を実現します。

5. データの一貫性と可用性

  • CAP定理：分散システムにおけるデータベースは、常に一貫性（Consistency）、可用性（Availability）、分割耐性（Partition tolerance）の3つの特性のうち、2つを選択する必要があります。DynamoDBのようなNoSQLデータベースは、可用性と分割耐性を優先し、最終的な整合性を保証することが多いです。
  • トランザクション管理：RDSやDynamoDBはトランザクション管理のための強力なサポートを提供しており、データの整合性を保ちながら、システム全体のパフォーマンスを最適化します。

まとめ

  • 製品データ（永続的なデータ）にはAmazon RDS、ユーザーセッションデータ（一時的なデータ）にはDynamoDBやElastiCacheを利用することで、データを効果的に分離し、災害復旧を実現することができます。
  • 複数のAWSサービスを組み合わせることで、パフォーマンスを最大化し、ビジネス継続性を確保できます。

実践

略

一問道場

問題 #327
ある企業が、オンプレミスのアプリケーションをAWSに移行しようとしています。アプリケーションのデータベースは、構造化された製品データと一時的なユーザーセッションデータを保存しています。企業は製品データとユーザーセッションデータを分離したいと考えています。また、災害復旧のために別のAWSリージョンでレプリケーションを実装する必要があります。
どのソリューションが、最高のパフォーマンスを提供し、これらの要件を満たすでしょうか？
A. Amazon RDS DBインスタンスを作成し、製品データとユーザーセッションデータをホストするために別々のスキーマを使用します。別のリージョンでDBインスタンスのリードレプリカを構成します。
B. Amazon RDS DBインスタンスを作成して製品データをホストします。DBインスタンスのリードレプリカを別のリージョンで構成します。Amazon ElastiCache for Memcachedでグローバルデータストアを作成してユーザーセッションデータをホストします。
C. 2つのAmazon DynamoDBグローバルテーブルを作成します。一方のグローバルテーブルを製品データのホストに、もう一方をユーザーセッションデータのホストに使用します。DynamoDB Accelerator(DAX)を使用してキャッシュします。
D. Amazon RDS DBインスタンスを作成して製品データをホストします。DBインスタンスのリードレプリカを別のリージョンで構成します。ユーザーセッションデータをホストするためにAmazon DynamoDBグローバルテーブルを作成します。

解説

この問題では、製品データとユーザーセッションデータを分離し、災害復旧のために別リージョンでレプリケーションを実装する必要があります。要件には高パフォーマンスが求められています。
選択肢ごとの分析:
A.
Amazon RDSを使用して、製品データとユーザーセッションデータを別々のスキーマでホストし、リードレプリカを別リージョンに構成する方法です。しかし、RDSはリレーショナルデータベースであり、ユーザーセッションデータのような一時的なデータを処理するには最適ではありません。さらに、RDSのリードレプリカは、特定のデータアクセスのパフォーマンス向上には限界があるため、パフォーマンス要件には合致しません。
B.
製品データをAmazon RDSにホストし、リードレプリカを別リージョンに構成します。ユーザーセッションデータは、ElastiCache for Memcachedでグローバルデータストアを使用することで、セッションデータの高速な読み書きを実現します。ElastiCacheはキャッシュとして非常に高パフォーマンスなソリューションであり、ユーザーセッションデータの分離と高速アクセスに適しています。この選択肢はパフォーマンスの要件に最適です。
C.
Amazon DynamoDBのグローバルテーブルを使用して、製品データとユーザーセッションデータをホストします。さらに、DAX（DynamoDB Accelerator）を使ってキャッシュを活用することで、非常に高速なデータアクセスを実現します。DynamoDBはスケーラビリティとパフォーマンスに優れ、グローバルテーブル機能を利用することで、別リージョン間のデータ同期と高可用性も確保できます。この選択肢も非常にパフォーマンス重視の要件を満たしています。
D.
製品データをAmazon RDSにホストし、リードレプリカを別リージョンに構成します。ユーザーセッションデータはAmazon DynamoDBグローバルテーブルでホストします。このアプローチも良いですが、ユーザーセッションデータの取り扱いにおいてDynamoDBを使用する選択肢は有効ですが、製品データにRDSを使う選択肢は、データベースのスケーラビリティやパフォーマンス要件によっては最適ではない場合もあります。
最適解:
B.
RDSとElastiCache for Memcachedを組み合わせることで、製品データとセッションデータを分離し、災害復旧機能を保持しつつ、非常に高いパフォーマンスを得ることができます。ElastiCacheは、ユーザーセッションデータの高パフォーマンスなキャッシュ層を提供し、RDSは堅牢でスケーラブルなリレーショナルデータベースとして機能します。
 
 

328-AWS SAP AWS 「理論・実践・一問道場」予防的ガードレール

 

理論

 

1. AWS Control Tower

AWS Control Towerは、AWS環境で複数のアカウントを効率的に管理するためのサービスです。特にガードレールを使って、組織内の各アカウントの設定やポリシーを統一し、セキュリティとコンプライアンスを確保できます。Control Towerは、リソースの設定ミスを減らすために使われます。
  • ガードレールには予防的ガードレールと探知的ガードレールがあり、前者はリソースの作成や変更を制限し、後者は不適切な設定を検出する役割があります。

2. AWS OrganizationsとSCP（サービスコントロールポリシー）

AWS Organizationsは、複数のAWSアカウントを管理するためのサービスで、組織単位でポリシーや設定を一元的に管理できます。SCPは、組織全体または特定のOU（組織単位）に対して適用できるポリシーで、許可または制限を行うためのものです。しかし、SCPはあくまでアクセス権限の制御を行うものであり、リソースの作成や変更そのものを制限するわけではありません。これに対して、Control Towerのガードレールはリソース作成の制限を行います。

3. AWS Config

AWS Configは、リソースの設定監視および変更履歴を追跡するサービスです。AWS Configルールを使用して、リソースが適切に設定されているかどうかを監視し、ポリシー違反を検出できます。AWS Configは主に設定や状態の監視に役立つため、リソースのデプロイ制限には向いていません。

4. 予防的ガードレール

AWS Control Towerの予防的ガードレールは、AWSリソースが特定のポリシーに従ってデプロイされることを確実にするために使います。これを使用すると、開発者が特定のインスタンスタイプ（例えば、バースト可能なインスタンス）以外のリソースを作成することを防ぐことができます。

まとめ

この問題では、開発OUに対して特定のインスタンスタイプとサービスの制限をかけるために、AWS Control Towerの予防的ガードレールを使用することが推奨されます。これにより、開発者がバースト可能なインスタンスだけをデプロイし、関連しないサービスを使用できないように制御できます。

実践

略

一問道場

質問 #328
ある会社が、AWS Control Towerを使用してマルチアカウント構造をオーケストレーションしています。同社はAWS Organizations、AWS Config、AWS Trusted Advisorを使用しています。同社には、開発者がAWSで実験するために使用する特定のOU（組織単位）があります。会社には何百人もの開発者がおり、各開発者には個別の開発アカウントがあります。同社はこれらの開発アカウントでコストを最適化したいと考えています。Amazon EC2インスタンスとAmazon RDSインスタンスはバースト可能でなければなりません。さらに、関連しないサービスの使用を禁止したいと考えています。
この要件を満たすために、ソリューションアーキテクトはどのような推奨をすべきですか？
A. AWS OrganizationsでカスタムSCPを作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。このSCPを開発OUに適用します。
B. AWS Control Towerでカスタムの探知コントロール（ガードレール）を作成し、そのコントロール（ガードレール）を設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。このコントロール（ガードレール）を開発OUに適用します。
C. AWS Control Towerでカスタムの予防コントロール（ガードレール）を作成し、そのコントロール（ガードレール）を設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。このコントロール（ガードレール）を開発OUに適用します。
D. AWS ConfigルールをAWS Control Towerアカウントで作成し、そのAWS Configルールを設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。AWS ConfigルールをCloudFormation StackSetsを使用して開発OUに展開します。

解説

この問題は、開発アカウントにおいてAWSリソースの使用を制限し、特にバースト可能なインスタンスのみを使用し、関連しないサービスの使用を禁止する方法に関するものです。最も適切な解決策を選ぶために、各選択肢を詳しく見ていきましょう。

選択肢の解説

A. AWS OrganizationsでカスタムSCPを作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。SCPを開発OUに適用します。
  • *サービスコントロールポリシー(SCP)**は、AWS Organizationsで設定され、IAMユーザーとロールのアクセス許可を制御します。SCPを使用すると、AWSリソースの使用を制限することができますが、実際のリソースの作成や管理に関する制限を厳密に行うためには、ガードレールを使用するのが一般的です。
  • SCPは「許可する」ポリシーを定義するのが難しく、特定のサービスやインスタンスに制限を加えることはできません。このため、リソース制限に関しては、SCPではなくガードレールを使う方が適切です。
B. AWS Control Towerでカスタムの探知コントロール（ガードレール）を作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。これを開発OUに適用します。
  • *探知コントロール（ガードレール）**は、リソースの使用状況を監視し、ポリシー違反を検出するために使用されます。リソースの作成や削除を直接制限するものではないため、リソースの使用を制限する目的には不十分です。
C. AWS Control Towerでカスタムの予防コントロール（ガードレール）を作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。これを開発OUに適用します。
  • *予防コントロール（ガードレール）**は、リソースの作成や変更を防ぐために使用されるもので、バースト可能なインスタンスのみを許可するという要件に最も適しています。予防コントロールはリソースの制限やガイドラインに従わせるため、特定のインスタンスタイプやサービスの使用を制限することができます。
  • 開発OUに適用することで、開発者の使用するインスタンスを制限し、他のサービスを使わせないようにできます。これが最も効果的な方法です。
D. AWS ConfigルールをAWS Control Towerアカウントで作成し、そのAWS Configルールを設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。AWS ConfigルールをCloudFormation StackSetsを使用して開発OUに展開します。
  • AWS Configは、AWSリソースの設定の監視と管理を行います。リソースの状態や変更を追跡するために使用されますが、リソースのデプロイを直接制限することはできません。AWS Configは、既存のリソースに対して監視や評価を行うツールであり、ポリシー違反を検出することができますが、リソースの作成を制御するためには予防コントロールが必要です。

結論

最適な解決策は、Cです。予防的ガードレールを使用することで、開発OU内でバースト可能なインスタンスのデプロイのみを許可し、その他のサービスを使用できないように制限できます。これにより、要件を満たし、効率的な管理が可能になります。
 
 

329-AWS SAP AWS 「理論・実践・一問道場」カスタムリソース

 

理論

1. AWS CloudFormation

  • AWS CloudFormationは、AWSリソースをテンプレートから自動的に作成、管理、削除できるサービスです。これを使うことで、手動でリソースを設定する手間を省き、インフラの管理をコード化できます。

2. カスタムリソース

  • カスタムリソースは、CloudFormationテンプレート内で定義する特別なリソースで、AWSの標準リソースだけでは解決できないような処理を自動化するために使われます。たとえば、Lambda関数を使用してS3バケット内のファイルを削除するなどのカスタムな操作を行うことができます。
具体的な流れとしては以下の通りです：
  1. Lambda関数：まず、Lambda関数を作成し、S3バケット内のオブジェクトを削除する処理を記述します。
  1. カスタムリソース：次に、CloudFormationテンプレート内でこのLambda関数をカスタムリソースとして定義します。このカスタムリソースをスタックの削除前に呼び出すように設定します。
  1. DependsOn属性：カスタムリソースでLambda関数を呼び出した後、S3バケットの削除を行いたいため、DependsOn属性を使用して、Lambda関数の削除が完了してからS3バケットの削除が行われるように順序を指定します。

3. AWS Lambda

  • AWS Lambdaは、サーバーを管理することなくコードを実行できるサービスです。イベント（例えばCloudFormationスタックの削除時）に基づいてコードを自動的に実行できます。CloudFormationのカスタムリソースとしてLambdaを使うと、特定の操作（ファイル削除など）を行うことができます。

4. S3バケットとオブジェクト

  • Amazon S3は、データを保存するためのオブジェクトストレージサービスです。バケットはデータを保存する容器であり、その中に「オブジェクト」（ファイル）が格納されます。S3バケットやその中のオブジェクトをCloudFormationで削除する場合、バケット内のオブジェクトを先に削除しないとバケットの削除が失敗します。

5. DependsOn属性

  • DependsOn属性は、CloudFormationでリソースの削除や作成を順番に実行するために使います。例えば、S3バケットを削除する前に、その中のオブジェクトを削除してからバケットを削除したい場合に使います。

解決方法

この問題では、CloudFormationスタックを削除する際にS3バケット内のオブジェクトが残っていると削除に失敗することがあります。Lambda関数を使って、CloudFormationスタックの削除前にS3バケット内のオブジェクトを削除するようにすると、問題が解決します。この操作は「カスタムリソース」としてCloudFormationに組み込むことができ、DependsOn属性を使って削除順序を管理することができます。

まとめ

  • CloudFormationでリソース管理を自動化できる。
  • Lambda関数を使って、CloudFormationで削除できないものを削除できる。
  • S3バケットの削除には、まずバケット内のオブジェクトを削除する必要がある。
  • DependsOnを使って、削除の順序を制御することができる。
このような方法を使うことで、AWSでのリソース管理が効率よく、エラーなく行えるようになります。

実践

略

一問道場

質問 #329
ある金融サービス会社は、Amazon EC2インスタンスとAWS Lambda関数で複雑なマルチティアアプリケーションを実行しています。このアプリケーションは、一時的なデータをAmazon S3に格納します。S3オブジェクトは45分間のみ有効で、24時間後に削除されます。会社はアプリケーションの各バージョンを、AWS CloudFormationスタックを起動することによって展開します。スタックは、アプリケーションを実行するために必要なすべてのリソースを作成します。会社が新しいアプリケーションバージョンを展開して検証した後、古いバージョンのCloudFormationスタックを削除します。しかし、会社は最近、古いアプリケーションバージョンのCloudFormationスタックを削除しようとしましたが、その操作は失敗しました。分析によると、CloudFormationは既存のS3バケットを削除できませんでした。ソリューションアーキテクトは、アプリケーションのアーキテクチャに大きな変更を加えることなくこの問題を解決する必要があります。
どのソリューションがこれらの要件を満たしていますか？
A. 与えられたS3バケットからすべてのファイルを削除するLambda関数を実装し、このLambda関数をCloudFormationスタックのカスタムリソースとして統合します。カスタムリソースには、S3バケットのリソースを指すDependsOn属性が必要です。
B. CloudFormationテンプレートを変更して、一時的なファイルをAmazon S3ではなくAmazon Elastic File System (Amazon EFS)ファイルシステムに格納するようにします。Lambda関数をファイルシステムと同じVPC内で実行するように構成し、EC2インスタンスとLambda関数にファイルシステムをマウントします。
C. CloudFormationスタックを変更して、S3オブジェクトが作成されてから45分後に期限切れとなるS3ライフサイクルルールを作成します。S3バケットのリソースを指すDependsOn属性を追加します。
D. CloudFormationスタックを変更して、S3バケットにDeleteという値のDeletionPolicy属性を追加します。

解説

この問題では、AWS CloudFormationスタックを削除する際にS3バケットが削除できない問題について解決策を求められています。特に、S3オブジェクトが削除されるべきなのに、スタックの削除時にバケット削除が失敗するというシナリオです。

解説

A. Lambda関数を実装し、CloudFormationのカスタムリソースとして統合する

  • 適切な解決策です。
  • このアプローチでは、CloudFormationスタックの削除時にカスタムリソースを使用してS3バケット内のオブジェクトを削除します。Lambda関数をカスタムリソースとして使用することで、S3バケット内のファイルが削除された後にバケット自体を削除するようにできます。また、DependsOn属性を使って、S3バケットのリソース削除を確実に待つことができます。

B. Amazon EFSに変更し、ファイルシステムをEC2インスタンスやLambda関数にマウントする

  • 不適切です。
  • Amazon EFSを使用することは、一時的なデータのストレージにおいて有効ですが、このシナリオではアプリケーションの変更を最小限に抑える必要があります。既存のS3バケットをEFSに移行することで、アーキテクチャに大きな変更が加わり、要件に反します。

C. S3ライフサイクルルールを作成し、オブジェクトの有効期限を45分に設定する

  • 不適切です。
  • ライフサイクルルールを設定してオブジェクトを期限切れにすることは可能ですが、オブジェクトの削除が即座に行われるわけではありません。また、CloudFormationの削除時にS3バケット自体を削除する際には、オブジェクトがすでに削除されている必要があり、この方法では不十分です。

D. S3バケットにDeletionPolicy属性を設定して削除する

  • 不適切です。
  • DeletionPolicy属性の設定は、CloudFormationスタックの削除時にリソースを保持するか削除するかを指定するものであり、バケット内のオブジェクトが削除されない限り、バケット自体を削除することができません。この方法は、S3オブジェクトの削除に関する問題を解決するものではありません。

最適な解決策

Aの方法が最も適切です。Lambda関数を使用して、CloudFormationのスタック削除時にS3バケット内のオブジェクトを確実に削除し、その後バケット自体を削除するプロセスを管理できます。この方法は、アプリケーションのアーキテクチャにほとんど変更を加えることなく問題を解決できます。
 
 

330-AWS SAP AWS 「理論・実践・一問道場」API Gateway ゲーム

 

理論

以下は ALB と API Gateway の簡潔な比較です。
特徴
ALB
API Gateway
使用ケース
EC2やLambdaへのリクエスト分散
REST APIの管理とデータ転送
スケーリング
自動スケーリング可能
自動スケーリング
セキュリティ
SSL/TLS、WAF統合
認証、APIキー、IAM、Cognito統合
API管理機能
基本的な負荷分散のみ
詳細なAPI管理（バージョン管理、スロットリング）
キャッシュ
提供なし
レスポンスキャッシュ機能あり
コスト
EC2、Lambdaの使用料
リクエスト数とデータ転送量に基づく
  • ALB: EC2やLambdaへのリクエスト分散に最適。
  • API Gateway: 詳細なAPI管理や認証、キャッシュが必要な場合に最適。
 
区別
  • ALB (Application Load Balancer) は 1対多 の関係です。
    • ALBは、1つのロードバランサーが複数のターゲット（EC2インスタンス、コンテナなど）にリクエストを振り分けます。
    • つまり、1つのエンドポイントに対する複数のリクエストを、複数のバックエンドに分配します。
  • API Gateway は 多対1 の関係です。
    • API Gatewayは、**複数のクライアント（例えば、モバイルアプリやウェブアプリ）**からのリクエストを受け付けて、1つのAPI Gatewayエンドポイントを介して処理します。
    • つまり、多くのクライアントが1つのAPI Gatewayにリクエストを送り、その後バックエンド（例えば、Lambda関数やEC2）に振り分けられます。
このように、ALBは1つのエンドポイントが複数のターゲットに振り分ける形であり、API Gatewayは複数のクライアントが1つのエンドポイントにリクエストを送る形です。

実践

略

一問道場

会社はモバイルゲームを開発しました。このゲームのバックエンドは、オンプレミスのデータセンターにある複数の仮想マシンで実行されています。ビジネスロジックはREST APIを使用して公開され、複数の機能があります。プレイヤーのセッションデータは中央のファイルストレージに格納されています。バックエンドサービスは、スロットリングとライブおよびテストトラフィックの区別のために異なるAPIキーを使用しています。ゲームバックエンドへの負荷は一日を通して変動します。ピーク時にはサーバー容量が不足し、プレイヤーセッションデータを取得する際にレイテンシーの問題もあります。経営陣は、ゲームの変動する負荷に対応し、低レイテンシーのデータアクセスを提供できるクラウドアーキテクチャを提案するようソリューションアーキテクトに求めています。APIモデルは変更しないことが前提です。
どのソリューションがこれらの要件を満たしますか？
A. REST APIをNetwork Load Balancer (NLB)で実装し、ビジネスロジックをNLBの背後にあるAmazon EC2インスタンスで実行します。プレイヤーのセッションデータはAmazon Aurora Serverlessに格納します。
B. REST APIをApplication Load Balancer(ALB)で実装し、ビジネスロジックをAWS Lambdaで実行します。プレイヤーのセッションデータはAmazon DynamoDBのオンデマンドキャパシティで格納します。
C. REST APIをAmazon API Gatewayで実装し、ビジネスロジックをAWS Lambdaで実行します。プレイヤーのセッションデータはAmazon DynamoDBのオンデマンドキャパシティで格納します。
D. REST APIをAWS AppSyncで実装し、ビジネスロジックをAWS Lambdaで実行します。プレイヤーのセッションデータはAmazon Aurora Serverlessに格納します。

解説

この問題では、ゲームの変動する負荷に対応し、低レイテンシーでデータアクセスを提供するアーキテクチャが求められています。特に、APIモデルの変更は避けたいという制約があり、どの選択肢が最適かを評価します。

解説：

A. REST APIをNLBで実装し、ビジネスロジックをEC2インスタンスで実行する

  • NLB（Network Load Balancer）は、トラフィックの分散を効率的に行うことができますが、通常はステートレスなトラフィック向けであり、REST APIに関しては管理の容易さやAPIルーティングの柔軟さに欠ける部分があります。
  • EC2インスタンスを使用すると、手動でスケーリングを調整する必要があり、トラフィックのピーク時に自動的にスケールする機能がないため、ゲームの変動する負荷にうまく対応できません。
  • Aurora Serverlessはスケーラブルですが、低レイテンシーアクセスに最適な設計ではないため、この選択肢は最適ではありません。

B. REST APIをALBで実装し、ビジネスロジックをLambdaで実行する

  • ALB（Application Load Balancer）は、Webアプリケーション向けに特化したロードバランサーで、APIのURLベースのルーティングや高度なトラフィック管理が可能です。これにより、柔軟なAPI管理が可能となります。
  • AWS Lambdaはサーバーレスで、トラフィックの変動に応じて自動的にスケールします。リクエスト数に合わせて実行されるため、コスト効率も高く、サーバー管理が不要です。
  • DynamoDBのオンデマンドキャパシティは、必要なときにスケールし、アクセスが増えるときでも高いパフォーマンスを維持できます。これにより、低レイテンシーのデータアクセスが実現できます。

C. REST APIをAPI Gatewayで実装し、ビジネスロジックをLambdaで実行する

  • API Gatewayは、REST APIの管理に最適化されたサービスで、非常に高いスケーラビリティと柔軟性を提供します。API Gatewayはリクエストのルーティング、認証、制限などを容易に管理でき、ゲームのような多くのリクエストを効率的に処理できます。
  • Lambdaと組み合わせることで、スケーラブルなアーキテクチャを提供し、リクエスト数に応じて自動的にスケールします。
  • DynamoDBのオンデマンドキャパシティは、セッションデータなどのストレージに最適で、高パフォーマンスと低レイテンシーでアクセスできるため、このアーキテクチャは非常に効率的で適しています。

D. REST APIをAppSyncで実装し、ビジネスロジックをLambdaで実行する

  • AppSyncは、GraphQL APIを管理するためのサービスです。REST APIを使用するという制約があるため、AppSyncは適切な選択肢ではありません。GraphQLはREST APIとは異なるアーキテクチャモデルであるため、この選択肢は要件を満たしません。

結論：

最適な解決策は C の選択肢です。API Gateway と Lambda の組み合わせは、スケーラビリティと低レイテンシーアクセスの両方を提供し、DynamoDBのオンデマンドキャパシティはデータアクセスに非常に適しています。これにより、ゲームの負荷変動にも柔軟に対応でき、性能が求められる環境で最適な解決策となります。
 
 
Relate Posts
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
初心者向け！コンテナ化WordPressサイト構築ガイド（超詳細版）
Lazy loaded image
EFSを活用！AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
00-AWS SAP「理論・実践・10問道場」
Lazy loaded image
01-AWS SAP「理論・実践・10問道場」
Lazy loaded image
02-AWS SAP「理論・実践・10問道場」
Lazy loaded image
31-AWS SAP「理論・実践・10問道場」33-AWS SAP「理論・実践・10問道場」
Loading...
Catalog
0%
minami
minami
一个普通的干饭人🍚
Announcement

🎉 ブログへようこそ 🎉

notion image
名前:みなみ独立事務所
性別:男
国籍:China
完全独学だけで基本情報をはじめ31個の資格を仕事をしながら合格。 現在はIT会社の技術担当や、ブログの執筆や学習支援などを手掛けています。 独学で合格できる学習法、勉強法、試験対策を配信します！

📚 主な内容

💻 IT・システム開発
🏠 不動産 × 宅建士
🎓 MBA 学習記録

🔍 コンテンツの探し方

現在、サイトのデザインはシンプルなため、情報がやや探しにくいかもしれません。
気になるテーマを探す際は、タグ検索の利用をおすすめします。
Search | みなみの風物詩
自分らしく未来へ
Search | みなみの風物詩
https://www.minami.ac.cn/search
Search | みなみの風物詩
Catalog
0%