type
status
date
slug
summary
tags
category
icon
password
书籍
061-AWS Transfer for SFTP
理論
AWS Transfer for SFTPは、Amazon Web Services (AWS) が提供するフルマネージド型のSFTPサービスです。これにより、ユーザーは自社でSFTPサーバーを立ち上げたり管理したりすることなく、AWSクラウド上で安全にファイル転送を行うことができます。
主な特徴:
- スケーラビリティ: トラフィックの増加に自動的に対応し、スケーラブルなファイル転送を提供します。
- セキュリティ: 転送されるデータは暗号化され、VPC内でデータを安全に管理できます。
- 簡単な管理: サーバーのセットアップやメンテナンスが不要で、管理が容易です。
- AWS S3との統合: ファイルは直接Amazon S3に保存され、他のAWSサービスと簡単に連携できます。
- カスタマイズ可能なドメイン名: DNSを使って、カスタムドメインを設定できます。
AWS Transfer for SFTPを使用することで、従来のオンプレミスSFTPサーバーのような管理の手間を省き、信頼性と可用性の高いファイル転送を簡単に実現できます。
一問道場
質問 #61
ある金融会社がAmazon S3にデータレイクをホストしています。この会社は、毎晩複数の第三者からSFTP経由で財務データのレコードを受け取っています。会社は、VPCのパブリックサブネットにあるAmazon EC2インスタンス上で自前のSFTPサーバーを運用しています。ファイルがアップロードされた後、それらは同じインスタンスで実行されるcronジョブによってデータレイクに移動されます。SFTPサーバーは、Amazon Route 53を使用してDNS名
sftp.example.com でアクセス可能です。SFTPソリューションの信頼性とスケーラビリティを改善するために、ソリューションアーキテクトは何をすべきですか？
- A.
EC2インスタンスをAuto Scalingグループに移動し、EC2インスタンスをApplication Load Balancer (ALB) の背後に配置します。Route 53でDNSレコード
sftp.example.com をALBのエンドポイントにポイントするように更新します。- B.
SFTPサーバーをAWS Transfer for SFTPに移行し、Route 53でDNSレコード
sftp.example.com をサーバーのエンドポイントホスト名にポイントするように更新します。- C.
SFTPサーバーをAWS Storage Gatewayのファイルゲートウェイに移行し、Route 53でDNSレコード
sftp.example.com をファイルゲートウェイのエンドポイントにポイントするように更新します。- D.
EC2インスタンスをNetwork Load Balancer (NLB) の背後に配置し、Route 53でDNSレコード
sftp.example.com をNLBのエンドポイントにポイントするように更新します。解説
この問題では、SFTPサーバーの信頼性とスケーラビリティを向上させる方法を尋ねています。
- A は、EC2インスタンスをAuto Scalingグループに追加し、ALBの背後に配置する提案ですが、SFTPのような状態を保持するプロトコルには不適切です。
- B は、AWS Transfer for SFTPを利用することで、スケーラブルで高可用性のSFTPサービスを提供でき、管理負担も軽減されます。
- C は、AWS Storage Gatewayを使ってファイルゲートウェイを提供する提案ですが、SFTPサーバーの機能としては過剰です。
- D は、NLBを使用する提案ですが、SFTPプロトコルにはALBの方が適しており、NLBは一般的にTCP接続のために使用されます。
最適解はBです。AWS Transfer for SFTPは、スケーラブルで信頼性の高いマネージドサービスで、SFTPサーバーとしての機能を提供し、管理も簡単になります。
062-VMをEC2に移行
理論
AWS DataSync
AWS DataSync は、データを迅速にオンプレミスから AWS のストレージサービス（例：Amazon S3、Amazon EFS、Amazon FSx）に転送するためのサービスで、エージェント を使用してデータ転送を行います。
AWS DataSync エージェントの役割
- オンプレミスにインストールされるエージェント
- AWS DataSync エージェント は、オンプレミスのサーバやストレージデバイスにインストールされます。このエージェントは、データ転送の実行を担う「データ転送ツール」です。
- データ転送の管理と最適化
- エージェントは、オンプレミスのストレージシステムと AWS のストレージ（Amazon FSx for Windows File Server など）間でデータを転送します。転送中、データは圧縮され、転送後に自動で暗号化されるため、効率よく安全にデータが移動します。
- 簡単に設定できる
- エージェントの設定は簡単で、インストール後に AWS Management Console または AWS CLI を使って転送ジョブを設定し、データの同期や移行が行えます。
Amazon FSx for Windows File Serverとの関係
- Amazon FSx for Windows File Server は、Windows 環境でファイル共有を行うためのフルマネージドなサービスです。
- AWS DataSync を使用することで、オンプレミスのストレージから Amazon FSx へのデータ移行が可能になります。
まとめ
- AWS DataSync はエージェントを使用して、オンプレミスのデータを迅速かつ効率的に AWS のストレージサービスに移行するサービスです。
- このエージェントは、AWS とオンプレミス環境間でのデータ転送を安全に行い、データ移行を自動化します。
VM Import/Export と OVF について
VM Import/Export
VM Import/Export は、オンプレミスの仮想マシン（VM）を Amazon EC2 インスタンスとしてインポートするためのサービスです。これにより、仮想マシンをAWSクラウドに移行し、AWS上で動作させることができます。また、EC2インスタンスをオンプレミスにエクスポートすることも可能です。
- VM Import を使うと、VMware、Microsoft Hyper-V などの仮想化プラットフォームからVMをEC2にインポートできます。
- VM Export によって、AWS上のEC2インスタンスを他の環境にエクスポートすることもできます。
OVF (Open Virtualization Format)
OVF は、仮想マシンの構成やイメージをパッケージ化するための標準フォーマットです。OVFファイルは、仮想マシンの構成、メタデータ、ディスクのイメージを含むことができ、仮想マシンの移行や複製を簡素化します。
- OVFファイル は、異なる仮想化環境間での仮想マシンの互換性を保ちながら移行を行うために使われます。
- VMwareやVirtualBoxなどの仮想化プラットフォームで一般的に使用されます。
まとめ
- VM Import/Export は仮想マシンをAWSにインポートするためのサービスで、OVF形式の仮想マシンイメージを利用することができます。
- OVF は仮想マシンの構成とディスクイメージを標準化された形式でパッケージ化するためのフォーマットです。
一問道場
質問 #62
ある企業が、オンプレミスのデータセンターで動作しているVMwareインフラからAmazon EC2にアプリケーションを移行したいと考えています。ソリューションアーキテクトは、移行中にソフトウェアと設定を保持する必要があります。
この要件を満たすためにソリューションアーキテクトは何をすべきですか？
A.
- AWS DataSyncエージェントを設定して、データストアを Amazon FSx for Windows File Server に複製
- SMB共有を使用してVMwareデータストアをホスト
- VM Import/Export を使用して、VMをAmazon EC2に移動
B.
- VMware vSphereクライアントを使用して、アプリケーションを Open Virtualization Format (OVF) 形式のイメージとしてエクスポート
- 対象のAWSリージョンにイメージを保存するために Amazon S3バケット を作成
- IAMロール を作成してVM Importを適用
- AWS CLI を使用してEC2インポートコマンドを実行
C.
- AWS Storage Gatewayのファイルサービスを設定して、 CIFS共有 をエクスポート
- 共有フォルダにバックアップコピーを作成
- AWS Management Consoleにサインインして、バックアップコピーから AMI を作成
- AMIに基づいてEC2インスタンスを起動
D.
- AWS Systems Managerでハイブリッド環境用の管理インスタンスのアクティベーションを作成
- オンプレミスのVMにSystems Managerエージェントをダウンロードしてインストール
- VMをSystems Managerに登録して管理対象インスタンスにする
- AWS Backup を使用してVMのスナップショットを作成
- AMIを作成し、AMIに基づいてEC2インスタンスを起動
解説
A.
- AWS DataSyncエージェントを使用して、オンプレミスのデータをAmazon FSx for Windows File Serverに複製します。これにより、ファイルシステム全体をAWSに移行できます。
- その後、VM Import/Exportを使用して、VMをEC2インスタンスに移行します。VM Import/Exportは、仮想マシンのイメージをAmazon EC2にインポートするためのツールです。
解説:
この方法では、まずファイルシステムの移行を行い、その後、仮想マシンをEC2に移行する流れです。VMwareの設定やソフトウェア設定を保持するためには、VM Import/Exportが適切ですが、VMwareのデータストアの移行に特化した方法ではありません。従って、この選択肢は完全に要件に適合するとは言えません。
B.
- VMware vSphereクライアントを使用して、アプリケーションを**Open Virtualization Format (OVF)**形式でエクスポートします。この形式は仮想マシンの移行に適しており、異なる仮想化プラットフォーム間での互換性があります。
- エクスポートしたOVFファイルをAmazon S3バケットにアップロードします。これにより、クラウド環境に簡単に移行できます。
- IAMロールを使用して、VM Importを適用し、AWS CLIを使ってEC2インポートコマンドを実行して仮想マシンをEC2にインポートします。
解説:
この選択肢は、VMware環境からEC2にアプリケーションを移行するために非常に適切です。OVF形式はVMware仮想マシンをエクスポートする標準的な方法であり、インポート後もソフトウェアや設定が保持されるため、要件を満たします。
C.
- AWS Storage Gatewayのファイルサービスを使用して、CIFS共有をエクスポートします。CIFSはファイルシステムの共有のためのプロトコルです。
- その後、バックアップコピーを作成し、AWS Management ConsoleでそのバックアップからAMIを作成します。
- 最後に、作成したAMIを基にEC2インスタンスを起動します。
解説:
AWS Storage GatewayはオンプレミスのストレージとAWSを接続するためのサービスですが、このアプローチはVMwareの仮想マシンの移行には向いていません。特に仮想マシンのソフトウェアや設定を保持する方法としては適切でなく、ファイルベースの移行となるため、要件には合致しません。
D.
- AWS Systems Managerで管理インスタンスのアクティベーションを作成し、オンプレミスのVMにSystems Managerエージェントをインストールします。これにより、インスタンスの管理が可能になります。
- AWS Backupを使用してVMのスナップショットを作成し、その後、AMIを作成してEC2インスタンスを起動します。
解説:
AWS Systems Managerを使用してVMを管理対象インスタンスとして登録し、バックアップを作成する方法ですが、仮想マシンの設定やソフトウェア設定を完全に移行するための方法としては不十分です。この選択肢は主にインスタンスの管理やバックアップに関連しており、移行に特化した方法ではありません。
結論
Bが最も適切な選択肢です。VMware環境からEC2にアプリケーションを移行するためには、OVF形式でのエクスポートとVM Import/Exportを使用する方法が、ソフトウェアと設定を保持したまま移行する最も効果的な方法です。
063-AWS Lambdaのタイムアウト制限
理論
Provisioned Concurrency
プロビジョンドコンカレンシー (Provisioned Concurrency) は、AWS Lambdaの機能の1つで、Lambda関数が処理するリクエストの待機時間を短縮し、スケーラビリティを向上させるための設定です。
具体的には、プロビジョンドコンカレンシーを使用すると、Lambda関数が呼び出される前に、指定した数のインスタンス（コンカレンシー）を予め起動しておくことができます。これにより、関数の初回実行（コールドスタート）を避けることができ、リクエストが来た時にすぐに処理を開始できるようになります。
どういう時に役立つか
- 高い可用性が求められる場合や、即時に応答が必要なシステムに有効です。
- 特に、Lambda関数の初回起動時に発生するコールドスタート（処理開始までにかかる遅延）を減らしたい場合に使用します。
使い方
- プロビジョンドコンカレンシーの設定では、Lambda関数の指定された数のインスタンスを常に実行しておくように設定します。
- これにより、関数がトラフィックの増加に素早く対応できるようになり、急なスパイクにも迅速に対応できるようになります。
メリット
- 低遅延: コールドスタートの遅延を削減できる。
- 安定したパフォーマンス: リクエストに対してすぐに処理を開始できる。
- スケーラビリティ: 予測可能なトラフィックパターンに基づいてスケールできる。
デメリット
- コスト: プロビジョンドコンカレンシーを使用することで、予めインスタンスを確保するため、通常のLambda実行時よりも追加費用がかかる可能性があります。
AWS Lambdaのタイムアウト制限、。
- AWS Lambdaのタイムアウト制限: Lambdaは最大15分までしか実行できず、大きなファイルや長時間処理が必要な場合、タイムアウトエラーが発生します。
- 代替アーキテクチャ:
- AWS Fargate + ECS: 長時間かかる処理をサーバーレスで実行できるコンテナサービス。インフラ管理が不要で、大規模な処理を効率的に行えます。
- Amazon S3との統合: 新しいファイルがS3にアップロードされた際にECSタスクをトリガーして処理を実行できます。
これにより、Lambdaのタイムアウトを回避し、大規模な画像処理を安定的に実行できます。
一問道場
あるビデオ処理会社が、Amazon S3バケットから画像をダウンロードし、画像を処理して、変換された画像を別のS3バケットに保存し、画像に関するメタデータをAmazon DynamoDBテーブルに更新するアプリケーションを持っています。このアプリケーションはNode.jsで書かれており、AWS Lambda関数を使用して実行されます。Lambda関数は、新しい画像がAmazon S3にアップロードされると起動されます。
アプリケーションはしばらく問題なく動作していましたが、画像のサイズが大きくなり、Lambda関数がタイムアウトエラーで頻繁に失敗するようになりました。関数のタイムアウトは最大値に設定されています。ソリューションアーキテクトは、呼び出し失敗を防ぐためにアプリケーションのアーキテクチャをリファクタリングする必要があります。会社は基盤となるインフラを管理したくありません。
この要件を満たすために、ソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（2つ選んでください）
選択肢：
A. アプリケーションのデプロイメントを変更して、アプリケーションコードを含むDockerイメージを作成し、そのイメージをAmazon Elastic Container Registry (Amazon ECR)に公開する。
B. 新しいAmazon Elastic Container Service (Amazon ECS)タスク定義を作成し、互換性タイプをAWS Fargateに設定する。タスク定義が新しいイメージをAmazon Elastic Container Registry (Amazon ECR)から使用するように設定し、新しいファイルがAmazon S3に到着したときにLambda関数がECSタスクを呼び出すように調整する。
C. AWS Step Functionsのステートマシンを作成し、Parallelステートを使ってLambda関数を呼び出す。Lambda関数のプロビジョンドコンカレンシーを増加させる。
D. 新しいAmazon Elastic Container Service (Amazon ECS)タスク定義を作成し、互換性タイプをAmazon EC2に設定する。タスク定義が新しいイメージをAmazon Elastic Container Registry (Amazon ECR)から使用するように設定し、新しいファイルがAmazon S3に到着したときにLambda関数がECSタスクを呼び出すように調整する。
E. アプリケーションを変更して、画像をAmazon Elastic File System (Amazon EFS)に保存し、メタデータをAmazon RDS DBインスタンスに保存する。Lambda関数を調整してEFSファイル共有をマウントする。
解説
問題の要点：
- Lambda関数がタイムアウトエラーで失敗する。
- 画像の処理が大きくなり、Lambda関数のタイムアウト制限を超える。
- アプリケーションはインフラ管理を最小限にしたい。
正しい解答は A と B です。
A. アプリケーションのデプロイメントを変更して、アプリケーションコードを含むDockerイメージを作成し、そのイメージをAmazon Elastic Container Registry (Amazon ECR)に公開する。
- 画像処理が重くなり、Lambdaがタイムアウトしているので、Dockerイメージ を作成して Amazon ECR に公開し、アプリケーションコードをコンテナ化することで、インフラの管理を最小限にしつつ、処理を分散できます。これにより、Lambda関数のタイムアウトを回避するための対応が可能になります。
B. 新しいAmazon Elastic Container Service (Amazon ECS)タスク定義を作成し、互換性タイプをAWS Fargateに設定する。タスク定義が新しいイメージをAmazon Elastic Container Registry (Amazon ECR)から使用するように設定し、新しいファイルがAmazon S3に到着したときにLambda関数がECSタスクを呼び出すように調整する。
- AWS Fargate は、サーバーレスでコンテナを実行できるサービスです。これにより、画像処理を ECSタスク にオフロードすることができ、Lambdaのタイムアウト制限を回避できます。Fargateを使用すると、インフラ管理なしでスケーラブルなコンテナ環境を提供できます。
まとめ：
- A と B の組み合わせが最適です。Dockerイメージを作成し、ECSで処理をオフロードすることで、Lambda関数のタイムアウト問題を解決し、インフラ管理を最小限に抑えることができます。
064-AWS Control Tower
理論
AWS Control Tower
AWS Control Tower は、複数のAWSアカウントを管理し、ガバナンスを強化するためのサービスです。自動でセキュリティやコンプライアンスを守るポリシー（ガードレール）を適用し、複数アカウントの管理やリソースの標準化を支援します。これにより、安全で効率的なAWS環境の構築と運用が可能になります。
わかりやすい具体例を使って AWS Control Tower を説明します。
例えば、大きな会社で多くのチームがそれぞれ別のAWSアカウントを使って開発、テスト、運用をしているとします。各チームのニーズは異なりますが、全チームが会社のセキュリティやコンプライアンスのルールに従う必要があります。
AWS Control Tower は、以下のことを簡単に行えるようにします：
- アカウントの自動作成：あなたが組織の構造を定義すると、AWS Control Towerは自動的に複数のAWSアカウントを作成し、各アカウントに適切な権限や設定を施します。例えば、開発チーム、テストチーム、運用チームのアカウントを個別に作成できます。
- 統一的なセキュリティとコンプライアンス管理：AWS Control Towerは、事前に設定されたセキュリティポリシー（「ガードレール」）を自動的に適用します。例えば、すべてのデータベースが暗号化されていることを確認したり、特定の地域へのアクセスを制限することができます。これにより、各チームは自分たちで設定する必要がなく、全体の管理が簡単になります。
- 一元管理と監視：AWS Control Towerを使うと、すべてのAWSアカウントのセキュリティ状態やコンプライアンス状況を一目で確認できます。もしどこかのアカウントがポリシーに違反していた場合、警告を受け取ることができます。
例として、会社のルールで「すべての運用環境のデータベースは暗号化すること」が決まっていたとします。もし、あるチームが運用環境に暗号化されていないデータベースを作成した場合、AWS Control Towerはそれを検出し、警告を出してくれます。
AWS Control Tower を使うことで、複数のAWSアカウントを効率的に管理し、全てのアカウントが会社のセキュリティやコンプライアンスルールに従っていることを簡単に確認できます。
ガードレール
ガードレール（Guardrails） は、AWS Control Tower における「事前定義されたセキュリティとコンプライアンスのポリシー」です。これらは、AWS 環境内でのリソースの使用や設定が特定のルールに従うように強制するものです。ガードレールを適用することで、セキュリティリスクを低減し、企業のポリシーを一貫して守ることができます。
ガードレールの例:
- 暗号化の強制：すべてのデータベースやストレージに暗号化を有効にする。
- リソースの地域制限：特定の地域（リージョン）でのみリソースを作成することを許可し、それ以外の地域ではリソース作成を禁止する。
- IAM（Identity and Access Management）ポリシーの管理：ユーザーやロールに対して必要なアクセス権のみを付与し、不要な権限を制限する。
ガードレールの種類：
- 推奨ガードレール：セキュリティとコンプライアンスを強化するための推奨される設定ですが、必ずしも強制ではありません。
- 必須ガードレール：組織に適用される強制的なポリシーで、必ず守らなければならない設定です。
ガードレールは、AWS Control Towerを使ってアカウントが設定される際に自動的に適用され、手動で設定する手間を省きます。これにより、AWS環境の一貫性とセキュリティが保たれます。
一問道場
質問 #64
ある会社がAWS Organizationsで組織を管理しており、AWS Control Towerを使用してランディングゾーンをデプロイしています。
会社はガバナンスとポリシーの実施を行いたいと考えており、プロダクションOU内の暗号化されていないAmazon RDS DBインスタンスを検出するポリシーを実施する必要があります。
この要件を満たすために最適なソリューションはどれでしょうか？
A. AWS Control Towerで必須のガードレールを有効にし、それをプロダクションOUに適用する。
B. AWS Control Towerの強く推奨されているガードレールの中から適切なものを有効にし、それをプロダクションOUに適用する。
C. AWS Configを使用して新しい必須ガードレールを作成し、そのルールをプロダクションOU内のすべてのアカウントに適用する。
D. AWS Control TowerでカスタムSCPを作成し、それをプロダクションOUに適用する。
065-NAT SSM
理論
1. SSHアクセスの課題
- リスク: 直接SSHアクセスはポート22を開放する必要があり、攻撃リスクが高まる。
- 解決策: セキュリティグループでIP制限を行うか、代替アクセス方法を採用する。
2. アクセス手段の選択肢
- EC2 Instance Connect:
- WebブラウザやCLIから一時的なSSH接続が可能。
- SSHキー管理不要。
- ただし、特定のOS（Amazon Linux 2など）に依存。
- Systems Manager Session Manager:
- ポート22を閉じてもセッション管理が可能。
- IAMベースのアクセス制御でセキュリティを向上。
- コマンド履歴の監査をCloudWatch Logsに保存可能。
3. 推奨ソリューションの概要
- セキュリティと監査を両立する方法:
- SSHアクセスを廃止し、Session Managerを採用。
- CloudWatch LogsやAWS Configを使用して操作ログやリソース変更を監視。
一問道場
質問 #65
あるスタートアップ企業は、最新のAmazon Linux 2 AMIを使用してプライベートサブネット内でAmazon EC2インスタンス群をホストしています。同社のエンジニアはトラブルシューティングのためにSSHアクセスに大きく依存しています。
現在のアーキテクチャには以下が含まれています：
- プライベートおよびパブリックサブネットを持つVPCとNATゲートウェイ
- オンプレミス環境との接続のためのサイト間VPN
- オンプレミス環境からの直接SSHアクセスを許可するEC2セキュリティグループ
同社は、SSHアクセスに対するセキュリティコントロールを強化し、エンジニアが実行したコマンドを監査する機能を提供する必要があります。
ソリューションアーキテクトが取るべき戦略はどれですか？
A. EC2インスタンス群にEC2 Instance Connectをインストールして設定する。インスタンスに接続されたすべてのセキュリティグループからポート22のTCPインバウンドルールを削除する。エンジニアにはEC2 Instance Connect CLIを使用してインスタンスにリモートアクセスするように指示する。
B. EC2セキュリティグループを更新し、ポート22のTCPインバウンドをエンジニアのデバイスのIPアドレスのみに許可する。すべてのEC2インスタンスにAmazon CloudWatchエージェントをインストールし、オペレーティングシステムの監査ログをCloudWatch Logsに送信する。
C. EC2セキュリティグループを更新し、ポート22のTCPインバウンドをエンジニアのデバイスのIPアドレスのみに許可する。AWS Configを有効にして、EC2セキュリティグループのリソース変更を監視する。AWS Firewall Managerを有効にし、セキュリティグループポリシーを適用してルールの変更を自動で修復する。
D. AmazonSSMManagedInstanceCoreマネージドポリシーをアタッチしたIAMロールを作成し、すべてのEC2インスタンスにアタッチする。インスタンスに接続されたすべてのセキュリティグループからポート22のTCPインバウンドルールを削除する。エンジニアにはAWS Systems Manager Session Managerプラグインをデバイスにインストールしてもらい、Systems Managerのstart-session APIコールを使用してリモートでインスタンスにアクセスするように指示する。
解説
この質問では、プライベートサブネット内のEC2インスタンスへのSSHアクセスのセキュリティを強化し、監査機能を提供する最適な方法を問われています。それぞれの選択肢を検討します。
要件のポイント
- SSHアクセスのセキュリティ強化: 不必要なアクセスを防ぎ、アクセス管理を強化する。
- 監査機能の提供: エンジニアが実行したコマンドやアクティビティを記録する。
- オンプレミスからの接続: 現在のVPN経由でのアクセスを考慮する。
選択肢の分析
A.
- 構成:
- EC2 Instance Connectを使用してSSHアクセスを管理。
- セキュリティグループからポート22のインバウンドルールを削除。
- 評価:
- 利点: ポート22のインバウンドルールを削除することで、直接的なSSH攻撃のリスクが軽減される。
- 問題点: EC2 Instance ConnectはAmazon Linux 2やUbuntuのみをサポートし、全てのOSに適用できるわけではない。また、コマンドの監査ログを記録する機能が含まれていない。
- 結論: 不適切（監査要件を満たさない）。
B.
- 構成:
- ポート22のインバウンドをエンジニアのデバイスIPアドレスに限定。
- Amazon CloudWatchエージェントで監査ログをCloudWatch Logsに送信。
- 評価:
- 利点: エンジニアごとのアクセス制限が可能。監査ログを収集できる。
- 問題点: ポート22を開けたままにするため、VPNやIP制限があってもSSH攻撃のリスクが残る。また、より安全なアクセス手段であるSession Managerと比較すると劣る。
- 結論: 部分的に適切（SSHリスクが残るため最適ではない）。
C.
- 構成:
- ポート22のインバウンドをエンジニアのデバイスIPアドレスに限定。
- AWS Configでセキュリティグループ変更を監視。
- AWS Firewall Managerでセキュリティグループポリシーを適用。
- 評価:
- 利点: セキュリティグループの変更監視と自動修復が可能。
- 問題点: ポート22を引き続き開けておくため、SSHリスクが残る。監査ログの収集が直接含まれていない。
- 結論: 部分的に適切（セキュリティの強化に不十分）。
D.
- 構成:
- IAMロールを使用して、AWS Systems Manager (SSM) の Session Manager を有効化。
- ポート22のインバウンドルールを削除。
- エンジニアには Session Manager を使用してインスタンスにアクセスさせる。
- 評価:
- 利点:
- ポート22を完全に閉じることでSSH攻撃リスクを排除。
- Session ManagerはAWS Systems Managerの機能として、エンジニアが実行したコマンドを詳細に監査・記録できる（CloudWatch LogsやS3に送信可能）。
- オンプレミスからのVPN経由のアクセスもサポート可能。
- 問題点: 追加設定（IAMロールの割り当て、Session Managerプラグインのインストール）が必要。
- 結論: 最適な解答（セキュリティと監査要件を完全に満たす）。
正解: D
Session Managerを使用することで、SSHアクセスを不要にし、エンドツーエンドでセキュリティを強化しながら、エンジニアのアクションを完全に監査できます。これが最も推奨されるアプローチです。
066-AWS Budgets
理論
AWS Organizations とコスト
AWS環境でのコスト管理は、運用効率を高めながら無駄な出費を抑えるための重要なスキルです。以下に、AWS Organizationsとコスト管理に関連する主要なポイントを整理します。
1. AWS Organizations の役割
- 概要: 複数のAWSアカウントを一元管理するサービス。
- 利点:
- サービスコントロールポリシー（SCP）で、アカウントや組織単位（OU）に適用する制限を設定可能。
- コストやセキュリティポリシーを統一的に適用できる。
2. サービスコントロールポリシー（SCP）
- 目的: アカウント内で許可・拒否するアクションを制御。
- 特徴:
- IAMポリシーよりも上位で動作し、組織全体に影響を与える。
- 高コストなサービスや特定のリソースの利用を制限することで、予期しないコストの発生を抑制可能。
3. AWS Budgets を活用したコスト監視
- 概要: AWSのコストや使用量を追跡し、予算超過時に通知を送るサービス。
- 主要機能:
- 月間予算の設定。
- SNS通知を利用したアラートの送信。
- コストや使用状況に応じたアクションを自動化可能。
4. AWS Lambda を用いたコスト制御
- 活用例:
- AWS BudgetsのSNS通知をトリガーにして、Lambda関数を実行。
- コスト超過時に不要なリソースを自動停止する仕組みを構築可能。
5. IAMポリシーとの違い
- IAMポリシー:
- ユーザーやロールに対するアクセス権限を個別に設定。
- AWS Organizations全体ではなく、アカウント単位で適用。
- SCP:
- 組織全体またはOU単位でアクセス制御を適用。
- 個別アカウントでの設定が不要なため、管理が容易。
6. ベストプラクティス
- コスト制限の設定:
- 高コストなサービスへのアクセスをSCPで制限。
- AWS Budgetsで各アカウントに予算を設定。
- コスト超過時の対応:
- SNS通知とLambdaを組み合わせた自動化を導入。
- 定期的なレビュー:
- コストレポートや使用状況を定期的に確認。
- 無駄なリソースや非効率な設定を見直し。
これらの機能を組み合わせることで、AWS環境における効率的なコスト管理とセキュリティ向上が可能です。
一問道場
質問 #66
AWS Organizations を使用しているある企業が、開発者が AWS で実験できる環境を提供しています。企業はランディングゾーンを展開しており、開発者は会社のメールアドレスを使用してアカウントをリクエストします。企業は、開発者が高コストなサービスを起動したり、不必要にサービスを実行したりしないようにしたいと考えています。企業は、開発者に月ごとの固定予算を設定し、AWS コストを制限する必要があります。
これらの要件を満たすには、どのステップの組み合わせが適切ですか？（3つ選択してください）
A. 固定の月間使用制限を設定する SCP（サービスコントロールポリシー）を作成します。その SCP を開発者アカウントに適用します。
B. AWS Budgets を使用して、アカウント作成プロセスの一環として各開発者アカウントに固定の月間予算を作成します。
C. 高コストなサービスやコンポーネントへのアクセスを拒否する SCP を作成します。その SCP を開発者アカウントに適用します。
D. 高コストなサービスやコンポーネントへのアクセスを拒否する IAM ポリシーを作成します。その IAM ポリシーを開発者アカウントに適用します。
E. 予算額に達した際にサービスを終了する AWS Budgets アラートアクションを作成します。そのアクションをすべてのサービスを終了するように構成します。
F. 予算額に達した際に Amazon Simple Notification Service (Amazon SNS) 通知を送信する AWS Budgets アラートアクションを作成します。その通知で AWS Lambda 関数を呼び出し、すべてのサービスを終了します。
解説
この問題では、開発者が使用するAWSアカウントに対し、コストを制限するための方法を検討します。選択肢の中から適切な組み合わせを選ぶ必要があります。それぞれの選択肢について解説します。
A. SCP（サービスコントロールポリシー）で固定の月間使用制限を設定
- 解説: SCPはAWS OrganizationsでアカウントやOU（組織単位）に適用できるポリシーですが、「固定の月間使用制限」を直接設定する機能はありません。SCPはリソースやアクションの許可・拒否に使用されますが、予算管理の役割は担いません。
- 結論: 不正解
B. AWS Budgetsを使用して、アカウント作成時に固定の月間予算を設定
- 解説: AWS Budgetsは、特定のアカウントやサービスに対する予算を設定し、コストを追跡できる機能です。これにより、開発者ごとに予算を管理でき、特定の制限に達した場合に通知を送ることも可能です。
- 結論: 正解
C. SCPで高コストなサービスやコンポーネントへのアクセスを拒否
- 解説: SCPは特定のサービスやリソースの利用を制限するのに適しています。高コストなサービス（例: EC2の特定インスタンスタイプやRDS）を制限することで、不必要なコストの発生を防ぐことができます。
- 結論: 正解
D. IAMポリシーで高コストなサービスやコンポーネントへのアクセスを拒否
- 解説: IAMポリシーはアカウントやロールに適用できますが、AWS Organizations全体での管理には向いていません。個別アカウントごとに設定が必要で、管理が煩雑になる可能性があります。また、IAMポリシーよりSCPの方が組織単位での制御に適しています。
- 結論: 不正解
E. AWS Budgetsアラートアクションで予算額到達時にサービスを終了
- 解説: AWS Budgetsアラートアクションは通知を送ることが主な機能であり、サービスを自動終了する直接的な方法はありません。さらに、強制的なリソースの終了はビジネス上のリスクを伴います。
- 結論: 不正解
F. AWS BudgetsアラートアクションでSNS通知を送信し、Lambda関数でサービスを終了
- 解説: AWS BudgetsはSNS通知をトリガーできます。SNS通知を受けたLambda関数を設定し、コスト超過時に不要なリソースを終了する自動化が可能です。ただし、慎重に設計しないと予期せぬサービス停止が発生するリスクがあります。
- 結論: 正解
正解の組み合わせ
B, C, F
これらを組み合わせることで、予算の設定、サービス制限、コスト超過時の対応が実現できます。
067-Aurora DB アカウント間 移行
理論
デプロイメントパッケージとは
AWS Lambda 関数の実行に必要なコードや依存関係をまとめたアーカイブファイル（通常 .zip ファイル）のこと。
構成要素
- コード: Lambda 関数で実行するスクリプト。
- 依存関係: 必要なライブラリやモジュール。
- 補助リソース（任意）: 設定ファイルや証明書。
作成手順
- コードと依存関係を準備。
- ディレクトリにまとめて圧縮（例:
zip -r deployment-package.zip .）。
アップロード方法
- AWS マネジメントコンソール
- AWS CLI（例:
aws lambda update-function-code）
- AWS SDK
デプロイメントパッケージは、Lambda 環境でコードを動作させるための重要な基盤です。
AWS Lambda と Aurora の移行
1. AWS Lambda の移行
- デプロイメントパッケージ:
- Lambda関数は、コードとその依存関係をまとめた「デプロイメントパッケージ（.zip）」を使用して移行する。
- ソースアカウントからデプロイメントパッケージをダウンロードし、ターゲットアカウントで新しいLambda関数を作成。
- アクセス許可の移行:
- 移行元のアカウントからターゲットアカウントへLambda関数のアクセス許可や環境変数を再設定する必要がある。
2. Amazon Aurora の移行
- スナップショットの利用:
- Auroraデータベースの移行には、DBスナップショットを使用する方法が一般的。スナップショットを作成し、それをターゲットアカウントと共有。
- 自動バックアップ機能を利用して、最小限のダウンタイムで移行。
- データベースのクローン:
- Auroraクラスターは、クローン機能を使用して簡単に別のアカウントに複製可能。
3. AWS Resource Access Manager (AWS RAM)
- リソースの共有:
- AWS RAMを使用することで、複数のAWSアカウント間でリソース（Lambda関数やAuroraデータベース）を共有できる。
- アカウント間でリソースのアクセス許可を設定し、ターゲットアカウントに移行後の管理権限を付与。
4. ダウンタイムの最小化
- 最小限のダウンタイム:
- Auroraのスナップショットやクローン機能を使用して、データベースの移行中でもアプリケーションの可用性を維持。
- Lambda関数の新規作成や設定変更により、移行中のサービス停止時間を最小化。
- 移行後のテスト:
- 新しいアカウントでLambda関数やAuroraデータベースを移行後、動作確認とテストを行い、アプリケーションの安定性を確認。
これらの手法を用いることで、AWS環境でのサービス移行を効率的かつ低ダウンタイムで実施することができます。
![[AWS] Resource Access Manager で Amazon Aurora（MySQL）のクロスアカウントクローンを作成する | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdev.classmethod.jp%2Ffavicon.ico?table=block&id=1aad7ae8-88e2-8016-8406-ffa0afd9b04e&t=1aad7ae8-88e2-8016-8406-ffa0afd9b04e)
![[AWS] Resource Access Manager で Amazon Aurora（MySQL）のクロスアカウントクローンを作成する | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-aurora.png?table=block&id=1aad7ae8-88e2-8016-8406-ffa0afd9b04e&t=1aad7ae8-88e2-8016-8406-ffa0afd9b04e)
一問道場
質問 #67
ある企業が「Source」という名前のAWSアカウントでアプリケーションを運用しています。このアカウントはAWS Organizations内の組織に属しています。以下の条件でアプリケーションが動作しています：
- AWS Lambda関数を使用しており、在庫データをAmazon Auroraデータベースに保存しています。
- アプリケーションはデプロイメントパッケージを使用してLambda関数をデプロイしています。
- Auroraの自動バックアップが設定されています。
この企業は、Lambda関数とAuroraデータベースを「Target」という新しいAWSアカウントに移行したいと考えています。
アプリケーションは重要なデータを処理するため、ダウンタイムを最小限に抑える必要があります。
どのソリューションがこの要件を満たしますか？
A. SourceアカウントからLambda関数のデプロイメントパッケージをダウンロードします。このデプロイメントパッケージを使用して、Targetアカウントで新しいLambda関数を作成します。自動化されたAurora DBクラスターのスナップショットをTargetアカウントと共有します。
B. SourceアカウントからLambda関数のデプロイメントパッケージをダウンロードします。このデプロイメントパッケージを使用して、Targetアカウントで新しいLambda関数を作成します。AWS Resource Access Manager（AWS RAM）を使用してAurora DBクラスターをTargetアカウントと共有します。TargetアカウントにAurora DBクラスターをクローンする権限を付与します。
C. AWS Resource Access Manager（AWS RAM）を使用して、Lambda関数とAurora DBクラスターをTargetアカウントと共有します。TargetアカウントにAurora DBクラスターをクローンする権限を付与します。
D. AWS Resource Access Manager（AWS RAM）を使用して、Lambda関数をTargetアカウントと共有します。自動化されたAurora DBクラスターのスナップショットをTargetアカウントと共有します。
解説
正しい解答: B
理由:
この問題では、AWS Lambda関数とAuroraデータベースの移行を効率的かつ最小限のダウンタイムで行う方法を求められています。
- Lambda関数の移行:
- ソースアカウントからLambda関数のデプロイメントパッケージをダウンロードし、それをターゲットアカウントで利用して新しいLambda関数を作成する方法が正しいです。
- Auroraデータベースの移行:
- Aurora DBクラスターをそのままAWS Resource Access Manager（AWS RAM）を使って共有し、ターゲットアカウントにクローンの作成を許可する方法が最も効率的で正しいです。
- Auroraのスナップショットを共有する方法もありますが、クローンを作成することにより、ターゲットアカウントで新しいインスタンスを作成する方が、移行中の可用性を維持しやすいため、ダウンタイムを最小化できます。
選択肢の詳細
- A:
- Lambda関数の移行方法は適切ですが、Auroraの自動バックアップを共有するだけでは、スナップショットやクローンの作成手順が不足しています。バックアップを共有するだけでは移行の成功には不十分です。
- B:
- 正解です。Lambda関数の移行にデプロイメントパッケージを使用し、AuroraのDBクラスターをRAMで共有し、ターゲットアカウントでクローン作成を許可する方法が、効率的でダウンタイムを最小化できます。
- C:
- Lambda関数の移行にAWS RAMを使う方法は適切ではなく、デプロイメントパッケージを使った方法が一般的です。
- D:
- Auroraのスナップショットを共有する方法は正しいですが、Lambda関数の移行方法に関してはAWS RAMを使うのは不適切です。
結論:
B が最も効率的でダウンタイムを最小化できる方法であり、正しい解答です。
068-S3 イベント通知
理論
AWSを活用した効率的なデータ処理アーキテクチャ
データ処理ワークロードを効率化し、スケーラビリティや可用性を確保するためには、以下のAWSサービスと設計原則が役立ちます。
1. サーバーレスアーキテクチャ
- AWS Lambda: イベント駆動型でコードを実行。サーバー管理不要で、使用時間に基づく課金モデルがコスト効率を最大化。
- Amazon S3 イベント通知: オブジェクトの作成・削除をトリガーにLambdaなどのサービスを起動可能。
メリット:
- インフラ管理の負担軽減。
- 自動スケーリングによる高可用性。
2. メッセージングとキューイング
- Amazon SQS: ワークロードを非同期で処理するためのキューサービス。スケーラブルで一時的なメッセージ保存に適している。
- Amazon SNS: メッセージの配信をイベント駆動で行う通知サービス。
活用例:
- データの到着順序を制御。
- 分散環境でタスクの負荷分散。
3. コンテナベースのアーキテクチャ
- Amazon ECS と AWS Fargate: コンテナを用いたアプリケーション実行環境を提供。Fargateではサーバー管理が不要。
- コンテナ化の利点: アプリケーションの移植性向上、リソースの効率的な利用。
4. コスト効率の最適化
- イベント駆動モデル: 必要なときだけリソースを利用することで、無駄なコストを削減。
- Auto Scaling: リソースを動的に調整し、需要に応じた運用を実現。
設計原則
- イベント駆動: イベントに応じてサービスを起動し、リアクティブに処理を実行。
- 分散アーキテクチャ: システム全体を耐障害性が高い構成にする。
- 管理負担の軽減: サーバーレスやマネージドサービスを活用して運用の効率化。
これらのAWSサービスと設計原則を活用することで、効率的でスケーラブルなデータ処理を実現し、コストと管理の負担を大幅に削減できます。
一問道場
質問 #68
トピック 1
ある企業が、データを処理するために Amazon EC2 インスタンス上で Python スクリプトを実行しています。このスクリプトは10分ごとに実行され、Amazon S3 バケットからファイルを取得して処理します。平均的に、スクリプトは各ファイルの処理に約5分かかります。また、スクリプトは既に処理済みのファイルを再処理しません。
企業が Amazon CloudWatch メトリクスを確認したところ、EC2 インスタンスはファイル処理速度のために約40%の時間がアイドル状態であることが分かりました。企業は、ワークロードを高可用性かつスケーラブルにしたいと考えています。また、長期的な管理の手間を減らすことも目指しています。
これらの要件を最も費用効果の高い方法で満たすソリューションはどれですか？
A. データ処理スクリプトを AWS Lambda 関数に移行します。S3 イベント通知を使用して、オブジェクトをアップロードした際に Lambda 関数を呼び出してオブジェクトを処理します。
B. Amazon Simple Queue Service (Amazon SQS) キューを作成します。Amazon S3 にイベント通知を設定して、このキューにメッセージを送信するようにします。最小サイズが1のインスタンスを持つ EC2 Auto Scaling グループを作成します。データ処理スクリプトを更新して SQS キューをポーリングし、メッセージが示す S3 オブジェクトを処理します。
C. データ処理スクリプトをコンテナイメージに移行します。データ処理コンテナを EC2 インスタンス上で実行し、S3 バケットに新しいオブジェクトがあるかをポーリングし、結果のオブジェクトを処理するように設定します。
D. データ処理スクリプトを Amazon Elastic Container Service (Amazon ECS) 上で実行するコンテナイメージに移行します。このコンテナを AWS Fargate 上で動作させます。コンテナがファイルを処理するときに Fargate の RunTaskAPI 操作を呼び出す AWS Lambda 関数を作成します。S3 イベント通知を使用して、この Lambda 関数を呼び出します。
069-Route53 DR
理論
AWSでの高可用性とディザスタリカバリを簡単に理解
1. 高可用性（HA）とは？
- システムが 常に動くようにする仕組み。
- どう実現する？
- マルチAZ構成: 1つの障害では止まらないよう、複数のデータセンター（AZ）にサーバーを配置。
- 負荷分散: Application Load Balancer（ALB）を使い、アクセスを分散してシステム全体の負担を減らす。
- 自動スケーリング: ユーザーが増えたらサーバーを増やし、減ったら減らす機能で、無駄を削減。
2. ディザスタリカバリ（DR）とは？
- 障害が発生してもすぐに復旧できる仕組み。
- 主な構成方法
- アクティブ/パッシブ構成:
- メインのシステム（アクティブ）を常に使う。
- 予備のシステム（パッシブ）は待機し、障害時に切り替え。
- Route 53での切り替え:
- Route 53がシステムの状態をチェックし、問題があれば自動で予備に切り替える。
3. よく使うAWSサービス
- EC2: システムを動かすための仮想サーバー。
- ALB（Application Load Balancer）: トラフィックを分散して処理を効率化。
- Route 53: システムを正常なリージョンに誘導するDNSサービス。
- Auto Scaling: サーバー台数を需要に応じて増減させる。
4. 実際の動き方
- 普段:
- メイン（例: us-east-1）でアクセスを処理。
- 障害が発生:
- Route 53が問題を検知。
- 予備（例: us-west-1）に自動で切り替え。
5. ポイントまとめ
- 高可用性:
- マルチAZ + 負荷分散。
- ディザスタリカバリ:
- 予備環境の準備 + 自動切り替え。
- 自動化:
- Auto Scalingでコスト削減＆運用負担軽減。
見ておきたい構成図
- マルチAZでの高可用性（HA）:
- ユーザー → ALB → 複数AZ内のEC2。
- アクティブ/パッシブDR:
- メイン（us-east-1） → Route 53 → 障害時に予備（us-west-1）へ。
これらを組み合わせることで、信頼性が高く、効率的なシステムを構築できます！
一問道場
質問 #69
ある北米の金融サービス企業が、AWS上で顧客向けに新しいオンラインWebアプリケーションをリリースする予定です。
- このアプリケーションは、Amazon EC2インスタンスを利用してus-east-1リージョンで展開されます。
- アプリケーションは高可用性であり、ユーザートラフィックに応じて動的にスケールする必要があります。
- また、us-west-1リージョンにアクティブ-パッシブフェイルオーバーを用いたディザスタリカバリー環境を実装したいと考えています。
要件を満たすソリューションはどれですか？
選択肢:
A.
- us-east-1リージョンとus-west-1リージョンにそれぞれVPCを作成。
- VPCピアリングを設定。
- us-east-1のVPCで、複数のアベイラビリティゾーン(AZ)にまたがるApplication Load Balancer (ALB)を作成。
- Auto Scalingグループを設定し、EC2インスタンスを両リージョンの複数のAZにデプロイ。
- Auto ScalingグループをALBの背後に配置。
B.
- us-east-1リージョンとus-west-1リージョンにそれぞれVPCを作成。
- us-east-1のVPCで、複数のAZにまたがるALBを作成。
- Auto Scalingグループを設定し、us-east-1 VPC内の複数のAZにEC2インスタンスをデプロイ。
- us-west-1でも同じ設定を作成。
- Amazon Route 53ホストゾーンを作成し、各ALBのレコードを個別に設定。
- ヘルスチェックを有効化して、リージョン間の高可用性を確保。
C.
- us-east-1リージョンとus-west-1リージョンにそれぞれVPCを作成。
- us-east-1のVPCで、複数のAZにまたがるALBを作成。
- Auto Scalingグループを設定し、us-east-1 VPC内の複数のAZにEC2インスタンスをデプロイ。
- us-west-1でも同じ設定を作成。
- Amazon Route 53ホストゾーンを作成し、各ALBのレコードを個別に設定。
- ヘルスチェックを有効化し、各レコードにフェイルオーバールーティングポリシーを設定。
D.
- us-east-1リージョンとus-west-1リージョンにそれぞれVPCを作成。
- VPCピアリングを設定。
- us-east-1のVPCで、複数のAZにまたがるALBを作成。
- Auto Scalingグループを設定し、EC2インスタンスを両リージョンの複数のAZにデプロイ。
- Auto ScalingグループをALBの背後に配置。
- Amazon Route 53ホストゾーンを作成し、ALBのレコードを設定。
解説
この問題の要件を整理しながら、各選択肢を解説します。
問題の要件
- 高可用性: us-east-1リージョン内で、複数のAZにわたる可用性を確保する。
- 動的スケーリング: ユーザートラフィックに応じて、インフラを自動的にスケールアップまたはスケールダウンする。
- ディザスタリカバリー: us-west-1リージョンをパッシブフェイルオーバーとして利用する。
- 最適な設計: 各リージョンで個別の構成を持つ必要がある。
選択肢の解説
A: VPCピアリングを利用して、複数リージョンを1つのALBで管理
- 解説:
- ALBをus-east-1で作成し、VPCピアリングを通じてus-west-1のVPCを接続しています。
- Auto Scalingグループで複数のリージョンにまたがるEC2インスタンスを展開。
- 欠点:
- ALBは単一リージョン内でのみ動作可能であり、複数リージョン間で共有することはできません。
- また、VPCピアリングはフェイルオーバー要件を満たしません。
- 結果: 不適切
B: 各リージョンに独立したALBとAuto Scalingグループを展開
- 解説:
- us-east-1とus-west-1でそれぞれALBとAuto Scalingグループを作成。
- Route 53でヘルスチェックを有効化し、高可用性を実現。
- 欠点:
- 高可用性を意識しているものの、明示的なフェイルオーバールーティングポリシーが設定されていません。
- パッシブフェイルオーバー要件を明確に満たしていない。
- 結果: 不完全
C: 各リージョンに独立したALBとAuto Scalingグループを展開し、Route 53でフェイルオーバールーティングを設定
- 解説:
- us-east-1とus-west-1にそれぞれALBとAuto Scalingグループを作成。
- Route 53でヘルスチェックを有効化し、フェイルオーバールーティングポリシーを利用して、us-west-1をパッシブフェイルオーバーとして設定。
- us-east-1のリソースが利用不可の場合、us-west-1へトラフィックを転送。
- 利点:
- 要件を完全に満たす設計であり、高可用性、スケーラビリティ、ディザスタリカバリーが実現可能。
- 結果: 最適解
D: 複数リージョンをVPCピアリングで接続し、ALBを共有
- 解説:
- Aと同様に、ALBをus-east-1で作成し、us-west-1と接続。
- 欠点:
- ALBは単一リージョン内でのみ動作するため、この設計は技術的に不可能。
- 結果: 不適切
結論
正解: C
- 理由:
- 各リージョンに独立したリソースを配置し、Route 53のフェイルオーバールーティングでアクティブ-パッシブ構成を実現できる。
- 要件（高可用性、スケーラビリティ、ディザスタリカバリー）を最も効率的に満たします。
070-IAM Identity Center AD
理論
AWS IAM Identity Center（AWS SSO）を活用するための本質的な知識を以下に整理します。
1. AWS IAM Identity Center (AWS SSO) 概要
- AWS SSO は、AWS のリソースへのアクセス管理を簡素化するサービスです。これにより、オンプレミスのディレクトリ（Active Directory）と統合して、ユーザーの認証と認可を一元的に管理できます。
- 企業内のユーザーが既存のディレクトリの資格情報を使って、複数のAWSアカウントやアプリケーションにシングルサインオン（SSO）でアクセスできるようにします。
2. AWS SSO の主要な設定
- ディレクトリの選択:
- AWS SSO には、2種類のアイデンティティソースを設定できます：
- AWS Managed Microsoft AD: AWS が提供する管理型の Microsoft Active Directory。
- AD Connector: 企業のオンプレミス Active Directory と AWS を接続するサービス。これにより、既存の Active Directory の資格情報を使用してAWSリソースにアクセスできます。
- ユーザーとグループ管理:
- AWS SSO 内でユーザーを作成するか、外部ディレクトリと同期して管理することができます。
- 既存のディレクトリのユーザーとグループを活用し、AWS のリソースへのアクセス権を割り当てます。
3. アクセス管理の効率化
- SSO によるユーザー管理の簡素化:
- 複数のアカウントやアプリケーションに対して、1つのログイン情報でアクセスできるため、パスワード管理やユーザー管理の負担が軽減されます。
- アクセスの一元管理が可能となり、セキュリティ強化にもつながります。
4. コスト効率の観点
- AD Connector vs. AWS Managed Microsoft AD:
- AD Connector は既存のオンプレミス Active Directory を活用するため、追加のコストが発生しません。
- 一方、AWS Managed Microsoft AD は AWS が完全に管理するディレクトリサービスで、運用コストがかかります。小規模環境や既存のディレクトリがある場合は、AD Connector の方がコスト効果的です。
AWS Organizationsの機能
機能 | 説明 | 小規模環境への適用 |
組織単位 (OUs) | 複数のアカウントを整理・管理するための機能。 | 小規模環境では不要な場合が多い。 |
サービスコントロールポリシー (SCPs) | AWSアカウントに対してアクセス制御を強化する機能。 | 設定が複雑で、小規模環境では過剰な場合がある。 |
AWS Budgets と Cost Explorer | 複数アカウントのコスト管理と予算設定を行う機能。 | 小規模環境では過剰で、管理負担が増える可能性がある。 |
Consolidated Billing（統合請求） | 複数のAWSアカウントの請求をまとめて1つにする機能。 | 少数アカウントでは不要な場合が多い。 |
AWS Single Sign-On（SSO） | 複数のAWSアカウントや外部アプリケーションに対してシングルサインオン（SSO）アクセスを提供する機能。 | 小規模環境では設定が煩雑になりやすい。 |
複数アカウント管理 | 複数のAWSアカウントを一元管理し、セキュリティやガバナンスを強化する機能。 | 少数のアカウントの場合、設定が過剰になることが多い。 |
リソース共有 | 複数のAWSアカウント間でリソースを共有する機能。 | 少数アカウントでの運用には過剰な機能。 |
まとめ
- 上記の機能は、組織が大規模に運用される場合や、複数アカウントを管理する必要がある場合に有用です。
- 小規模な環境では、設定や管理が複雑になり過ぎるため、最小限の機能だけを選択する方がコスト効率が良く、運用が簡単です。
アイデンティティソース
アイデンティティソースとは、ユーザー認証を行うために使用される「ユーザー情報の元となる場所」です。AWSの文脈では、アイデンティティソースは、ユーザーの認証情報が格納され、アクセス制御が行われる場所を指します。
例えば、AWSでのアイデンティティソースには次のようなものがあります。
1. AWS IAM（Identity and Access Management）
- IAMユーザーとその認証情報（ユーザー名、パスワード、アクセスキーなど）はAWS IAM内に管理されます。IAMをアイデンティティソースとして使用すると、AWSのリソースへのアクセス管理がIAMユーザーごとに行われます。
2. AWS IAM Identity Center（旧AWS SSO）
- IAM Identity Center（SSO）をアイデンティティソースに設定すると、オンプレミスのActive Directoryや外部の認証プロバイダー（Google WorkspaceやOktaなど）を通じて、AWSアカウントへのアクセスを管理できます。これにより、SSO（シングルサインオン）が実現され、ユーザーは一度認証すれば、複数のAWSアカウントやサービスにアクセスできるようになります。
3. AWS Directory Service
- AD ConnectorやAWS Managed Microsoft ADなどのサービスをアイデンティティソースに設定することで、オンプレミスのActive Directoryと連携して、AWSのサービスにアクセスできるようになります。これにより、Active Directoryに登録されているユーザーアカウントを使ってAWSリソースにアクセスできるようになります。
アイデンティティソースの選定の重要性
アイデンティティソースは、組織がどのようにユーザーの認証と認可を管理するかに大きな影響を与えます。例えば：
- IAMユーザーをアイデンティティソースとして選んだ場合、ユーザーのパスワードやアクセスキーなどをAWS内で管理する必要があります。
- IAM Identity Centerを選択した場合、既存のActive Directoryや外部の認証システムを利用して一元的にユーザー管理と認証を行えるため、ユーザー管理が簡素化されます。
まとめ
アイデンティティソースは、AWS環境にアクセスするために認証を行う場所を意味し、通常はIAM、IAM Identity Center、またはディレクトリサービス（AD ConnectorやAWS Managed Microsoft AD）などが用いられます。どのアイデンティティソースを選ぶかは、組織のユーザー管理方針やコスト効率に影響を与えます。
例
- ユーザーの認証：
- Active Directory (AD) がユーザーの認証を担当します。ユーザーが企業の内部ネットワークにログインする際に、ADはそのユーザーの資格情報（ユーザー名とパスワード）を確認します。
- 認証結果の伝達：
- 認証が成功すると、ADはそのユーザーの認証情報を**IAM Identity Center (SSO)**に伝えます。この情報は、ユーザーがAWSリソースにアクセスするための権限を持っているかどうかを確認するために使用されます。
- アクセスの許可：
- IAM Identity Centerは、ユーザーがどのようなAWSリソースにアクセスできるかを制御します。たとえば、IAM Identity Center内で設定された許可セット（Permission Sets）に基づいて、ユーザーにアクセス権が割り当てられます。
この流れにより、オンプレミスAD（Active Directory）がユーザー認証を担当し、認証後のアクセス制御はIAM Identity Centerが担当します。この構成は、企業の既存のActive Directory資格情報を活用し、AWS Management ConsoleへのアクセスをSSOでシームレスに統合するためのものです。
一問道場
ある企業は、単一のAWSアカウントを使用する環境を持っています。ソリューションアーキテクトがこの環境をレビューし、特にAWS Management Consoleへのアクセス方法に関して改善点を提案しようとしています。現在、ITサポート担当者は、ジョブロールに紐づけられたIAMユーザーとして認証を行い、コンソールにアクセスして管理タスクを実行しています。
ITサポート担当者は、Active DirectoryとIAMユーザーアカウントの両方を管理することを望まなくなり、既存のActive Directoryの資格情報を使用してコンソールにアクセスできるようにしたいと考えています。ソリューションアーキテクトは、この機能を実現するためにAWS IAM Identity Center（AWS Single Sign-On）を使用しています。
この要件を最もコスト効率よく満たすソリューションはどれですか？
選択肢：
A:
- AWS Organizationsで組織を作成
- OrganizationsでIAM Identity Center機能を有効にする
- AWS Directory Service for Microsoft Active Directory（AWS Managed Microsoft AD）でディレクトリを作成し、企業のオンプレミスActive Directoryとの双方向トラストを設定
- IAM Identity Centerを設定し、AWS Managed Microsoft ADディレクトリをアイデンティティソースとして選択
- 既存のAWS Managed Microsoft ADディレクトリ内のグループに許可セットを作成して割り当て
B:
- AWS Organizationsで組織を作成
- OrganizationsでIAM Identity Center機能を有効にする
- AD Connectorを作成して、企業のオンプレミスActive Directoryに接続
- IAM Identity Centerを設定し、AD Connectorをアイデンティティソースとして選択
- 既存のActive Directory内のグループに許可セットを作成して割り当て
C:
- AWS Organizationsで組織を作成
- 組織のすべての機能を有効にする
- AWS Directory Service for Microsoft Active Directory（AWS Managed Microsoft AD）でディレクトリを作成し、企業のオンプレミスActive Directoryとの双方向トラストを設定
- IAM Identity Centerを設定し、AWS Managed Microsoft ADディレクトリをアイデンティティソースとして選択
- 既存のAWS Managed Microsoft ADディレクトリ内のグループに許可セットを作成して割り当て
D:
- AWS Organizationsで組織を作成
- 組織のすべての機能を有効にする
- AD Connectorを作成して、企業のオンプレミスActive Directoryに接続
- IAM Identity Centerを設定し、AD Connectorをアイデンティティソースとして設定
- 既存のActive Directory内のグループに許可セットを作成して割り当て
解説
要件の理解:
問題では、企業のITサポート担当者が現在、AWS Management ConsoleへのアクセスにIAMユーザーアカウントを使用しているが、既存のActive Directory（AD）の資格情報を使用してAWSにアクセスしたいという要件があります。また、ITサポート担当者はActive DirectoryとIAMユーザーの両方のアカウントを管理することを望まなくなっているため、**IAM Identity Center（旧AWS Single Sign-On）**を使って、Active Directoryの資格情報を活用し、AWSにアクセスできるようにするという目的です。
解決策の分析:
IAM Identity Center（旧AWS Single Sign-On）は、AWS環境でシングルサインオン（SSO）機能を提供し、既存のユーザー認証基盤（例えば、Active Directory）と統合して、複数のAWSアカウントやサービスにアクセスできるようにします。これにより、Active Directoryに基づいてAWSのアクセス管理が可能になります。
AD Connectorを使用すると、オンプレミスのActive DirectoryとAWSサービス（IAM Identity Centerなど）を接続することができます。これにより、AWS側で別途ユーザーを作成することなく、Active DirectoryのユーザーをAWS Management Consoleにアクセスさせることができます。
選択肢の評価:
Aの選択肢:
- AWS Managed Microsoft AD を使用する方法です。これは、オンプレミスのActive DirectoryとAWS Managed Microsoft AD（AWSが提供するActive Directory）を双方向で接続し、その後、IAM Identity Centerを利用して、AWS Managed Microsoft ADをアイデンティティソースとして使います。
- これは機能的には正しいですが、コスト効率が悪いです。AWS Managed Microsoft ADはAD Connectorよりも高額です。
Bの選択肢:
- AD Connector を使用してオンプレミスのActive DirectoryとAWSを接続し、IAM Identity Centerを利用して認証します。
- ただし、IAM Identity CenterはAWS Organizationsの「すべての機能」が有効化されている状態でのみ利用可能です。問題文にあるように、「IAM Identity Centerを機能として有効にする」ということはできません。AWS Organizationsを「すべての機能」にする必要があります。従って、この選択肢は不適切です。
Cの選択肢:
- AWS Managed Microsoft ADを使用し、IAM Identity Centerを設定します。これも機能的には正しいですが、コスト効率が悪いという点でAと同様です。
Dの選択肢:
- AD Connectorを使用して、オンプレミスのActive Directoryと接続し、IAM Identity Centerを設定します。
- 重要な点は、AWS Organizationsで「すべての機能」を有効にすることです。この設定で、IAM Identity Centerを有効化することができます。
- この選択肢が最もコスト効率が良い解決策です。AD Connectorを使うことで、オンプレミスのActive Directoryと直接接続し、IAM Identity Centerを活用して既存のユーザーアカウントをAWSで利用するため、最もコストパフォーマンスが高いです。
結論:
最もコスト効率よく要件を満たす解決策は、Dです。この選択肢では、AD Connectorを使って既存のActive Directoryと接続し、IAM Identity Centerを有効にして、AWS Management Consoleへのアクセスをシームレスに行います。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16ad7ae8-88e2-8060-8589-ccdd5fa7d24b
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
