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

type

status

date

slug

summary

401-AWS SAP AWS 「理論・実践・一問道場」SMBプロトコル

理論

SMB (Server Message Block) プロトコルは、主にWindows環境でファイル共有やプリンター共有に使用される通信プロトコルです。ただし、Windows以外のOSでもサポートされています。

AWS Outposts は、AWSが提供するハイブリッドクラウドソリューションの1つで、AWSのインフラストラクチャとサービスをオンプレミス環境に拡張するためのものです。

これにより、AWSのクラウドサービスをデータセンター、オンプレミスの施設、またはエッジロケーションで利用でき、クラウドと同様の体験をローカル環境で実現します。

災害復旧 (Disaster Recovery, DR) におけるクラウド活用の基本知識

クラウド環境を活用した災害復旧 (DR) ソリューションの設計では、以下のポイントが重要です。

1. 災害復旧要件の明確化

RTO (Recovery Time Objective): サービスを復旧するまでの許容時間（例: 5分以内）。

RPO (Recovery Point Objective): データ損失の許容範囲（例: 数秒～数時間）。

この問題では「5分以内に利用可能」がRTOに該当。

2. ストレージ選択の基準

Amazon S3 Standard-IA: 低頻度アクセスデータ向けで、コストとパフォーマンスのバランスが良い。

Amazon S3 Glacier/Glacier Deep Archive: アクセス頻度がさらに低いアーカイブデータ向け。ただし、復元に時間がかかる（数分～数時間）。

Amazon FSx for Windows File Server: SMBアクセスに特化した高パフォーマンスなファイルシステム。

3. SMBプロトコルのサポート

オンプレミスアプリケーションがSMBを使用している場合、クラウド上でもSMBを利用可能なサービスが必要。

Amazon FSx: SMBアクセスをネイティブでサポート。
Amazon S3 File Gateway: SMB共有を介してAmazon S3にデータを保存可能。

4. データアクセス頻度に応じた設計

頻繁にアクセスされるデータ: 高速ストレージ（例: SSDやAmazon FSx）を使用。

低頻度アクセスデータ: S3 Standard-IAやGlacierなど、コスト効率を重視したストレージを選択。

5. コスト効率と柔軟性

運用コストを抑えるため、必要に応じてストレージ階層を組み合わせる。

メタデータのような小規模で高頻度アクセスが必要なデータと、大容量で低頻度アクセスのデータ（例: 画像ファイル）を分けて管理。

AWSサービスの選択ポイント

サービス	特徴	適用シナリオ
Amazon S3 File Gateway	SMB共有を通じてデータをS3に保存可能。S3 Standard-IAやGlacierと連携可能。	データセンターとAWS間で低頻度アクセスデータを共有する場合に適用。
Amazon FSx for Windows	SMBプロトコルをネイティブでサポート。高パフォーマンス。	高頻度アクセスが必要なアプリケーションやファイル共有に最適。
Amazon S3 Glacier	コスト効率が良いアーカイブストレージ。ただし復元に時間がかかる。	長期保存が必要なデータ（例: バックアップやアーカイブ）。

まとめ

災害復旧設計では、要件に応じたRTOとRPOの設定が最優先です。AWSのサービスは、コスト効率とアクセス頻度に応じて柔軟に選択可能です。特に、Amazon S3 File Gateway はSMBプロトコルをサポートし、コスト効率と簡便性を兼ね備えた強力な選択肢です。

実践

略

一問道場

質問 #401

ある会社が、自社のデータセンターで稼働しているアプリケーションの災害復旧（DR）ソリューションを設計したいと考えています。このアプリケーションは、SMBファイル共有に書き込みを行い、2つ目のファイル共有にコピーを作成します。両方のファイル共有はデータセンター内にあります。このアプリケーションは2種類のファイルを使用します：メタデータファイルとイメージファイルです。

会社は、このコピーをAWSに保存したいと考えています。また、災害が発生した場合にはデータセンターまたはAWSからSMBを使用してデータにアクセスできる必要があります。このデータのコピーはほとんどアクセスされることはありませんが、5分以内に利用可能でなければなりません。

選択肢

A. Amazon S3ストレージを備えたAWS Outpostsをデプロイします。Outposts上のWindows Amazon EC2インスタンスをファイルサーバーとして構成します。

B. Amazon FSx File Gatewayをデプロイします。Amazon FSx for Windows File ServerのマルチAZファイルシステム（SSDストレージを使用）を構成します。

C. Amazon S3 File Gatewayをデプロイします。S3 File Gatewayを構成して、メタデータファイルにはAmazon S3 Standard-Infrequent Access（S3 Standard-IA）を使用し、イメージファイルにはS3 Glacier Deep Archiveを使用します。

D. Amazon S3 File Gatewayをデプロイします。S3 File Gatewayを構成して、メタデータファイルとイメージファイルの両方にAmazon S3 Standard-Infrequent Access（S3 Standard-IA）を使用します。

解説

要件

SMBアクセス

データセンターおよびAWSからSMBでデータにアクセス可能である必要があります。

これは、AWS側でSMBプロトコルをサポートするソリューションが必要であることを意味します。

ディザスタリカバリ (DR)

AWSにデータをコピーし、災害時にはそこからデータを利用可能にする必要があります。

低頻度アクセス

データのコピーはほとんどアクセスされないが、災害時には5分以内に利用可能でなければなりません。

ファイルの種類

メタデータファイルとイメージファイルの2種類。これらに異なるストレージポリシーを適用する可能性があります。

選択肢の分析

A: AWS Outposts + Windows EC2インスタンス

利点:

Outpostsはオンプレミス環境にAWSのハードウェアを持ち込み、AWSリソースをローカルで利用可能にします。
Windows EC2インスタンスを使えばSMB共有を提供可能。

欠点:

Outpostsはコストが非常に高く、要件に比べて過剰なソリューション。
データの「低頻度アクセス」には適していません。

➡ 不適切。

B: Amazon FSx File Gateway + FSx for Windows File Server

利点:

Amazon FSx for Windows File Serverは、SMBプロトコルをネイティブにサポート。データセンターとAWSの両方からSMBでアクセス可能。
マルチAZ構成により高可用性を確保。

欠点:

FSxは高パフォーマンスが求められるユースケース向けであり、「低頻度アクセス」にはコスト効率が低い。
メタデータファイルとイメージファイルのストレージ要件に応じた柔軟性がない。

➡ 不適切。

C: Amazon S3 File Gateway (S3 Standard-IA + Glacier Deep Archive)

利点:

Amazon S3 File Gatewayは、オンプレミスのアプリケーションに対してSMB共有を提供可能。
S3 Standard-IAは低頻度アクセス用、Glacier Deep Archiveはさらにコスト効率が良い長期アーカイブ用。
メタデータファイルとイメージファイルで異なるストレージポリシーを適用可能。

欠点:

Glacier Deep Archiveはリストアに時間がかかり、5分以内のアクセス要件を満たさない可能性がある。

➡ 不適切（要件に完全には一致しない）。

D: Amazon S3 File Gateway (S3 Standard-IAのみ)

利点:

S3 File GatewayがSMB共有を提供。オンプレミスおよびAWSからのアクセスが可能。
S3 Standard-IAは低頻度アクセスデータに最適で、5分以内のアクセス要件を満たす。
メタデータファイルとイメージファイルを同じストレージクラスで管理することで運用が簡素化される。

欠点:

ストレージコストはやや上がる可能性がある（イメージファイル用にGlacier Deep Archiveを使用しないため）。

➡ 最適な選択肢。

結論

最適な選択肢は D: Amazon S3 File Gateway を利用し、S3 Standard-IA を使用する です。

この構成は、以下の理由で要件を満たします：

SMBでのアクセスをサポート。

低頻度アクセスデータにコスト効率が高い。

5分以内にデータを利用可能。

402-AWS SAP AWS 「理論・実践・一問道場」Amazon WorkSpaces

理論

1. 仮想デスクトップインフラストラクチャ（VDI）の活用

VDIとは: リモートでデスクトップ環境を提供する技術。クラウド上に仮想デスクトップをホストし、従業員が任意のデバイスからアクセス可能。

代表的なサービス:

Amazon WorkSpaces: WindowsやLinuxの仮想デスクトップを提供。既存のオンプレミス環境との統合が容易。

2. ディレクトリサービスとの統合

目的: 既存のユーザーアカウントをリモート環境でもそのまま使用可能にする。

主要ツール:

AD Connector: Amazon WorkSpacesとオンプレミスActive Directoryを接続。追加の複雑な設定なしで統合可能。

3. 多要素認証（MFA）の導入

必要性: 災害時などのリモートワーク環境では、セキュリティリスクが高まるためMFAが不可欠。

一般的な構成:

RADIUSサーバーを使用してMFAを有効化。
簡易なログイン体験を提供しながら、セキュリティを確保。

4. VPN（仮想プライベートネットワーク）の利用

目的: クラウド環境とオンプレミス環境間の安全な通信を確保。

重要性: オンプレミスリソースやディレクトリサービスへのアクセスが求められる場合に必須。

5. クラウドアプリケーションストリーミングの特徴

Amazon AppStream 2.0: アプリケーション単位でのストリーミングに特化。

適用範囲: 特定の業務アプリケーションのみをリモート利用する場合に適しているが、フルデスクトップの再現には不向き。

6. 選定基準のポイント

ユーザー体験: 現在のデスクトップ環境を完全に再現可能か。

セキュリティ: MFAやVPNを使用してリモートアクセスの安全性を確保。

スケーラビリティ: 必要に応じてリモート環境を迅速に拡張可能か。

まとめ

災害時のリモートワーク環境では、仮想デスクトップサービス（例: Amazon WorkSpaces）が優れた選択肢です。特に、Active Directory統合やMFA、VPN接続を組み合わせることで、既存環境に近いユーザー体験を安全かつ迅速に提供できます。

実践

略

一問道場

質問 #402

ある企業が、予期せぬ災害時に400人の従業員をリモートワーク環境に移行できるソリューションを構築しようとしています。

従業員のデスクトップにはWindowsとLinuxのオペレーティングシステムが混在しており、Webブラウザやメールクライアントなど、さまざまな種類のソフトウェアがインストールされています。

ソリューションアーキテクトは、従業員が既存の認証情報を使用できるよう、企業のオンプレミスActive Directoryと統合可能なソリューションを実装する必要があります。このソリューションは、多要素認証（MFA）を提供し、既存のデスクトップ環境と同じユーザー体験を再現する必要があります。

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

選択肢

Amazon WorkSpacesをクラウドデスクトップサービスとして使用します。

オンプレミスネットワークへのVPN接続を設定します。AD Connectorを作成してオンプレミスActive Directoryに接続します。AWSマネジメントコンソールを使用してAmazon WorkSpacesのMFAを有効化します。

Amazon AppStream 2.0をアプリケーションストリーミングサービスとして使用します。

従業員向けにDesktop Viewを構成します。オンプレミスネットワークへのVPN接続を設定します。オンプレミスでActive Directory Federation Services (AD FS) をセットアップします。VPN接続を通じてVPCネットワークをAD FSに接続します。

Amazon WorkSpacesをクラウドデスクトップサービスとして使用します。

オンプレミスネットワークへのVPN接続を設定します。AD Connectorを作成してオンプレミスActive Directoryに接続します。MFAのためにRADIUSサーバーを構成します。

Amazon AppStream 2.0をアプリケーションストリーミングサービスとして使用します。

オンプレミスでActive Directory Federation Servicesをセットアップします。AppStream 2.0へのユーザーアクセスを許可するためにMFAを構成します。

解説

正解: C

理由

要件を詳細に分析すると、以下の要素が重要です：

リモートワーク環境の提供

400人の従業員が予期せぬ災害時にリモートワークできる環境を構築する必要がある。

この要件を満たすには、従業員が現在使用しているデスクトップ環境（WindowsとLinux）をそのまま再現できる クラウドデスクトップサービス が適しています。

これには、Amazon WorkSpaces（仮想デスクトップインフラストラクチャ）が最適です。

オンプレミスActive Directoryとの統合

既存の認証情報を使用できる必要があるため、オンプレミスActive Directoryとの統合が必須です。

これには、Amazon WorkSpacesが提供する AD Connector を使用します。

多要素認証（MFA）の提供

高いセキュリティ要件を満たすために、多要素認証を設定する必要があります。

WorkSpacesでは、RADIUSサーバーを構成することでMFAを実現できます。

ユーザー体験の再現

現在のデスクトップ環境を再現することが必要です。

AppStream 2.0 はアプリケーションストリーミングに特化しており、完全なデスクトップ環境の再現には向きません。

選択肢の評価

Amazon WorkSpaces、AD Connectorを使用している点は正しいですが、MFAの構成が「AWSマネジメントコンソール」で有効化されると記載されています。この設定ではRADIUSサーバーによるMFAを提供できないため、要件を完全に満たしていません。

Amazon AppStream 2.0 を使用していますが、AppStream 2.0 はデスクトップ全体のストリーミングよりも特定のアプリケーションストリーミングに向いています。また、Active Directory Federation Services (AD FS) をセットアップする複雑さやユーザー体験の観点から、要件に適していません。

Amazon WorkSpaces と AD Connector を使用してオンプレミスActive Directoryに統合し、さらに RADIUSサーバーを使用してMFAを提供しています。この構成は、全ての要件を満たします。

AppStream 2.0 を使用しているため、デスクトップ全体のユーザー体験を再現するには不十分です。また、構成が複雑であり、災害時にスムーズなリモートワークを提供するには適していません。

結論

選択肢 C が、要件を最も効率的かつ完全に満たすソリューションです。

403-AWS SAP AWS 「理論・実践・一問道場」Amazon Connect

理論

Amazon Connectと通話管理

Amazon Connectは、クラウドベースのコンタクトセンターサービスであり、顧客とのインタラクションを管理するための多くの強力な機能を提供します。ここでは、スパム通話や不要な通話を効率的に管理するための一般的なアプローチや、Amazon Connectの関連機能について解説します。

1. Amazon Connectの基本的な概念

Amazon Connectは、顧客との音声通話、チャット、メール、メッセージなどのインタラクションをシームレスに統合するクラウドサービスです。コンタクトセンターの運営に必要な機能を、簡単に設定・運用できるように提供されています。エージェントは、Amazon Connectの「Contact Control Panel（CCP）」を使用して通話やチャットを管理します。

2. スパム通話の管理と自動化

コンタクトセンターでは、スパム通話や自動音声応答（IVR）などの不要な通話が生産性を低下させ、コストを増加させる原因となります。そのため、以下のような方法でスパム通話を管理し、自動的にブロックすることが重要です。

A. UpdateContactAttributes APIの利用

Amazon Connectでは、UpdateContactAttributes APIを使用して、通話に関連する属性を変更することができます。このAPIを活用すると、通話がスパムであるかどうかを示す属性をエージェントがマークすることができ、その情報をもとに次回以降の通話をブロックすることが可能です。これにより、スパム通話の処理を自動化できます。

B. Lambda関数とDynamoDBの連携

Lambda関数を使用して、スパム通話の番号を動的に管理することができます。DynamoDBを使ってスパム番号をデータベースとして保存し、通話がその番号からかかってきた場合に自動的に通話をブロックする仕組みを作ることが可能です。これにより、スパム通話の管理を効率化し、エージェントの手間を省くことができます。

C. Contact Lensによる通話分析

Amazon Connectの「Contact Lens」は、音声通話やチャットをリアルタイムで分析し、感情分析やインサイトを提供する機能です。この機能を活用して、通話の内容からスパムや迷惑通話を自動的に識別することができます。Contact Lensのルールをカスタマイズすることで、スパム通話の検出をより効果的に行えます。

3. クイックコネクト（Quick Connect）の活用

Quick Connectは、エージェントがよく使用する通話フローを事前に設定しておく機能です。スパム通話が検出された場合、エージェントはQuick Connectを使って簡単にその通話を別のフローに転送したり、スパム通話専用のフローに移すことができます。これにより、エージェントの負担を軽減し、効率的に通話を管理することができます。

4. 通話フローのカスタマイズ

Amazon Connectでは、通話フローをカスタマイズして通話の処理を柔軟に変更できます。たとえば、通話開始時に発信者の入力を求め、入力がない場合に自動的にスパムとしてマークしたり、通話がエージェントに接続される前に検出した情報に基づいて通話を分類することができます。

5. 多要素認証（MFA）によるセキュリティ強化

スパム通話の管理だけでなく、コンタクトセンターのセキュリティ強化も重要です。Amazon Connectでは、MFAを導入することで、エージェントや管理者のアクセスをより安全に管理できます。MFAを利用することで、不正アクセスを防止し、センターのデータを保護することができます。

まとめ

Amazon Connectを利用したコンタクトセンターの運用において、スパム通話の管理は重要な課題です。Lambda関数、DynamoDB、Contact Lens、Quick Connectなどを組み合わせることで、スパム通話の検出と自動ブロックを効率化できます。さらに、通話フローのカスタマイズやセキュリティ対策を適切に行うことで、コンタクトセンターの運用効率を大幅に向上させることが可能です。

実践

略

一問道場

質問 #403

ある企業がAmazon Connectを使用してコンタクトセンターを運営しています。エージェントからは、コンピュータによって発信された通話が多く報告されています。企業は、これらの通話がコストや生産性に与える影響を懸念しています。この企業は、エージェントが通話をスパムとしてマークし、その後自動的にその番号がエージェントに転送されないようにブロックするソリューションを求めています。

この要件を満たす、最も運用効率の良い解決策はどれですか？

Contact Control Panel（CCP）をカスタマイズし、AWS Lambda関数を呼び出すための「通話をフラグ付けする」ボタンを追加します。このLambda関数は、UpdateContactAttributes APIを呼び出します。スパム番号はAmazon DynamoDBテーブルに格納します。コンタクトフローを変更して、更新された属性を検索し、Lambda関数を使ってDynamoDBテーブルの読み書きを行います。

Amazon ConnectのContact Lensルールを使用してスパム通話を検出します。スパム番号を格納するためにAmazon DynamoDBテーブルを使用します。コンタクトフローを変更して、ルールを検索し、AWS Lambda関数を使ってDynamoDBテーブルの読み書きを行います。

スパム番号を格納するためにAmazon DynamoDBテーブルを使用します。エージェントがCCPからスパム通話を転送できるように、クイックコネクトを作成します。クイックコネクトのコンタクトフローを変更して、AWS Lambda関数を呼び出し、DynamoDBテーブルに書き込むようにします。

最初のコンタクトフローを変更して、発信者から入力を求めます。エージェントが入力を受け取らなかった場合、エージェントはその発信者をスパムとしてマークします。スパム番号を格納するためにAmazon DynamoDBテーブルを使用し、AWS Lambda関数でDynamoDBテーブルの読み書きを行います。

解説

この問題では、Amazon Connectを使用したコンタクトセンターで、スパム呼び出しを効率的に管理する方法を求めています。エージェントがスパム通話をマークし、その番号を自動的にブロックするために、どの解決策が最も運用効率が良いかを判断する必要があります。

以下、各選択肢についての解説です。

A. Contact Control Panel (CCP) をカスタマイズして Lambda 関数を呼び出す

説明: CCPをカスタマイズし、エージェントが通話をスパムとしてマークできるボタンを追加する方法です。このボタンが押されると、AWS Lambda関数が呼び出され、UpdateContactAttributes APIを使って通話の属性を更新します。スパム番号はDynamoDBに保存され、コンタクトフローでその属性を確認することで、スパム番号が次回以降の通話でエージェントに転送されないようにします。

評価: この方法は、エージェントがスパム通話を即座にマークし、DynamoDBを使ってその番号を追跡できるため、運用効率が非常に高いです。さらに、カスタマイズされたCCPとLambdaによる自動化により、手動での管理が最小限に抑えられます。

B. Contact Lens ルールと Lambda 関数を使ってスパム通話を検出

説明: Amazon ConnectのContact Lens機能を使い、スパム通話を自動的に検出します。検出されたスパム番号はDynamoDBに保存され、コンタクトフローがその情報を参照して、Lambda関数を使用して番号を管理します。

評価: Contact Lensは自然言語処理を使用して通話内容を解析しますが、事前にスパム番号を指定する管理方法には向いていないため、スパム通話の検出に関しては、やや複雑で効率的ではない可能性があります。

C. クイックコネクトを使ってエージェントがスパム通話を転送

説明: エージェントがスパム通話を「クイックコネクト」で転送できる方法です。この方法では、エージェントが通話をスパムとしてマークし、Lambda関数を通じてDynamoDBに記録されることになります。

評価: クイックコネクトを使用するアプローチは、エージェントにとっての操作が増えるため、運用効率が低くなります。また、通話の自動検出や自動ブロックが不足しており、手動での介入が多くなる可能性があります。

D. 初期コンタクトフローで発信者入力を求め、エージェントがスパムをマーク

説明: 最初のコンタクトフローで発信者からの入力を求め、エージェントが入力を受け取らなかった場合にスパムとしてマークする方法です。この場合もDynamoDBにスパム番号を保存し、Lambda関数を通じて管理します。

評価: この方法では、発信者の入力が必須となるため、エージェントの操作が必要であり、手動でスパムを識別することになるため効率的ではありません。自動化が不足している点が課題です。

最適な解決策

最も運用効率が良い解決策は A です。エージェントが通話をスパムとしてマークできるようにCCPをカスタマイズし、Lambda関数を使用してDynamoDBにスパム番号を保存し、コンタクトフローで自動的にその情報を参照することで、スパム番号を効率的に管理できます。このアプローチは、エージェントの負担を軽減し、自動化されたプロセスでスパム通話をブロックできるため、非常に効率的です。

404-AWS SAP AWS 「理論・実践・一問道場」Amazon Kinesis Data Stream + AWS Lambda + Amazon SNS

理論

1. リアルタイムデータストリーミングと処理のためのAWSサービス

Amazon Kinesis

Amazon Kinesisは、リアルタイムでデータを取り込み、処理するためのフルマネージドサービスです。主に3つの主要コンポーネントがあります：

Kinesis Data Streams: 大規模で高頻度なデータをリアルタイムでストリーミングし、後で分析するために保存できます。センサーからのデータストリームを取り込むのに適しています。
Kinesis Data Firehose: データをリアルタイムで取り込み、指定されたデスティネーション（S3、Redshiftなど）に送信するサービスです。リアルタイム分析というよりは、データの集積や保存に役立ちます。
Kinesis Data Analytics: ストリーミングデータをリアルタイムで分析し、SQLやアプリケーションを使ってデータを処理できます。簡単なデータ変換、フィルタリング、集計などをリアルタイムで行えます。

AWS Lambda

AWS Lambdaは、サーバーレスでコードを実行できるサービスで、特定のイベント（この場合、Kinesis Data Streamsからのデータ）に応じて自動的にコードを実行します。Lambdaは、データがKinesisに到達した際にそれを処理し、分析を行うのに役立ちます。

Lambdaの利用により、従来のサーバー管理を必要とせず、スケーラブルで効率的なリアルタイム分析が可能です。

Amazon SNS (Simple Notification Service)

Amazon SNSは、通知サービスであり、電子メールやSMSなどでメッセージを送信するために使用されます。KinesisやLambdaで分析した結果、アラートが発生した際に、SNSを利用して即座に通知を送ることができます。SNSは、低レイテンシで大規模な通知配信をサポートしており、広範囲なアラート通知システムの構築に役立ちます。

2. リアルタイムデータストリーミングのアーキテクチャ設計

以下のプロセスは、リアルタイムデータストリーミングと通知システムを構築する際の一般的な設計方法です。

データのストリーミング:

企業が工場に設置したセンサーが環境データ（湿度、温度、光など）をリアルタイムで送信します。これらのデータはAmazon Kinesis Data Streamsを利用してAWSクラウドに取り込まれます。Kinesis Data Streamsは、高スループットでデータをリアルタイムで収集するのに最適です。

データの処理と分析:

取り込んだデータはAWS Lambdaを使用して処理されます。Lambda関数は、Kinesisからデータを取得し、分析を行います。例えば、センサー値がしきい値を超えた場合には、それを検出してアラートをトリガーします。

また、Amazon Kinesis Data Analyticsを使用すると、SQLを用いてリアルタイムデータの分析や集計ができます。これにより、データのパターンを分析したり、異常検出を行ったりできます。

通知の発行:

もしデータが許容範囲外に入った場合、Amazon SNSを利用してアラートを運用チームに送信します。これにより、リアルタイムで問題に対応できるようになります。

通知の受信:

SNSの通知は、運用チームのメンバーが迅速に対応できるように電子メールやSMSで送られます。これにより、工場内で即時の対応が可能となります。

3. サービス選択のポイント

Kinesis Data Streams vs Kinesis Data Firehose:

Kinesis Data Streamsは、ストリーミングデータをリアルタイムで消費して処理する場合に使用します。一方、Kinesis Data Firehoseは、データのストレージ先に対するストリームの配信に特化しています。リアルタイム分析が求められる場合は、Kinesis Data Streamsが最適です。

AWS Lambda vs Kinesis Data Analytics:

Lambdaはサーバーレスで、データをストリームから処理するために柔軟にカスタマイズできます。Kinesis Data Analyticsは、SQLで簡単な分析を行うために特化しており、リアルタイムデータのストリーミング解析に最適ですが、複雑なカスタム処理が必要な場合はLambdaが有効です。

SNS vs SES:

SNSは通知サービスであり、複数の受信者に簡単に通知を送信できるため、アラートや通知配信に最適です。SES（Simple Email Service）は主に電子メールの送信に使いますが、SNSはより多様な通知方法を提供します。

実践

略

一問道場

質問 #404

ある企業が、工場全体で湿度や光などの環境パラメーターに関する情報を収集するためにセンサーを取り付けました。この企業は、AWSクラウドでリアルタイムでデータをストリーミングして分析する必要があります。もしパラメーターが許容範囲外に入った場合、工場の運営チームにすぐに通知が届くようにしなければなりません。

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

データをAmazon Kinesis Data Firehose配信ストリームにストリーミングします。AWS Step Functionsを使用して、Kinesis Data Firehose配信ストリーム内のデータを消費して分析します。Amazon Simple Notification Service（Amazon SNS）を使用して運営チームに通知を送ります。

データをAmazon Managed Streaming for Apache Kafka（Amazon MSK）クラスターにストリーミングします。Amazon MSKでトリガーを設定し、AWS Fargateタスクを呼び出してデータを分析します。Amazon Simple Email Service（Amazon SES）を使用して運営チームに通知を送ります。

データをAmazon Kinesisデータストリームにストリーミングします。AWS Lambda関数を作成してKinesisデータストリームを消費し、データを分析します。Amazon Simple Notification Service（Amazon SNS）を使用して運営チームに通知を送ります。

データをAmazon Kinesis Data Analyticsアプリケーションにストリーミングします。自動スケーリングされ、コンテナ化されたAmazon Elastic Container Service（Amazon ECS）サービスを使用してデータを消費して分析します。Amazon Simple Email Service（Amazon SES）を使用して運営チームに通知を送ります。

解説

この問題では、リアルタイムで環境パラメーターのデータを収集し、それをクラウドでストリーミングして分析し、許容範囲外のパラメーターに対して即座に通知を送るという要件を満たすソリューションを選択する必要があります。以下、各選択肢について解説します。

A. Amazon Kinesis Data Firehose + AWS Step Functions + Amazon SNS

Kinesis Data Firehose: Amazon Kinesis Data Firehoseは、リアルタイムでデータを取り込み、指定した保存先（S3、Redshiftなど）に配信するサービスです。通常はデータストリームの処理に特化したサービスではなく、ストリーミングデータの即時分析を行うには不向きです。

AWS Step Functions: AWS Step Functionsは、分散アプリケーションのワークフローを管理するサービスですが、データのストリーミングと分析に直接関連しないため、リアルタイムのデータ処理に適していません。

Amazon SNS: SNSは通知を送信するのに使用できますが、データ分析には他のサービスの方が適しています。

結論: このソリューションはリアルタイムデータの分析という要件に最適ではなく、運用効率に欠けます。

B. Amazon MSK + AWS Fargate + Amazon SES

Amazon MSK: Apache KafkaのマネージドサービスであるAmazon MSKは、リアルタイムのストリーミングデータを処理するために適していますが、設定や管理が複雑であり、リアルタイム分析を効率的に行うには他のAWSサービスが必要です。

AWS Fargate: AWS Fargateはコンテナをサーバーレスで実行するサービスですが、Kafkaのストリームを消費して即座に分析するためのフレームワークとしては最適ではありません。

Amazon SES: SESは通知を送信するために使えますが、データのリアルタイム分析自体には向いていません。

結論: 複雑すぎて、リアルタイムで簡単にデータを分析するソリューションには向きません。

C. Amazon Kinesis Data Stream + AWS Lambda + Amazon SNS

Amazon Kinesis Data Stream: Kinesis Data Streamsは、リアルタイムで大規模なデータをストリーミングし、処理するために設計されたサービスです。センサーから送られる環境データを効率的に取り込むことができます。

AWS Lambda: Lambdaは、Kinesisのデータストリームをリアルタイムで処理し、データ分析を行うことができます。コードを書くだけで、ストリーミングデータを分析して条件に合うものを処理できます。

Amazon SNS: SNSを使用することで、リアルタイムのデータ分析の結果に基づいて即座に通知を送信できます。

結論: このソリューションは、リアルタイムでデータをストリーミングし、分析して、条件に合った通知を送るという要件を満たすために最も適しています。非常に効率的で、拡張性もあります。

D. Amazon Kinesis Data Analytics + Amazon ECS + Amazon SES

Amazon Kinesis Data Analytics: これは、Kinesisのデータストリームをリアルタイムで分析するためのフルマネージドサービスであり、ストリーミングデータの分析に特化していますが、ECSとの組み合わせが必要なケースは少ないです。

Amazon ECS: ECSはコンテナオーケストレーションサービスで、ストリーミングデータの分析にはやや過剰なインフラストラクチャを提供します。コンテナ化されたサービスで分析を行うのは複雑であり、よりシンプルなアプローチが望まれます。

Amazon SES: SESを通知に使用することは可能ですが、データ分析のプロセスには他のサービスの方が適しています。

結論: このソリューションも可能ではありますが、他の選択肢に比べて過剰で複雑です。

最適解: C. Amazon Kinesis Data Stream + AWS Lambda + Amazon SNS

このソリューションが最も効率的で適切です。Kinesis Data Streamを利用することで、リアルタイムでデータをストリーミングし、Lambdaで即時処理を行い、SNSで通知を送るという流れがシンプルかつスケーラブルです。この構成は、指定された要件を満たすために最適な解決策です。

405-AWS SAP AWS 「理論・実践・一問道場」トポロジースプレッド制約

理論

1. Amazon EKS (Elastic Kubernetes Service)

Amazon EKS は、Amazon Web Services (AWS) が提供するフルマネージドな Kubernetes クラスターサービスです。Kubernetes はコンテナ化されたアプリケーションのデプロイと管理を自動化するオープンソースのプラットフォームです。EKSは、Kubernetesの運用負荷を軽減し、簡単にスケーラブルで高可用性のあるコンテナ管理を実現します。

EKS の基本的な機能:

管理されるコントロールプレーン: EKS では、Kubernetes コントロールプレーン（API サーバーなど）を管理する必要がありません。AWSがその管理を行い、高可用性を提供します。
オートスケーリング: Kubernetes クラスター内で、ポッドやノードを自動的にスケールできます。
セキュリティ: EKSは、IAM（Identity and Access Management）と統合され、認証とアクセス管理が行えます。

2. ステートレス vs ステートフル

ステートレスなポッド: ステートレスなポッドは、状態（データ）を保持せず、リクエストが終了するたびにその状態が失われます。これにより、ポッドを自由にスケールアウト（複製）やスケールイン（削除）できます。多くのWebアプリケーションやマイクロサービスはステートレスに設計され、負荷に応じて迅速にスケールできます。

ステートフルなポッド: ステートフルなポッドは、データを保持し、状態を管理します。これには永続的なストレージ（EBS、EFSなど）が必要になることが多く、スケーリングの際に注意が必要です。

3. ノードのレジリエンス（耐障害性）

ノードのレジリエンスとは、EKS クラスター内で稼働するインスタンス（EC2 ノード）の可用性と耐障害性を指します。ノードの障害時にアプリケーションが適切に動作し続けるためには、以下のような技術が重要です。

アベイラビリティゾーンの分散:

Kubernetes のポッドは、アベイラビリティゾーン（AZ）に分散配置することで、特定のAZに障害が発生しても、他のAZに配置されたポッドが動作を続けることができます。これにより、全体のシステムの可用性が向上します。
トポロジースプレッド制約を利用することで、ポッドが複数のAZに分散され、システムの耐障害性を最大化できます。

オートスケーリング:

Kubernetes クラスターオートスケーラーを設定することで、リソースの使用状況に基づいて自動的にノードを追加・削除し、クラスターのスケールに柔軟に対応できます。

4. Kubernetes オートスケーリング

Kubernetes には、ポッドとノードのスケーリングを管理するための機能があります。

Horizontal Pod Autoscaler (HPA):

ポッドの数を自動的に増減させるためのリソース管理機能です。ポッドのCPUやメモリの使用状況に応じて、適切な数のポッドを維持します。

Cluster Autoscaler:

クラスターのノード数を増減させる機能です。ノードが過剰または不足している場合に自動的に調整します。

5. ワークロードのスケーリング戦略

EKS を使用している場合、ワークロードが予測できない数のポッドをサポートするために、次のようなスケーリング戦略が重要です。

Pod Distribution (ポッド分散):

複数のアベイラビリティゾーン（AZ）にポッドを分散させることで、耐障害性を高めます。これにより、1つのAZがダウンした場合でも、他のAZのポッドがリクエストを処理し続けます。

リソース要求の設定:

各ポッドに対して適切なリソース要求（CPU、メモリ）を設定することが重要です。リソース要求が適切でないと、ポッドが十分にスケールしない可能性があります。

6. Kubernetes スプレッド制約

トポロジースプレッド制約は、Kubernetesでポッドを異なるリソースやゾーンに分散するための方法です。これにより、システムが障害に対してよりレジリエント（耐障害性）になり、可用性が向上します。具体的には、次のような制約が使用されます：

topologySpreadConstraints:

ポッドが特定のトポロジー（例えば、アベイラビリティゾーン）で適切に分散されるように制約を加えることができます。

まとめ

Amazon EKSを使ってステートレスなポッドを効率的にスケーリングするためには、アベイラビリティゾーンにポッドを分散させるトポロジースプレッド制約を活用し、クラスターオートスケーラーを使ってノードの数を自動で調整することが効果的です。これにより、ポッドとノードの耐障害性が最大化され、予測できないワークロードにも対応できるようになります。

実践

略

一問道場

質問 #405

ある企業が、ワークロード用にAmazon Elastic Kubernetes Service (Amazon EKS) クラスターをデプロイしようとしています。企業は、クラスターが予測できない数のステートレスなポッドをサポートすることを期待しており、多くのポッドは、ワークロードが自動的にレプリカ数をスケーリングする際に短期間で作成されます。

ノードのレジリエンスを最大化するための最適なソリューションはどれですか？

EKS コントロールプレーンをワークロードノードグループとは別の2つ目のクラスターにデプロイするために、別々の起動テンプレートを使用する。

ワークロードノードグループを更新し、ノードグループの数を減らしてインスタンスを大きくする。

Kubernetes クラスターオートスケーラーを設定して、ワークロードノードグループのコンピューティング容量が過剰に供給されないようにする。

ワークロードに、アベイラビリティゾーンに基づくトポロジースプレッド制約を使用するように設定する。

解説

この問題は、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターでのワークロードのスケーラビリティとノードのレジリエンスを最大化する方法について問われています。以下に、各選択肢の解説を初心者向けに説明します。

選択肢 A:

EKS コントロールプレーンをワークロードノードグループとは別の2つ目のクラスターにデプロイするために、別々の起動テンプレートを使用する。

解説: ここで言う「コントロールプレーン」とは、Kubernetes クラスターの管理部分のことです。この選択肢では、ワークロード用のノードグループと管理用のノードグループを別々のクラスターに分けようとしています。しかし、この方法は管理が複雑になり、必要なリソースを効率的にスケールするのに最適ではありません。通常、コントロールプレーンとワークロードのノードグループは同じクラスター内で運用します。

選択肢 B:

ワークロードノードグループを更新し、ノードグループの数を減らしてインスタンスを大きくする。

解説: この選択肢では、ノードの数を減らし、各ノードのサイズを大きくして、リソースを効率的に使用しようとしています。しかし、スケーラビリティ（需要に応じてポッドの数が増減する）の観点では、この方法は最適ではありません。特に、ポッドの数が変動するようなワークロードには、柔軟にスケールできる方が良いです。この方法では、ノードのスケーリングが難しくなる可能性があります。

選択肢 C:

Kubernetes クラスターオートスケーラーを設定して、ワークロードノードグループのコンピューティング容量が過剰に供給されないようにする。

解説: Kubernetes クラスターオートスケーラーは、ワークロードの需要に応じて自動的にノードを追加または削除する仕組みです。これにより、予測できない負荷やスケーリングに対応でき、リソースの効率的な利用が可能になります。しかし、この選択肢は、ノード自体のスケーリングのみに焦点を当てており、ポッドのスケーリングやノードのレジリエンスに対する最大化には十分ではありません。

選択肢 D:

ワークロードに、アベイラビリティゾーンに基づくトポロジースプレッド制約を使用するように設定する。

解説: トポロジースプレッド制約は、Kubernetes でポッドを複数のアベイラビリティゾーンに分散させる設定です。これにより、特定のゾーンで障害が発生しても他のゾーンでポッドが動作し続けるため、システム全体の可用性が向上します。ノードのレジリエンス（耐障害性）を最大化するために、この方法は非常に有効です。予測できないスケーリングに対応するだけでなく、システムの安定性も確保できます。

結論:

選択肢 Dが最適です。アベイラビリティゾーンに基づくトポロジースプレッド制約を使うことで、ポッドが複数のゾーンに分散され、クラスタの耐障害性が向上します。これにより、ワークロードのスケーリングとノードのレジリエンスが最大化されます。

406-AWS SAP AWS 「理論・実践・一問道場」DR

理論

ディザスタリカバリ（DR）と高可用性の設計

ディザスタリカバリ（DR）は、システム障害や災害時にアプリケーションやデータを迅速に復旧させるための計画です。特に、Web アプリケーションが複数のリージョンで高可用性を確保することが重要です。以下は、AWS 上での DR 設計における重要な概念です。

1. クロスリージョン冗長性

AWS では、リージョンごとに独立したインフラが提供されています。クロスリージョン冗長性は、複数のリージョンにデータとアプリケーションを配置することで、単一リージョンでの障害が全体に影響を与えないようにする戦略です。これにより、1つのリージョンが障害を起こしても、別のリージョンでバックアップとして機能し、迅速な復旧が可能です。

クロスリージョンリードレプリカ: RDS では、別リージョンにデータベースのリードレプリカを作成できます。リードレプリカはデータがリアルタイムで同期されるため、障害時に迅速にプライマリインスタンスに昇格させることができます。

2. AWS Lambda の自動化

AWS Lambda を使用して、復旧手順を自動化することができます。Lambda 関数をトリガーして、障害発生時に次のような操作を行うことが可能です:

新しい ECS クラスターの作成

RDS のスナップショットの取得と復元

Route 53 によるトラフィックのリダイレクト

自動化により、手動操作を減らし、復旧時間を最小限に抑えることができます。

3. AWS ECS と Fargate

ECS（Elastic Container Service）は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを行うサービスです。Fargate は、サーバーレスでコンテナを実行するための AWS のサービスで、インフラの管理を気にせずにアプリケーションを実行できます。ECS クラスターと Fargate を使うことで、簡単にコンテナのスケーリングや再起動が可能です。

ECS クラスターの複製: 障害発生時に迅速に新しいリージョンに ECS クラスターを立ち上げ、サービスを再起動できます。

4. Route 53 によるトラフィックのリダイレクト

Route 53 は、DNS のサービスを提供しており、トラフィックを別のリージョンや別のリソースにリダイレクトするために使用できます。障害発生時には、Route 53 を使って新しいリージョンにトラフィックを転送することができます。

ヘルスチェックと自動リダイレクト: Route 53 のヘルスチェックを設定して、プライマリリージョンがダウンした場合に自動でセカンダリリージョンにトラフィックをリダイレクトします。

5. RDS スナップショット

RDS のスナップショットを取得することにより、データベースの現在の状態を保存できます。これにより、障害時にスナップショットからデータを復元することが可能です。

スナップショットの複製: 別のリージョンにスナップショットをコピーし、新しいインスタンスをそのコピーから立ち上げることで、迅速にサービスを復旧できます。

結論

ディザスタリカバリ計画を設計する際は、クロスリージョン冗長性、自動化の活用（Lambda）、Route 53 のトラフィック管理、ECS/Fargate のスケーリング、RDS スナップショットとリードレプリカを組み合わせることで、迅速で効率的な復旧が可能となります。

実践

略

一問道場

問題 #406

ある企業は、Web アプリケーションのディザスタリカバリ (DR) 計画を実装する必要があります。このアプリケーションは単一の AWS リージョンで実行されています。アプリケーションはコンテナで実行されるマイクロサービスを使用しており、コンテナは AWS Fargate 上の Amazon Elastic Container Service (Amazon ECS) でホストされています。アプリケーションには Amazon RDS for MySQL DB インスタンスがデータ層として使用され、Amazon Route 53 が DNS 解決に使用されています。アプリケーションに障害が発生した場合、Amazon CloudWatch アラームが Amazon EventBridge ルールを呼び出します。

ソリューションアーキテクトは、別のリージョンでアプリケーションの復旧を提供する DR ソリューションを設計する必要があります。このソリューションは、障害から回復するために必要な時間を最小限に抑える必要があります。

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

A. 別のリージョンに 2 番目の ECS クラスターと ECS サービスを Fargate 上に設定します。AWS Lambda 関数を作成して、以下の操作を実行させます：RDS DB インスタンスのスナップショットを取得し、そのスナップショットを別のリージョンにコピーし、そのスナップショットから新しい RDS DB インスタンスを作成し、Route 53 を更新して 2 番目の ECS クラスターにトラフィックをルーティングします。EventBridge ルールを更新して、Lambda 関数をターゲットとして追加します。

B. AWS Lambda 関数を作成して、別のリージョンに 2 番目の ECS クラスターと ECS サービスを作成します。Lambda 関数を設定して、以下の操作を実行させます：RDS DB インスタンスのスナップショットを取得し、そのスナップショットを別のリージョンにコピーし、そのスナップショットから新しい RDS DB インスタンスを作成し、Route 53 を更新して 2 番目の ECS クラスターにトラフィックをルーティングします。EventBridge ルールを更新して、Lambda 関数をターゲットとして追加します。

C. 別のリージョンに 2 番目の ECS クラスターと ECS サービスを設定します。RDS DB インスタンスのクロスリージョンリードレプリカを別のリージョンに作成します。AWS Lambda 関数を作成して、リードレプリカをプライマリデータベースに昇格させます。Lambda 関数を設定して、Route 53 を更新して 2 番目の ECS クラスターにトラフィックをルーティングします。EventBridge ルールを更新して、Lambda 関数をターゲットとして追加します。

D. 別のリージョンに 2 番目の ECS クラスターと ECS サービスを設定します。RDS DB インスタンスのスナップショットを取得し、そのスナップショットを Amazon DynamoDB グローバルテーブルに変換します。AWS Lambda 関数を作成して、Route 53 を更新して 2 番目の ECS クラスターにトラフィックをルーティングします。EventBridge ルールを更新して、Lambda 関数をターゲットとして追加します。

解説

この問題では、AWS 上で運用されている Web アプリケーションのディザスタリカバリ (DR) ソリューションを設計するため、要件に適合する最適な解決策を選ぶ必要があります。具体的には、アプリケーションが単一のリージョンで実行されており、別のリージョンで迅速に復旧することが求められています。

選択肢の解説

A: ECS クラスターと RDS インスタンスのスナップショットを用いた方法

内容: 別のリージョンに 2 番目の ECS クラスターと ECS サービスを作成し、RDS DB インスタンスのスナップショットを取得し、そのスナップショットを別リージョンにコピーします。そして、新しい RDS インスタンスを作成し、Route 53 を更新してトラフィックを新しい ECS クラスターにルーティングします。

利点: 完全なシステムバックアップを提供し、インスタンスの再構築を行い、シンプルな構成で迅速に復旧できます。Lambda 関数を使用することでプロセスを自動化し、効率的に運用できます。

短所: RDS のスナップショットは整合性が取れた状態で提供されるため、少し時間がかかる可能性があります。また、スナップショットを利用して復旧するプロセスがやや手動的であるため、最短時間での復旧が求められる場合には、やや効果が薄い場合もあります。

B: Lambda で ECS クラスターとサービスを作成する方法

内容: AWS Lambda を使用して ECS クラスターとサービスを作成し、RDS のスナップショットを取得し、新しいリージョンにコピーして新しい RDS インスタンスを作成します。最終的に、Route 53 でトラフィックを新しい ECS クラスターにルーティングします。

利点: Lambda を活用して復旧処理を完全に自動化できます。しかし、実質的には A のオプションと同じ内容であり、Lambda 関数を使って処理を実行する点が異なります。

短所: 同じように RDS の復旧に時間がかかる可能性があり、最短時間での復旧を求める場合には、少し非効率的かもしれません。

C: クロスリージョンリードレプリカと Lambda を使った方法

内容: 別のリージョンに ECS クラスターを作成し、RDS のクロスリージョンリードレプリカを作成します。Lambda 関数を使ってリードレプリカをプライマリに昇格させ、Route 53 を更新して新しい ECS クラスターにトラフィックをルーティングします。

利点: クロスリージョンリードレプリカは、RDS インスタンスが故障した際に非常に速く切り替えが可能です。リードレプリカは常にデータを同期しているため、ダウンタイムを最小限に抑え、より迅速に復旧できます。

短所: この方法は比較的高価なオプションですが、非常に迅速な復旧を提供します。データの整合性やトラフィックのルーティングに関する設定が重要です。

D: DynamoDB と Lambda を使った方法

内容: RDS のスナップショットを取得し、それを Amazon DynamoDB グローバルテーブルに変換します。Lambda 関数を使って Route 53 を更新してトラフィックを新しい ECS クラスターにルーティングします。

利点: DynamoDB グローバルテーブルを使用する方法は、分散型データベースを活用して、高可用性とスケーラビリティを確保できます。しかし、RDS のデータベースから DynamoDB にデータを移行することは一般的ではなく、複雑で時間がかかる可能性があります。

短所: RDS と DynamoDB は異なるタイプのデータベースであり、RDS のデータを DynamoDB に変換する手順は複雑であり、この方法は他のオプションに比べて効率的ではありません。

最適な選択肢

C (クロスリージョンリードレプリカと Lambda を使った方法) が最も迅速な復旧を提供します。クロスリージョンリードレプリカを使用することで、データの同期が常に行われ、インスタンスの障害発生時に速やかに復旧できます。この方法は、迅速な復旧と最小限のダウンタイムを実現するため、最適です。

まとめ

A と B はスナップショットを利用するため時間がかかりますが、C はクロスリージョンリードレプリカを使用するため、迅速な復旧が可能です。

D は DynamoDB にデータを移行する方法ですが、最適な選択肢ではありません。

従って、最も効率的で最速な復旧を提供するCが最適な解決策です。

407-AWS SAP AWS 「理論・実践・一問道場」AWS Budgets

理論

1. AWS Budgets

AWS Budgetsは、使用量、コスト、リソースの使用状況に関して、予算を設定し、その予算に基づいてアラートを送信するためのサービスです。企業が予算超過を防ぐために非常に役立ちます。

設定方法:

予算の作成: コストまたは使用量に基づいて予算を作成。

閾値設定: 使用量やコストが指定した閾値を超えた場合にアラートを送信。

通知設定: メールやSNSを利用して、予算超過を管理者に通知。

利用例:

「EC2インスタンスの使用時間が過去30日間の平均使用時間を10%以上超えた場合に通知」
「コストが指定の予算を超過した場合にアラート」

AWS Budgetsは、特定のリソースの使用量やコストに基づいて、リアルタイムで予算を管理するために使われます。

2. AWS Cost Anomaly Detection

AWS Cost Anomaly Detectionは、コストの異常を検出するためのサービスです。従来の手動でのコスト管理から自動化された異常検出へと移行することができます。

機能:

使用量やコストにおける異常な変動を検出。

検出した異常に基づいて、アラートを発行。

利用例:

「AWSサービスの使用量が急激に増加した場合」
「コストが想定外に高くなった場合」

このサービスは、コストの急激な増加を警告するために非常に有効ですが、使用量の詳細な閾値管理には不向きです。

3. Amazon CloudWatch

Amazon CloudWatchは、AWSリソースとアプリケーションの監視を行うサービスで、メトリクスの監視、アラートの設定、ログの収集・分析を行うことができます。

使用方法:

メトリクスの収集: 各AWSリソース（EC2、RDSなど）の使用状況を監視。

アラートの設定: 定期的な閾値を設定し、閾値を超えた場合に通知。

利用例:

「EC2インスタンスのCPU使用率が80%を超えた場合にアラート」
「RDSインスタンスのストレージ使用率が90%を超えた場合に通知」

CloudWatchを利用することで、使用量やパフォーマンスメトリクスに基づく監視とアラートを行い、リアルタイムでの対応が可能になります。

4. AWS Trusted Advisor

AWS Trusted Advisorは、AWS環境におけるベストプラクティスを提供し、コスト削減、セキュリティ、パフォーマンスの最適化を支援します。主にコスト管理やリソース最適化に焦点を当てています。

利用例:

「未使用のEC2インスタンスやボリュームを削除」
「コスト削減の提案」

Trusted Advisorは、異常な使用状況やコストの管理には直接関わりませんが、全体的な最適化には役立ちます。

5. AWS Cost Explorer

AWS Cost Explorerは、AWSのコストを視覚的に分析し、使用状況をトラッキングするためのツールです。リソースごとの使用量やコストの推移を視覚化できるため、異常を早期に発見するのに役立ちます。

利用方法:

コストと使用量のトレンド分析。

過去のデータに基づく予測。

Cost Explorerは、詳細なコスト分析や過去の使用状況に基づく傾向の特定を行いたい場合に役立ちます。

結論

AWSでは、リソースの使用量やコストに関するアラートを設定するためにさまざまなツールがあります。今回の問題での解答は、AWS Budgetsを使用することで、指定した使用量に達した場合に通知を受けることができます。AWS Cost Anomaly DetectionやAmazon CloudWatchなどは、異常検出やパフォーマンス監視には強力ですが、直接的に「使用量の閾値に基づいたアラート」には特化していません。

実践

略

一問道場

会社はAWS Organizationsに所属する複数のAWSアカウントを運用しています。会社はAmazon EC2の使用状況を指標として追跡したいと考えています。また、アーキテクチャチームは、EC2の使用状況が過去30日間の平均使用状況よりも10%以上高い場合に、毎日アラートを受け取る必要があります。

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

A. AWS Organizationsの管理アカウントでAWS Budgetsを設定します。使用タイプとしてEC2実行時間を指定し、日次期間を設定します。予算額を、AWS Cost Explorerから取得した過去30日間の平均使用状況より10%多い額に設定します。使用量の閾値に達した場合に、アーキテクチャチームに通知するアラートを設定します。

B. AWS Organizationsの管理アカウントでAWS Cost Anomaly Detectionを設定します。モニタタイプをAWSサービスに設定し、フィルターをAmazon EC2に設定します。過去30日間の平均使用状況よりも10%高い場合に、アーキテクチャチームに通知するアラートサブスクリプションを設定します。

C. AWS Organizationsの管理アカウントでAWS Trusted Advisorを有効にし、コスト最適化アドバイザリーアラートを設定します。EC2の使用量が過去30日間の平均使用状況より10%多い場合に、アーキテクチャチームに通知します。

D. AWS Organizationsの管理アカウントでAmazon Detectiveを設定し、EC2の使用異常アラートを設定します。Detectiveが10%以上の使用異常を特定した場合に、アーキテクチャチームに通知します。

解説

この問題は、EC2の使用状況が過去30日間の平均と比べて10%以上増加した場合にアラートを受け取る方法について尋ねています。ここでの目標は、過去の使用状況をベースにした使用量の異常を特定し、指定された閾値を超えた場合に通知を受けることです。

各選択肢についての解説

A: AWS Budgetsを使用

AWS Budgetsは、指定した予算と使用量に基づいてアラートを設定できるサービスです。EC2実行時間（使用量）を追跡し、過去30日間の平均使用状況よりも10%高い使用量を設定して、予算を超えた場合に通知を受け取る仕組みです。

適切な選択肢です。この方法は、コストや使用量の予算を設定してアラートを送信するという要件を満たしています。

B: AWS Cost Anomaly Detectionを使用

AWS Cost Anomaly Detectionは、異常なコストや使用量の変動を検出するサービスです。Amazon EC2の使用量にフィルターを設定し、異常が検出されると通知を送る設定ができますが、このサービスはコストの異常に焦点を当てており、使用量の閾値を設定するものではありません。

不適切な選択肢です。ここでは、コストではなく、使用量（10%の増加）が基準となっています。

C: AWS Trusted Advisorを使用

AWS Trusted Advisorは、コスト最適化、セキュリティ、パフォーマンスなどに関するベストプラクティスを提案するツールです。コスト最適化のアドバイスを提供しますが、特定の使用量が10%増加した場合にアラートを送るような機能は提供していません。

不適切な選択肢です。この選択肢は、使用量の増加に関するアラートには対応していません。

D: Amazon Detectiveを使用

Amazon Detectiveは、セキュリティのインシデントの調査や異常検出を行うサービスです。EC2の使用異常を検出する機能はありますが、使用量の閾値を設定してアラートを出す機能ではありません。これはセキュリティインシデントや異常な振る舞いを検出するためのツールであり、使用量の監視に特化していません。

不適切な選択肢です。このサービスは、使用量の異常を追跡するには不向きです。

正解

A: AWS Budgetsを使用が最も適切な選択肢です。AWS Budgetsを利用することで、過去の使用状況をもとに使用量の閾値を設定し、10%増加した場合に通知を受けることができます。

408-AWS SAP AWS 「理論・実践・一問道場」疎結合

理論

1. 高可用性とスケーラビリティの重要性

高可用性: アプリケーションが稼働し続けるためには、障害が発生してもダウンタイムを最小限に抑える必要があります。これを実現するためには、冗長性のあるアーキテクチャや、障害発生時に自動で回復する仕組みを取り入れることが求められます。

スケーラビリティ: 特にeコマースなど、トラフィックの増減が予測できないシステムでは、アプリケーションが柔軟にスケールできることが重要です。必要に応じてコンピューティングリソースを動的に増減させることができるアーキテクチャが求められます。

2. 疎結合なアーキテクチャ

疎結合: コンポーネント間の依存性を最小限にし、障害が発生しても他の部分に影響を与えないようにする設計が重要です。AWSでは、Amazon SQS や AWS Lambda などのサーバーレスサービスを使用することで、疎結合の設計が簡単に実現できます。

3. AWSサービスの利用

Amazon SQS (Simple Queue Service): スケーラブルで高可用なメッセージキューサービス。メッセージをキューに格納し、後続の処理で取り出して処理するため、システム全体の疎結合性を高め、耐障害性を確保できます。

AWS Lambda: サーバーレスコンピューティングサービスで、リクエストに基づいて自動的にスケールします。メッセージがSQSに到着すると自動的にLambda関数が起動し、必要な処理を行います。Lambdaは使用した分だけ料金が発生するため、トラフィックの変動にも柔軟に対応でき、コスト効率が高いです。

4. シンプルなシステム設計

システム設計をシンプルに保つことは、運用負荷を軽減し、問題が発生した際に迅速に対応できることを意味します。AWS LambdaとSQSを使用することで、サーバーレスでシンプルかつスケーラブルなシステムを構築できます。

結論

eコマースなど、トラフィックに変動があるシステムにおいては、Amazon SQS と AWS Lambda の組み合わせが、高可用性、スケーラビリティ、疎結合 を実現する最適なアーキテクチャとなります。このアーキテクチャは、障害に強く、トラフィックの増減に柔軟に対応できます。

実践

略

一問道場

問題 #408

あるeコマース会社がITインフラを刷新し、AWSサービスを使用することを計画しています。同社のCIOは、ソリューションアーキテクトに、シンプルで高可用性かつ疎結合の注文処理アプリケーションの設計を依頼しました。このアプリケーションは、注文を受け取り処理した後、Amazon DynamoDBテーブルに格納する役割を担います。アプリケーションはまばらなトラフィックパターンを持ち、マーケティングキャンペーン中に注文を処理する際に遅延を最小限に抑えてスケールできる必要があります。

次のうち、要件を満たす最も信頼性の高いアプローチはどれですか？

A. Amazon EC2でホストされたデータベースに注文を受け取り、EC2インスタンスで処理する。

B. Amazon SQSキューで注文を受け取り、AWS Lambda関数を呼び出して処理する。

C. AWS Step Functionsプログラムを使用して注文を受け取り、Amazon ECSコンテナを起動して処理する。

D. Amazon Kinesis Data Streamsで注文を受け取り、Amazon EC2インスタンスで処理する。

解説

この問題では、シンプルで高可用性かつ疎結合な注文処理アプリケーションを設計するための最適なアプローチを選択する必要があります。重要な要素としては、以下の点が挙げられます：

高可用性: システムがダウンしないように、スケーラブルで耐障害性のあるアーキテクチャが求められます。

疎結合: コンポーネント間の依存関係が最小化されており、スケールしやすく、障害発生時にも影響を最小限に抑えられること。

スケーラビリティ: マーケティングキャンペーンなどの高トラフィックに対応できるように、トラフィック量に応じてスケールアップまたはスケールダウンできること。

これらの要素を考慮した上で、各選択肢を解説します。

選択肢の評価

A. Amazon EC2でホストされたデータベースに注文を受け取り、EC2インスタンスで処理する。

問題点: EC2インスタンスを使用する方法は、スケーラビリティに制限があり、アプリケーションが急激にスケールする場合や障害が発生した場合に柔軟性が欠けます。高可用性や疎結合の要件に最適ではありません。

B. Amazon SQSキューで注文を受け取り、AWS Lambda関数を呼び出して処理する。

最適な選択肢:

高可用性: Amazon SQSは分散型で、耐障害性が高く、メッセージが失われることはありません。
疎結合: SQSとLambdaを使用することで、注文受け取りと処理の間に明確な分離ができ、異常が発生しても他の部分への影響を最小限に抑えられます。
スケーラビリティ: Lambdaは自動的にスケールし、負荷が増えても適切に対応できます。
コスト効率: Lambdaはリクエスト数に応じて課金され、トラフィックが少ない時はコストを抑えられます。

C. AWS Step Functionsプログラムを使用して注文を受け取り、Amazon ECSコンテナを起動して処理する。

問題点: Step FunctionsとECSコンテナの組み合わせはスケーラブルで強力ですが、セットアップが複雑であり、またLambdaに比べて管理が必要となります。シンプルなアーキテクチャを求めている場合、オーバーヘッドが増える可能性があります。

D. Amazon Kinesis Data Streamsで注文を受け取り、Amazon EC2インスタンスで処理する。

問題点: Kinesisはリアルタイムデータストリーミングに強力ですが、EC2インスタンスを使用することで、スケーリングの柔軟性がやや欠け、管理の手間が増えます。また、注文処理のシンプルさを求めている場合には過剰なソリューションとなります。

結論

Bは最も信頼性が高く、シンプルでスケーラブルな解決策です。Amazon SQSとAWS Lambdaを使用することで、注文の受け取りと処理を効率的に分離し、高可用性と疎結合を実現できます。また、Lambdaは自動的にスケールし、負荷の増加に対応できるため、マーケティングキャンペーンなどのピークトラフィックにも適切に対応できます。

したがって、Bが最適な選択肢です。

409-AWS SAP AWS 「理論・実践・一問道場」AWS Secrets Manager

理論

1. AWS Lambdaとデータベースアクセスのセキュリティ

AWS Lambda関数がデータベース（例えば、Amazon RDS）にアクセスする場合、資格情報のセキュアな管理が重要です。資格情報（ユーザー名やパスワード）をアプリケーションコード内にハードコードすると、セキュリティリスクが高まります。

2. 資格情報の管理方法

AWSでの資格情報管理には、主に以下の2つの方法があります：

AWS Secrets Manager: 資格情報を安全に保存し、自動ローテーションが可能です。例えば、データベースのユーザー名やパスワードを定期的に更新する設定ができます。
AWS Systems Manager Parameter Store: 資格情報を安全に保存できますが、自動ローテーション機能は提供されていません。暗号化やアクセス制御は可能ですが、資格情報のローテーションは手動で管理する必要があります。

3. AWS Secrets Managerの利点

自動ローテーション: Secrets Managerは、指定した期間ごとに資格情報を自動で更新できます。これにより、セキュリティを高めるとともに、手動で資格情報を変更する手間を省けます。

簡単な統合: Lambda関数や他のAWSサービスと簡単に統合できます。Secrets ManagerのAPIを使って、Lambda関数内で資格情報を安全に取得できます。

環境ごとの管理: 異なる環境（QA、開発、本番）で異なる資格情報を管理することができ、環境ごとにアクセス制御を強化できます。

4. AWS KMSとS3での管理

AWS KMS: KMSは暗号化サービスで、データの暗号化や管理を行いますが、資格情報のローテーション機能は提供しません。資格情報の保護には適しているものの、自動ローテーション機能を提供するには他のサービス（例：Secrets Manager）と組み合わせる必要があります。

Amazon S3: 資格情報をS3に保存することも可能ですが、これも手動でのローテーションが必要であり、S3はストレージサービスであるため、資格情報管理には適していません。

5. ベストプラクティス

資格情報をハードコードしない: アプリケーションコード内に資格情報を直接記述することは避け、専用のセキュアなストレージサービス（Secrets Managerなど）を使用する。

自動ローテーションを活用する: 資格情報のローテーションを手動で行うと人的ミスが発生しやすいため、可能な限り自動化を図る。AWS Secrets Managerはこの自動ローテーション機能を提供します。

アクセス制御: IAM（Identity and Access Management）を使用して、Lambda関数がSecrets ManagerやS3バケットにアクセスする際の権限を最小限に設定する。

このように、AWSの資格情報管理を適切に行うことで、セキュリティを保ちながら、運用の手間を減らすことができます。

実践

略

一問道場

会社はAWS Lambda関数を展開し、それらの関数がAmazon RDS for PostgreSQLデータベースにアクセスします。会社は、Lambda関数をQA環境と本番環境の両方で起動する必要があります。アプリケーションコード内で資格情報を公開せず、パスワードを自動的にローテーションする必要があります。

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

A. 両方の環境のデータベース資格情報をAWS Systems Manager Parameter Storeに保存します。AWS Key Management Service (AWS KMS)キーを使用して資格情報を暗号化します。Lambda関数のアプリケーションコード内で、AWS SDK for Python（Boto3）を使用してParameter Storeパラメーターから資格情報を取得します。Lambda関数にParameter Storeパラメーターへのアクセスを提供する役割を追加します。

B. 両方の環境のデータベース資格情報をAWS Secrets Managerに保存し、QA環境と本番環境のための異なるキーエントリを作成します。ローテーションを有効にします。Lambda関数に対してSecrets Managerキーを参照する環境変数を提供します。

C. 両方の環境のデータベース資格情報をAWS Key Management Service（AWS KMS）に保存します。ローテーションを有効にします。Lambda関数に対してAWS KMSに保存されている資格情報を参照する環境変数を提供します。

D. QA環境と本番環境のために別々のS3バケットを作成します。S3バケットに対してAWS KMSキー（SSE-KMS）によるサーバーサイド暗号化を有効にします。Lambda関数に対応する環境の資格情報を取得できるように、オブジェクト命名パターンを使用します。各Lambda関数の実行役割にAmazon S3へのアクセスを提供します。

解説

この問題は、AWS Lambda関数がデータベース（Amazon RDS for PostgreSQL）にアクセスする際に、資格情報の管理とローテーションの要件を満たす方法に関するものです。重要な要件は、資格情報がアプリケーションコード内に公開されず、自動的にローテーションされることです。選択肢を見ていきましょう。

A. AWS Systems Manager Parameter Storeを使用

利点:

AWS Systems Manager Parameter Storeに資格情報を保存することで、セキュアに管理できます。
AWS KMSを使って暗号化することで、データ保護が強化されます。
Lambda関数内でAWS SDK（Boto3）を使用して資格情報を取得する方法は一般的な手法です。

制限:

自動的なパスワードローテーションを設定することはできません。資格情報のローテーションを自動化する機能はありません。
セキュリティ的に資格情報の管理が不十分な場合があります。

B. AWS Secrets Managerを使用

利点:

Secrets Managerは、資格情報のローテーションを自動的に管理できるサービスです。これにより、定期的に資格情報が変更される場合でも、アプリケーションコードを変更することなく、常に最新の資格情報を使用できます。
異なるキーエントリを使って、QA環境と本番環境の資格情報を管理することができます。
Secrets Managerの参照を環境変数としてLambda関数に渡すことで、資格情報を安全に管理し、コード内に露出しません。

制限:

他の方法と比較して、費用がかかります（Secrets Managerには管理コストが伴います）。

C. AWS Key Management Service (AWS KMS)を使用

利点:

AWS KMSは強力な暗号化機能を提供しますが、直接的な資格情報のローテーション機能はありません。
資格情報をKMSで暗号化し、Lambda関数に参照させる方法はセキュアですが、ローテーションの自動化は提供されません。

制限:

資格情報の管理とローテーションには追加の自動化が必要です。AWS KMS単体ではローテーション機能は提供していません。

D. S3バケットとKMSを使用

利点:

S3バケットで資格情報を管理する方法もありますが、これは一般的ではなく、主にストレージ用途に適しています。
S3バケットを使うことで資格情報を安全に格納できますが、資格情報のローテーションやアクセス管理に関しては手動での管理が必要です。

制限:

ローテーションの自動化が提供されていないため、手動で資格情報を更新しなければならず、運用が複雑になります。

最適な選択肢

B. AWS Secrets Managerを使用が最適な選択肢です。

理由:

自動ローテーション機能があり、資格情報を定期的に変更してもLambda関数は常に最新の資格情報を利用できます。
環境変数としてSecrets Managerの参照をLambda関数に渡すことで、アプリケーションコード内に資格情報が露出しないため、セキュリティ的にも優れています。
異なる環境（QAと本番）で異なる資格情報を管理しやすく、セキュアで自動化された方法です。

したがって、AWS Secrets Managerを使用することが、要件に最も適していると言えます。

410-AWS SAP AWS 「理論・実践・一問道場」AssociatePublicIpAddress

理論

AWS Organizations と AWS Control Tower による効率的なインフラ管理

1. AWS Organizationsの概要

AWS Organizations は、複数のAWSアカウントを一元的に管理するためのサービスです。組織単位（OU: Organizational Units）を使用して、アカウントを論理的にグループ化できます。これにより、企業はアカウントを部門別やプロジェクト別に整理し、それぞれに対して異なる管理ポリシーを適用できます。

アカウントの管理: AWS Organizationsを使用すると、複数のAWSアカウントを一括で作成、削除、管理することができます。

サービスコントロールポリシー（SCP）: これにより、特定のAWSサービスへのアクセス制限や制御を実施できます。例えば、特定のアカウントでAmazon EC2の起動を禁止することができます。

2. AWS Control Towerの役割

AWS Control Tower は、AWS Organizationsを基盤にした管理機能を提供するサービスです。主に以下の目的で使用されます。

ガバナンスの確立: Control Towerは「積極的なコントロール（Guardrails）」というセキュリティ・コンプライアンスポリシーを提供します。これにより、組織内のアカウントに一貫した管理ポリシーを適用できます。

自動化: Control Towerは新しいアカウントを迅速にセットアップするためのテンプレートとプロセスを提供し、管理者は新しいアカウントを一貫したベストプラクティスに従って簡単に作成できます。

セキュリティとコンプライアンスの強化: Control Towerは、AWS Config、CloudTrail、GuardDutyなどを統合して、組織全体でセキュリティとコンプライアンスを強化する機能を提供します。

3. Guardrailsと積極的なコントロール

Control Towerでは、**積極的なコントロール（Guardrails）を利用して、企業全体でベストプラクティスを強制することができます。これらのコントロールは、セキュリティやコスト管理、インフラの運用に関するものです。Guardrailsは「検出型」と「強制型」**の2種類に分かれます。

検出型Guardrails: 特定のリソースに関する設定が正しいかどうかを監視し、違反が発生した場合に通知を送ります。

強制型Guardrails: 規定の設定を強制し、違反が発生した場合にリソース作成を防ぎます。

例えば、インスタンスのパブリックIPアドレスの管理に関するポリシーは、強制型Guardrailsとして設定できます。この設定により、OU内のすべてのアカウントでインスタンスにパブリックIPアドレスが割り当てられるのを防ぎます。

4. 事前防止と事後対応の違い

事前防止型アプローチは、問題が発生する前に制限やポリシーを設定し、問題を未然に防ぐ方法です。たとえば、AWS Control Towerのガードレールを使用して、インスタンスにパブリックIPアドレスを割り当てないように制限する方法がこれに該当します。事前防止型のアプローチは、組織全体で一貫性を保ちながら、手間をかけずにセキュリティとコンプライアンスを維持できます。

一方、事後対応型アプローチは、問題が発生した後にそれを検出し、修正する方法です。例えば、AWS ConfigとLambdaを使用して、インスタンスにパブリックIPアドレスが割り当てられている場合に自動的に修正する方法がこれに該当します。事後対応型アプローチは、柔軟性がありますが、問題発生後の対応が必要になるため、予防策としてはやや不十分です。

5. パブリックIPアドレスの管理

Amazon EC2インスタンスがパブリックIPアドレスを取得しないようにするためには、いくつかの方法があります。

AWS Control Towerの積極的なコントロール: Control Towerのガードレールを利用して、インスタンスの設定を制御できます。特に、AssociatePublicIpAddressプロパティを設定し、インスタンスにパブリックIPアドレスが自動的に割り当てられないようにすることが可能です。

SCP（Service Control Policies）: SCPを使用して、アカウント全体にパブリックIPアドレスを設定できないようにすることもできますが、これはServiceの利用に対するアクセス制御の範疇であり、リソースの設定に直接関連する制御とは異なります。

AWS ConfigとLambda: AWS Configでインスタンス設定を監視し、インスタンスがパブリックIPアドレスを持っている場合にLambda関数で修正する方法もあります。この方法は後から修正するため、プロアクティブな解決策としては適していません。

まとめ

AWS OrganizationsとAWS Control Towerは、企業全体のAWSアカウント管理とガバナンスを効率的に行うための強力なツールです。特に、パブリックIPアドレスの設定を管理する際には、AWS Control Towerの積極的なコントロールを活用することで、セキュリティとコンプライアンスの維持が容易になります。事前防止型アプローチを採用することで、リソース設定の一貫性を保ちながら、運用の効率化を実現することができます。

このような知識を活用することで、AWS環境を効果的に管理し、セキュリティやコスト管理の面でも最適化を図ることができます。

実践

略

一問道場

質問 #410

ある会社は、AWS Organizations内でAWS Control Towerを使用してAWSアカウントを管理しています。会社には、アカウントを含むOU（組織単位）があります。この会社は、OU内のアカウントで新規または既存のAmazon EC2インスタンスがパブリックIPアドレスを取得できないようにする必要があります。

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

A. 各アカウントのインスタンスにAWS Systems Managerを使用するように設定します。Systems ManagerのAutomationランブックを使用して、インスタンスにパブリックIPアドレスが割り当てられるのを防ぎます。

B. AWS Control Towerの積極的なコントロールを実装して、OU内のアカウントでインスタンスにパブリックIPアドレスが設定されているかどうかを確認します。AssociatePublicIpAddressプロパティをFalseに設定し、この積極的なコントロールをOUに適用します。

C. パブリックIPアドレスを持つインスタンスの起動を防止するSCP（Service Control Policy）を作成します。さらに、SCPを設定して既存のインスタンスにパブリックIPアドレスを割り当てることを防ぎます。このSCPをOUに適用します。

D. インスタンスにパブリックIPアドレスが設定されているかどうかを検出するAWS Configカスタムルールを作成します。AWS Lambda関数を使用してパブリックIPアドレスをインスタンスから切り離す修復アクションを設定します。

解説

このシナリオでは、AWSアカウント内のAmazon EC2インスタンスがパブリックIPアドレスを取得できないようにする必要があります。それに対して、最適なソリューションを選択することが求められています。

各選択肢について解説します。

A. 各アカウントのインスタンスにAWS Systems Managerを使用するように設定します。Systems ManagerのAutomationランブックを使用して、インスタンスにパブリックIPアドレスが割り当てられるのを防ぎます。

不適切な選択肢: Systems ManagerのAutomationランブックを使用して、インスタンスにパブリックIPアドレスを割り当てないようにする方法は、管理が手動で複雑になる可能性が高く、AWS OrganizationsやControl Towerを活用して一貫したポリシーを適用する方が効率的です。この方法は、実装と運用がやや煩雑でスケールしにくいため、適切ではありません。

B. AWS Control Towerの積極的なコントロールを実装して、OU内のアカウントでインスタンスにパブリックIPアドレスが設定されているかどうかを確認します。AssociatePublicIpAddressプロパティをFalseに設定し、この積極的なコントロールをOUに適用します。

適切な選択肢: AWS Control Towerの積極的なコントロール（Guardrails）を使用して、OU内のアカウントに一貫して制約を適用する方法です。この方法では、AssociatePublicIpAddressプロパティをFalseに設定することで、インスタンスにパブリックIPアドレスが割り当てられないように制御できます。このアプローチは、AWS Organizations内のすべてのアカウントに対して一貫したポリシーを適用でき、管理が簡単です。

C. パブリックIPアドレスを持つインスタンスの起動を防止するSCP（Service Control Policy）を作成します。さらに、SCPを設定して既存のインスタンスにパブリックIPアドレスを割り当てることを防ぎます。このSCPをOUに適用します。

不適切な選択肢: SCP（Service Control Policy）は、アカウントやユーザーに対して許可または拒否する操作を制御するポリシーですが、パブリックIPアドレスの割り当てに対する直接的な制御は提供しません。SCPはAWSサービスの利用制限には役立ちますが、特定のリソースに対してパブリックIPアドレスを設定させないことを直接的に制御する機能はありません。そのため、この方法は不適切です。

D. インスタンスにパブリックIPアドレスが設定されているかどうかを検出するAWS Configカスタムルールを作成します。AWS Lambda関数を使用してパブリックIPアドレスをインスタンスから切り離す修復アクションを設定します。

不適切な選択肢: AWS ConfigとLambdaを使用してインスタンスの修復アクションを設定する方法は、問題を発見して修正するための手段にはなりますが、事前にインスタンスにパブリックIPアドレスが設定されないようにするための予防的な手段としては最適ではありません。修復アクションは後からの対応となるため、予防策としては不十分です。

結論

最も適切な解決策は B です。AWS Control Towerの積極的なコントロールを使用して、OU内のアカウントにパブリックIPアドレスを設定させないようにすることが、最も効率的で管理が容易な方法です。