type
status
date
slug
summary
tags
category
icon
password
书籍
051-Amazon S3の暗号化
理論
2. Amazon S3の暗号化４種類
SSE-S3
- Amazon S3によって処理、管理されるキーを使用
- オブジェクトを固有のキーで暗号化
AES-256暗号化タイプを使用
"x-amz-server-side-encryption":"AES256"ヘッダーを設定して利用する
SSE-KMS
- オブジェクトを作成する際にAWS Key Management Service(AWS KMS)の顧客マスタキー(CMK)を使用するサーバ側の暗号化によりデータを暗号化するように指定
"x-amz-server-side-encryption":"aws:kms"ヘッダーを設定して利用する
SSE-C
- サーバ側の暗号化を使用して独自の暗号化キーを設定
- リクエストの一部として用意された暗号化キーで、Amazon S3 は、ディスクに書き込む際の暗号化、オブジェクトにアクセスする際の復号を管理
AES-256暗号化タイプを使用
- HTTPSだけサポートする
クライアント側の暗号化
- クライアント側の暗号化でAmazon S3に送る前にデータを暗号化する方法
- クライアント側暗号化ライブラリ（AWS Encryption SDK）を使用すると暗号化をより容易に実装可能
- AWS Encryption SDKとAmazon S3 暗号化クライアントは、異なるデータ形式で暗号テキストを生成するため互換できない
1. S3の暗号化方法:
AWS S3では、オブジェクトを保存する際に、暗号化を行うことでデータを保護できます。主に2つの方法があります：
- SSE-S3 (Server-Side Encryption with S3-Managed Keys): S3が管理する暗号化キーを使用します。手軽に利用できますが、制御の幅は狭いです。
- SSE-KMS (Server-Side Encryption with KMS Managed Keys): AWS Key Management Service (KMS) を使用して、暗号化キーを管理できます。より細かい制御や監査が可能です。
2. デフォルト暗号化設定:
S3バケットには「デフォルトの暗号化設定」を有効にすることができます。この設定により、アップロードされたオブジェクトは、指定した暗号化方式（SSE-S3やSSE-KMS）で自動的に暗号化されます。これにより、暗号化されていないデータがS3に保存されることを防げます。
3. 暗号化強制のためのバケットポリシー:
S3バケットポリシーを使用して、未暗号化のオブジェクトがバケットに保存されることを防ぐことができます。例えば、未暗号化のPutObjectリクエストを拒否することで、すべてのオブジェクトが指定した暗号化方式で保存されるように強制することができます。
4. 再アップロードによる暗号化の変更:
既存のオブジェクトの暗号化方式を変更するためには、オブジェクトを再アップロードする必要があります。S3バケットのデフォルト暗号化設定を変更しても、既存オブジェクトには適用されないため、新しい暗号化方式で再アップロードすることが求められます。
5. 暗号化とセキュリティ管理:
暗号化を使用することで、データが保存されている間に盗聴されるリスクを減らし、セキュリティを強化できます。また、KMSキーを使用することで、暗号化キーのアクセス権限や監査を細かく管理することができます。
これらの知識を組み合わせることで、S3の暗号化を適切に管理し、セキュリティ要件に対応することができます。
一問道場
質問 #51
ある医療保険会社が、個人識別情報（PII）をAmazon S3バケットに保存しています。この会社では、オブジェクトを暗号化するためにS3管理暗号化キー（SSE-S3）を使用しています。しかし、新しい要件により、S3バケット内の現在および将来のすべてのオブジェクトを、会社のセキュリティチームが管理するキーを使用して暗号化する必要があります。このS3バケットにはバージョニングは有効化されていません。
この要件を満たすためには、どのソリューションを採用すべきですか？
選択肢
A.
S3バケットのプロパティでデフォルトの暗号化設定をSSE-S3からKMS-CMKを使用した暗号化に変更します。AWS CLIを使って、S3バケット内のすべてのオブジェクトを再アップロードします。さらに、未暗号化のPutObjectリクエストを拒否するS3バケットポリシーを設定します。
B.
S3バケットのプロパティでデフォルトの暗号化設定をAWS KMS管理の暗号化キー（SSE-KMS）に変更します。未暗号化のPutObjectリクエストを拒否するS3バケットポリシーを設定します。その後、AWS CLIを使用して、S3バケット内のすべてのオブジェクトを再アップロードします。
C.
S3バケットのプロパティでデフォルトの暗号化設定をAWS KMS管理の暗号化キー（SSE-KMS）に変更します。S3バケットポリシーを設定し、GetObjectおよびPutObjectリクエスト時にオブジェクトが自動的に暗号化されるようにします。
D.
S3バケットのプロパティでデフォルトの暗号化設定を顧客管理キー（AES-256）を使用した暗号化に変更します。S3バケットにアクセスするエンティティが未暗号化のPutObjectリクエストを送信できないようにするポリシーを設定します。その後、AWS CLIを使用して、S3バケット内のすべてのオブジェクトを再アップロードします。
解説
選択肢 B は、次の要件を満たすための最適な方法です：
- SSE-KMSの使用：
- S3バケットのデフォルト暗号化設定を SSE-KMS（AWS KMS管理の暗号化キー）に変更します。これにより、セキュリティチームが管理するKMSキーを使用してオブジェクトが暗号化されます。SSE-S3ではなく、SSE-KMSを選択することで、暗号化キーを管理する権限がAWS KMSに委任され、セキュリティチームがそのキーを管理できます。
- 未暗号化のPutObjectリクエストを拒否：
- バケットポリシーを設定して、未暗号化のPutObjectリクエスト（暗号化されていないオブジェクトのアップロード）を拒否します。これにより、今後S3バケットに保存されるオブジェクトは必ず暗号化され、ポリシーによりセキュリティが強化されます。
- 既存のオブジェクトの再アップロード：
- バケット内の既存オブジェクトは自動的に暗号化されないため、AWS CLIを使用して、これらのオブジェクトを再アップロードする必要があります。再アップロードによって、既存のオブジェクトも新しい暗号化キーで暗号化されます。
他の選択肢の問題点：
- A は、SSE-KMSの使用方法が誤っており、KMS-CMKという不適切な用語が使われています。また、再アップロードの手順が不完全です。
- C は、SSE-KMSを使う点では正しいものの、「自動的に暗号化される」という説明が誤解を招きます。既存のオブジェクトは再アップロードする必要があるため、その指示が不足しています。
- D は、顧客管理キー（AES-256）を使用する設定ですが、これはセキュリティチームの管理するキーではなく、要件に合致しません。
そのため、B が最適な選択肢です。
「自動暗号化」と「未暗号化のPutObjectリクエストを拒否するポリシー」は似ていますが、違いがあります。
- 自動暗号化：オブジェクトは自動的に暗号化され、アップロード時に暗号化を指定しなくても暗号化されます。
- ポリシーによる拒否：暗号化されていないオブジェクトのアップロードを拒否しますが、自動的に暗号化されるわけではありません。
つまり、自動暗号化は暗号化を自動で行い、ポリシーは暗号化されていないリクエストをブロックします。
052-CloudFront フェイルオーバー
理論
AWS Global Acceleratorとは
AWS Global Accelerator は、アプリケーションのグローバルユーザーに対する低レイテンシー、信頼性、パフォーマンスを向上させるサービスです。
主な特徴:
- グローバルエンドポイント管理:
- 複数のAWSリージョンやリソース（ALB, NLB, EC2インスタンスなど）を単一のエンドポイントで公開。
- 障害時にはヘルスチェックで健全なエンドポイントへ自動的にトラフィックを切り替え。
- AWSバックボーンネットワーク:
- ユーザーのリクエストを最も近いエッジロケーションからAWSバックボーンネットワーク経由で処理。
- インターネット経由よりも高速で信頼性の高いルーティング。
- DNSベースではない:
- クライアントからGlobal Acceleratorへの接続は静的IPアドレスを使用するため、DNSキャッシュの影響を受けない。
主なユースケース:
- グローバルなユーザーに対する高可用性アプリケーション。
- 複数リージョンを跨ぐ負荷分散やフォールトトレランス。
CloudFrontとは
Amazon CloudFront は、静的および動的コンテンツを高速に配信するコンテンツデリバリーネットワーク (CDN) です。
主な特徴:
- エッジロケーション:
- 世界中のエッジロケーションを活用して、ユーザーに最も近いポイントからコンテンツを配信。
- キャッシュの活用:
- 静的コンテンツをキャッシュし、オリジンサーバーへの負荷を軽減。
- 動的コンテンツもリアルタイムで配信可能。
- セキュリティ機能:
- AWS Shield StandardやAWS WAFと統合し、DDoS攻撃や不正アクセスを防止。
主なユースケース:
- ウェブサイトや動画の配信。
- APIの高速化。
- セキュリティ強化（SSL/TLS暗号化やオリジンシールド）。
Route 53のフェイルオーバーとCloudFrontの比較表
特徴 | Route 53 フェイルオーバー | CloudFront |
主な用途 | DNSベースでのリソース切り替え | コンテンツの高速配信 |
切り替え対象 | IPアドレスやDNSレコード | オリジン（ALB, S3バケットなど） |
動作方法 | ヘルスチェックに基づいてレコードを切り替え | プライマリとセカンダリのオリジングループ |
応答速度 | DNSキャッシュに依存し、数分かかる場合あり | 即時切り替え（オリジングループ機能） |
セキュリティ | DNSベースのセキュリティ（簡易的） | AWS WAFやShieldでDDoS対策が可能 |
主な制約 | DNSキャッシュの影響を受ける | 配信対象がCloudFront経由である必要 |
ALBはリージョン間のフォールトオーバーができない理由
ALB（Application Load Balancer）は、単一のAWSリージョン内でトラフィックを分散するためのサービスです。
理由:
- リージョンスコープの制限:
- ALBはリージョン内のリソース（EC2インスタンスやターゲットグループ）のみを管理可能。
- グローバルIPアドレスがない:
- ALBは静的なグローバルIPアドレスを提供しないため、他リージョンとの直接的なトラフィック切り替えができない。
- 代替ソリューション:
- グローバルフォールトオーバーには、AWS Global AcceleratorやCloudFrontを利用してリージョンを跨ぐトラフィック管理を実現。
これらの知識を活用することで、信頼性の高いAWSアーキテクチャを設計できます。
一問道場
質問 #52
ある会社が AWSクラウド で Web アプリケーションを運用しています。このアプリケーションは、以下の構成になっています：
- Amazon EC2 インスタンス で作成された動的コンテンツ。
- EC2 インスタンスは Auto Scaling グループ に属しており、Application Load Balancer (ALB) のターゲットグループとして設定されている。
さらに、会社は以下のサービスを使用しています：
- Amazon CloudFront: アプリケーションをグローバルに配信。CloudFront ディストリビューションは ALB をオリジンとして使用している。
- Amazon Route 53: DNS 管理に利用。
www.example.comの A レコード を CloudFront ディストリビューションに設定済み。
課題
ソリューションアーキテクトは、このアプリケーションを 高可用性 かつ フォールトトレラント にするように構成する必要があります。
どのソリューションがこれらの要件を満たしますか？
選択肢
A.
- 異なる AWS リージョンに、フルセットのセカンダリアプリケーションデプロイメントを構築する。
- Route 53 の A レコードをフェイルオーバーレコードに更新する。
- 両方の CloudFront ディストリビューションを値として追加し、Route 53 のヘルスチェックを作成する。
B.
- 異なる AWS リージョンに ALB、Auto Scaling グループ、および EC2 インスタンスを構築する。
- CloudFront ディストリビューションを更新し、新しい ALB をオリジンとして追加する。
- 2 つのオリジンを含むオリジングループを作成し、一方をプライマリ、もう一方をセカンダリとして設定する。
C.
- 異なる AWS リージョンに Auto Scaling グループと EC2 インスタンスを構築する。
- 新しい Auto Scaling グループのターゲットを ALB に追加する。
- ALB にフェイルオーバールーティングアルゴリズムを設定する。
D.
- 異なる AWS リージョンに、フルセットのセカンダリアプリケーションデプロイメントを構築する。
- 新しい CloudFront ディストリビューションを作成し、新しいアプリケーションセットアップをオリジンとして追加する。
- AWS Global Accelerator を作成し、両方の CloudFront ディストリビューションをエンドポイントとして追加する。
どれが適切なソリューションですか？
問題の解説
問題概要
この問題では、AWS CloudFrontを利用してアプリケーションをグローバルに配信しつつ、高可用性 (High Availability) とフォールトトレランス (Fault Tolerance) を実現する構成を選ぶ必要があります。
以下の要素がポイントです:
- 高可用性: アプリケーションが障害発生時でも稼働し続けること。
- フォールトトレランス: 一部のコンポーネントに障害が起きても、全体の機能が停止しない設計。
- CloudFrontとALBの役割: CloudFrontがユーザーに近いエッジでコンテンツを配信し、ALBがオリジンとしてEC2インスタンスへの負荷分散を行う。
選択肢の評価
A: Route 53によるフェイルオーバー
- 構成: 2つのCloudFrontディストリビューションを異なるリージョンに配置し、Route 53のフェイルオーバーレコードを使用。
- 評価:
- DNSフェイルオーバーは動作に数分の遅延が生じる可能性があります（DNSキャッシュの影響）。
- 高可用性とフォールトトレランスを実現しますが、切り替えの速度が遅く、ユーザー体験に影響を及ぼす可能性があります。
- 結果: 適切だが、より迅速な切り替えが可能な方法が優先されます。
B: CloudFrontのオリジングループ
- 構成: 2つのALB（異なるリージョン）をCloudFrontのオリジンとして設定し、プライマリとセカンダリをオリジングループで管理。
- 評価:
- CloudFrontのオリジングループはヘルスチェックを利用して、プライマリの障害時にセカンダリへ即座に切り替えます。
- DNSキャッシュの影響を受けず、迅速かつシームレスな切り替えが可能です。
- 結果: この方法が最も高可用性とフォールトトレランスを効率的に実現します。 正解。
C: ALB内でのフォールトオーバー
- 構成: 単一のALB内に複数リージョンのターゲットを設定。
- 評価:
- ALBは単一リージョン内での負荷分散しか対応しておらず、複数リージョン間でのフォールトトレランスを実現できません。
- 結果: 不適切。
D: AWS Global Acceleratorの利用
- 構成: Global Acceleratorを使用し、複数のCloudFrontディストリビューションをエンドポイントとして設定。
- 評価:
- 高可用性とフォールトトレランスを実現可能。
- ただし、Global Acceleratorは通常、非常に低レイテンシーを要求するリアルタイムアプリケーション向けで、今回のWebアプリケーションには過剰なアプローチです。
- 結果: 適切だが、コストと複雑さの観点から非推奨。
正解
B: CloudFrontのオリジングループを使用
ポイントとなる本質的な知識
- CloudFrontのオリジングループ:
- プライマリオリジンが利用不可になると、セカンダリオリジンに即座に切り替え可能。
- DNSキャッシュの影響を受けないため、迅速な切り替えを実現。
- ALBのリージョン制限:
- ALBは単一リージョン内のリソースを管理するため、リージョン間でのフォールトトレランスには不適切。
- Route 53のフェイルオーバー:
- ヘルスチェックによるフェイルオーバーが可能だが、DNSキャッシュにより切り替えの遅延が発生。
- Global Accelerator:
- 非常に低レイテンシーを必要とするアプリケーションに適しているが、今回のケースではCloudFrontで十分対応可能。
これらを踏まえると、Bの構成が最適となります。
053-プレフィックスリスト
理論
1. プレフィックスリストとは？
- 定義: プレフィックスリストは、1つ以上のCIDRブロック(IPアドレスの範囲)をまとめたリストです。
- 用途:
- セキュリティグループやルートテーブルの設定を簡略化。
- 一括管理により、複数のIPアドレス範囲を個別に管理する手間を削減。
- メリット:
- リストを一度更新するだけで、それを参照しているすべての設定に即座に適用。
- 最大1000件のIPアドレス範囲をサポート。
主な特徴：
- IP アドレス範囲の管理:
- プレフィックスリストは、複数の IP アドレス範囲（CIDR ブロック）をリストとしてまとめることができます。
- 例えば、会社のグローバルオフィスの IP アドレス範囲をリストにまとめて管理できます。
使い方の例：
- セキュリティグループで使用: グローバルオフィスの全ての IP アドレス範囲を1つのプレフィックスリストとしてまとめ、そのリストをセキュリティグループのルールに組み込むことで、複数のアカウントで一貫したアクセス制御を実現します。
- ルートテーブルで使用: VPC間でのトラフィックを制御するために、プレフィックスリストをルートテーブルに追加して、トラフィックが指定した IP 範囲にルーティングされるようにできます。
例:
例えば、企業が各オフィスの IP アドレス範囲を持っているとします。この場合、プレフィックスリストに各オフィスの IP アドレス範囲を追加しておき、そのリストをセキュリティグループのルールや VPC 間のルート設定で使用することができます。これにより、各オフィスからのトラフィックを安全に管理し、変更を一元的に更新できるようになります。
2. AWS Resource Access Manager (RAM) での共有
- RAMの役割:
- AWS Organizations内の複数アカウントや特定のアカウント間で、リソースを簡単に共有できる。
- プレフィックスリストを含む、VPC、サブネット、トランジットゲートウェイなどのネットワーク関連リソースを共有可能。
- 利用シーン:
- 中央集権的な管理を必要とする場合。
- 各アカウントが独立しているが、共通のネットワーク設定を使用する場合。
3. セキュリティグループとアクセス制御
- セキュリティグループ:
- AWS環境でインバウンド/アウトバウンドトラフィックを制御する仮想ファイアウォール。
- 特定のIPアドレスまたはCIDRブロックに基づいて通信を許可/拒否。
- プレフィックスリストとの連携:
- セキュリティグループのルールにプレフィックスリストを使用すると、IPアドレスの管理が簡潔になる。
- 例えば、複数のIPアドレスを許可する場合、リスト化して1つのルールに統合可能。
4. ネットワーク管理の効率化
- 中央管理の利点:
- 複数アカウントやリージョンにわたるIPアドレスやセキュリティ設定を一元管理。
- 更新作業を簡略化し、人的ミスを削減。
- スケーラビリティ:
- 動的なネットワーク変更に対応しやすい。
- 新しいIPアドレスやCIDRブロックを迅速に追加可能。
5. プレフィックスリストとトランジットゲートウェイ
- トランジットゲートウェイの役割:
- 複数のVPCやオンプレミスネットワークを統合するハブ。
- VPN接続やDirect Connectとの連携で、企業全体のネットワーク基盤を構築。
- プレフィックスリストの活用:
- トランジットゲートウェイを通じたルート設定やアクセス制御を簡素化。
6. 運用負荷を減らすためのベストプラクティス
- 一括管理ツールの活用:
- プレフィックスリストやRAMを使用して、設定の冗長性を排除。
- 必要に応じてInfrastructure as Code(IaC)を採用し、設定の自動化を実現。
- ドキュメントとトラッキング:
- すべてのリソース共有や更新履歴を記録。
- IAMポリシーを適切に設定し、誤操作を防止。
このように、AWSのプレフィックスリストとRAMを活用することで、ネットワーク管理の効率化、セキュリティの向上、運用負荷の削減が可能です。これらの技術を正しく使いこなすことで、大規模なAWS環境でも柔軟で安全なネットワーク設計が実現できます。
実践
一問道場
質問 #53
ある企業がAWS Organizationsで複数のAWSアカウントを持つ組織を運営しています。その中の1つのAWSアカウントは「トランジットアカウント」として指定されており、トランジットゲートウェイが他のすべてのAWSアカウントと共有されています。
この企業は、グローバル拠点とトランジットアカウントの間でAWS Site-to-Site VPN接続を構成しています。また、AWS Configがすべてのアカウントで有効化されています。
ネットワークチームは、グローバル拠点に属する内部IPアドレス範囲のリストを集中管理する必要があります。開発者はこのリストを参照して、アプリケーションへの安全なアクセスを確保します。
次の条件を満たし、最小限の運用負荷でこれらの要件を満たすソリューションはどれですか？
A.
Amazon S3にホストされたJSONファイルを作成し、内部IPアドレス範囲をリスト化します。
JSONファイルが更新されたときに各アカウントでトリガーされるAmazon SNSトピックを設定します。SNSトピックにAWS Lambda関数をサブスクライブして、更新されたIPアドレス範囲で関連するセキュリティグループルールを更新します。
B.
内部IPアドレス範囲をすべて含む新しいAWS Configマネージドルールを作成します。このルールを使用して、各アカウントのセキュリティグループがIPアドレス範囲リストと一致していることを確認します。不一致が検出された場合、ルールが自動で修復を行うよう設定します。
C.
トランジットアカウントで、すべての内部IPアドレス範囲を含むVPCプレフィックスリストを作成します。AWS Resource Access Managerを使用して、このプレフィックスリストを他のすべてのアカウントと共有します。共有されたプレフィックスリストを使用して、他のアカウントでセキュリティグループルールを構成します。
D.
トランジットアカウントで、すべての内部IPアドレス範囲を含むセキュリティグループを作成します。他のアカウントで、トランジットアカウントのセキュリティグループを「ネストされたセキュリティグループ参照（/sg-1a2b3c4d）」を使用して参照するセキュリティグループを構成します。
解説
この問題は、複数のAWSアカウントでIPアドレス範囲を一元管理し、セキュリティグループに適用する方法を問うものです。
最も適切な解決策はCです。具体的には、トランジットアカウントでVPCプレフィックスリストを作成し、それを**AWS Resource Access Manager (RAM)**を使って他のアカウントと共有します。これにより、各アカウントのセキュリティグループが同じIPアドレス範囲を参照でき、管理が簡単になります。
054-AWS Compute Optimizer
理論
AWS Compute Optimizerとは
AWS Compute Optimizer は、機械学習を使ってリソースの使用状況を分析し、最適なリソースを提案するサービスです。これにより、コスト削減やパフォーマンス向上を視覚的に確認できます。
サポート対象のリソースは以下の4つです：
- EC2インスタンス
- EC2 AutoScaling
- EBSボリューム
- Lambda関数
基本利用料は無料で、分析期間は通常2週間ですが、3ヶ月分のデータ分析を行う場合は有料となり、料金は1時間あたり$0.0003360215です。
opt-in
「オプトイン（opt-in）」とは、サービスや機能を利用するために自分から選択して参加することを指します。AWS Compute Optimizerにおける「オプトイン」とは、ユーザーがこのサービスを有効にするために明示的に選択し、サービスを開始することを意味します。
AWS Compute Optimizerを利用するためには、まずオプトインしてサービスを有効にする必要があります。これにより、AWSアカウント内のリソースの使用状況を分析し、最適な構成を提案してもらえるようになります。
AWS Compute Optimizerが提供する推奨設定の具体例を以下に示します。
1. EC2インスタンスの推奨
- 例:
- 状況: 大きなインスタンス (例:
m5.2xlarge) が使用されているが、実際のCPUやメモリ使用量が少ない。 - 推奨: より小さなインスタンス (例:
m5.xlarge) への変更を提案。これによりコストを削減できます。 - 理由: 使用しているインスタンスのリソースが過剰であり、必要なリソースを無駄に消費しているため。
2. EC2 Auto Scalingの推奨
- 例:
- 状況: Auto Scalingグループが多すぎるインスタンスを起動している。リソース使用率が低いため、スケーリングが非効率的。
- 推奨: Auto Scalingのしきい値を調整して、インスタンスの数を減らす。適切なスケーリングポリシーを設定し、より効率的なリソースの使用を促進。
- 理由: 過剰にインスタンスをスケーリングすることで、コストが増加しているため、最適化する必要があります。
3. EBSボリュームの推奨
- 例:
- 状況: EBSボリュームが過剰に大きい（例えば、1000GB）が、実際には50GBしか使用していない。
- 推奨: ボリュームサイズを適切な容量に縮小（例: 50GB）。
- 理由: 余分な容量を保持していることでコストが無駄に発生しているため、サイズの調整を提案します。
4. Lambda関数の推奨
- 例:
- 状況: Lambda関数が4GBのメモリで設定されているが、実際には1GBのメモリでも十分なパフォーマンスが得られている。
- 推奨: Lambda関数のメモリ設定を1GBに減らす。
- 理由: メモリ設定が過剰であるため、コスト削減が可能です。Lambdaの実行時間やリソース消費に基づき、最適なメモリサイズを提案します。
これらの推奨設定を適用することで、AWSのリソース利用が最適化され、コスト削減とパフォーマンス向上を実現できます。
AWS Trusted Advisor
以下は、AWS Trusted Advisorの最適化に関するアドバイスと推奨設定の具体例を表形式でまとめたものです。
カテゴリ | 推奨事項 | 具体例 |
コスト最適化 | 未使用リソースの停止または削除 | 長期間使用されていないEC2インスタンスを停止・削除 |
ㅤ | 過剰なリソースの削減 | EC2インスタンスやEBSボリュームのサイズ調整 |
セキュリティ | セキュリティグループの最適化 | 不要なポート（SSH/RDP）の閉鎖 |
ㅤ | 最小権限設定 | IAMユーザーやロールの過剰な権限削除 |
パフォーマンス | インスタンスのスケーリング | 過負荷のEC2インスタンスをアップグレードまたはAuto Scaling |
ㅤ | EBSボリュームのIOPS調整 | 過剰なIOPSを消費しているEBSボリュームのサイズ調整 |
耐障害性 | 冗長構成の推奨 | 単一AZに依存せず、複数AZにリソースを分散 |
サービス制限 | リソース制限アラート設定 | EC2インスタンスやElastic IPの制限に達する前にアラート設定 |
違い
特徴 | AWS Compute Optimizer | AWS Trusted Advisor |
主な目的 | リソースの最適化とコスト削減 | ベストプラクティスに基づく総合的なアドバイス |
対象リソース | EC2、Lambda、EBSなどの計算リソース | セキュリティ、コスト、パフォーマンス、信頼性 |
具体的な提案 | インスタンスサイズ、メモリ設定、リソースの変更 | コスト削減、セキュリティ改善、未使用リソースの削除 |
主な利用シーン | インスタンスのリソース最適化 | アカウント全体の運用ベストプラクティスの確認 |
まとめ:
- Compute Optimizer は、リソースの適正化に焦点を当て、コストを削減する提案を行います。
- Trusted Advisor は、AWS全体のベストプラクティスに基づき、セキュリティやコスト管理、パフォーマンス向上などの提案を行います。
実践
一問道場
質問 #54
ある企業は、Amazon S3で静的ウェブサイトとして新しいアプリケーションを運用しています。企業はアプリケーションを本番のAWSアカウントにデプロイし、Amazon CloudFrontを使用してウェブサイトを配信しています。ウェブサイトはAmazon API Gateway REST APIを呼び出しており、各APIメソッドはAWS Lambda関数がバックエンドを担当しています。
企業は、各Lambda関数の推奨されるメモリ設定、推奨コスト、および現在の設定と推奨設定との価格差を示すCSVレポートを2週間ごとに作成したいと考えています。企業はそのレポートをS3バケットに保存します。
最小限の開発時間でこの要件を満たすソリューションはどれですか？
- A. Lambda関数を作成し、Amazon CloudWatch Logsから各API Lambda関数のメトリクスデータを抽出して2週間の期間分を取得します。データを表形式で集計し、S3バケットに.csvファイルとして保存します。Amazon EventBridgeルールを作成してLambda関数を2週間ごとに実行するようにスケジュールします。
- B. AWS Compute Optimizerにオプトインします。Lambda関数を作成して
ExportLambdaFunctionRecommendations操作を呼び出し、CSVファイルをS3バケットにエクスポートします。Amazon EventBridgeルールを作成してLambda関数を2週間ごとに実行するようにスケジュールします。
- C. AWS Compute Optimizerにオプトインし、強化されたインフラストラクチャメトリクスを設定します。Compute Optimizerコンソールで、Lambdaの推奨設定をCSVファイルとしてエクスポートするジョブをスケジュールします。そのCSVファイルを2週間ごとにS3バケットに保存します。
- D. 本番アカウントにAWSビジネスサポートプランを購入し、AWS Compute OptimizerにオプトインしてAWS Trusted Advisorチェックを有効にします。Trusted Advisorコンソールで、コスト最適化チェックをCSVファイルとしてエクスポートするジョブをスケジュールします。そのCSVファイルを2週間ごとにS3バケットに保存します。
解説
この問題は、会社がAPI Lambda関数のメモリ設定の推奨設定、コスト、現在の設定との価格差を2週間ごとにCSVレポートとして生成し、そのレポートをS3バケットに保存する方法について尋ねています。
要件:
- API Lambda関数の推奨されるメモリ設定、コスト、価格差を含むレポートを作成。
- 2週間ごとにレポートを作成し、S3バケットに保存。
選択肢の解説:
A.
- Lambda関数を作成して、CloudWatch Logs からデータを取得し、CSV形式でS3に保存。
- 問題点: この方法では、Lambda関数の推奨設定や価格差を自動的に計算できません。Lambda関数の使用データを取得することはできますが、推奨されるメモリ設定やコストに関する情報を取得する機能は含まれていません。したがって、要件を満たすためには追加のロジックが必要です。
B.
- AWS Compute Optimizer を使用し、ExportLambdaFunctionRecommendations APIを呼び出して、推奨設定をCSVファイルとしてエクスポート。Lambda関数の推奨設定をS3に保存。
- 問題なし: AWS Compute Optimizerは、Lambda関数のメモリ設定推奨、コスト、最適化の提案を提供します。
ExportLambdaFunctionRecommendationsを利用して、推奨設定を自動的に取得し、CSVとして保存することができます。この方法が最も効率的で、最小限の開発で要件を満たすことができます。
C.
- Compute Optimizerコンソールで、Lambda推奨設定をCSVファイルにエクスポートし、2週間ごとにS3に保存。
- 問題点: AWS Compute OptimizerはLambda関数の推奨設定を提供しますが、Compute Optimizerコンソール内で自動的にCSVファイルにエクスポートする機能はありません。そのため、この選択肢は誤りです。手動でデータを取得し、CSVファイルに保存する必要があります。
D.
- AWS Business Supportプランを使用し、AWS Compute Optimizerを有効化。Trusted Advisorでコスト最適化チェックをCSVファイルにエクスポート。
- 問題点: Trusted Advisorはコスト最適化に関するアドバイスを提供しますが、Lambda関数の推奨設定に関する情報は提供しません。このため、この方法では問題を解決できません。
正解:
Bが最適です。AWS Compute Optimizerを利用して、Lambda関数のメモリ設定の推奨やコストを簡単にレポートとして生成できます。APIを使用してCSVにエクスポートし、S3に保存できます。
結論:
- AWS Compute Optimizerを使って、Lambda関数の推奨メモリ設定をエクスポートし、S3に保存する方法が最適です。
- A、C、Dは要件を満たすために追加の手順や方法が必要です。
055-配分タグ + Cost Categories
理論
AWSコスト配分タグとは
AWS コスト配分タグ とはAWSリソースのコストを詳細に追跡するためのタグです。どのタグをつけたリソースにいくらコストが掛かっているかの可視化に利用できます。
前提として、AWSにはリソースにメタデータを付与するための AWS リソースのタグ付けという機能が存在しますが、このタグ付け機能を元にコスト管理にも応用したものと考えられます。
AWS Cost Categories
AWS Cost Categoriesは、AWS Billing Dashboardの機能で、コストを任意のルールでグループ化し、自動的に分割表示します。これにより、特定のチームや部門ごとの利用料金を簡単に追跡できます。
主なポイント：
- コストのグルーピング：AWSアカウント、コスト配分タグ、料金タイプ、サービスなどでコストを分ける。
- 利用方法：Cost ExplorerやAWS Budgetのフィルタとして活用でき、特定のチームやアカウントのコスト分析に便利。
- 設定方法：管理アカウントでCost Categoriesを作成し、ルールを設定。例えば「開発部門A」と「開発部門B」、および「管理部門」に分けて、それぞれの部門に関連するコストを管理することができます。さらに、複数の部門が共通で使用する「Sandbox環境」などのリソースのコストを、それぞれの部門に按分（分けて割り当てる）することができます。
以下の表に、AWS Billing and Cost Managementの主なサービスとその内容、料金、コストカテゴリーを加えたものを整理しました：
項目 | 内容 | 料金 |
請求書 | 毎月の請求書や、使っているAWSサービスの詳細内訳が確認できる | 無料 |
請求ダッシュボード | 支出ステータスやコスト傾向などが確認できる | 無料 |
AWS Cost Explorer | コストと使用量を可視化し、把握・管理できる | 付属のユーザーインターフェイス使用時は無料、APIを使用したプログラムアクセスは有料 |
AWS Budgets | コストと使用量のカスタム予算を設定し、特定の条件でアラートを発信する | 使用自体は無料だが、３つめのカスタム予算から料金がかかる |
コストと使用状況レポート | コストと使用量に関する最も詳細なデータを参照できる | 無料 |
コストカテゴリー（Cost Categories） | 任意のルールでコストをグルーピングし、自動的に分割表示する機能 | 無料 |
コストカテゴリー（Cost Categories）は、AWSの請求情報を部門、プロジェクト、または他のグループに基づいて整理できる機能です。
実践
一問道場
問題 #55
ある会社の工場と自動化アプリケーションは単一のVPC内で動作しています。20以上のアプリケーションがAmazon EC2、Amazon Elastic Container Service (Amazon ECS)、およびAmazon RDSの組み合わせで実行されています。会社には3つのチームがソフトウェアエンジニアを配置しており、それぞれのチームがアプリケーションの1つを担当し、各チームはアプリケーションのコストとパフォーマンスに責任を負っています。チームリソースには、アプリケーションとチームを表すタグが付けられています。チームは日常的な活動にIAMアクセスを使用しています。
会社は、月々のAWS請求書のどのコストが各アプリケーションまたはチームに帰属するかを特定する必要があります。また、過去12ヶ月のコストを比較するレポートを作成できるようにし、今後12ヶ月のコスト予測を支援できるようにする必要があります。ソリューションアーキテクトは、このコストレポートを提供するためのAWS請求およびコスト管理ソリューションを推奨する必要があります。
どのアクションの組み合わせがこれらの要件を満たしますか？（3つ選んでください。）
- A. アプリケーションとチームを表すユーザー定義のコスト配分タグを有効にする。
- B. アプリケーションとチームを表すAWS生成のコスト配分タグを有効にする。
- C. 請求およびコスト管理で各アプリケーションのコストカテゴリを作成する。
- D. 請求およびコスト管理へのIAMアクセスを有効にする。
- E. コスト予算を作成する。
- F. コストエクスプローラーを有効にする。
解説
この質問では、会社がAWSのコストをアプリケーションやチーム別に追跡して、過去12ヶ月分のコストを分析したり、今後12ヶ月分の予測を立てたりする方法を求めています。これを達成するために、以下の3つのアクションが必要です：
1. ユーザー定義のコスト配分タグを有効にする（A）
- 会社のアプリケーションやチームごとにタグを設定します。このタグを使って、コストがどのアプリケーションやチームに属しているかを区別できるようにします。
- 例：各アプリケーションには「アプリ名」のタグを、チームには「チーム名」のタグを設定する。
2. コストカテゴリを作成する（C）
- AWS Billing and Cost Management で「コストカテゴリ」を設定します。これにより、特定のアプリケーションやチームごとのコストを整理しやすくなります。
- 例：アプリケーションごとにコストカテゴリを作成し、そのカテゴリに関連するコストをまとめる。
3. Cost Explorerを有効にする（F）
- Cost Explorer を使って、過去のコストデータを視覚的に確認できます。これにより、コストの傾向を分析したり、将来のコスト予測を立てたりできます。
- 例：Cost Explorerで12ヶ月のコストデータを表示して、どのアプリケーションやチームが最もコストを消費しているかを分析する。
まとめ：
これらの設定を行うことで、各アプリケーションやチームごとのコストを追跡し、詳細なレポートを作成できるようになります。コストの傾向を把握したり、将来のコストを予測したりするための有力なツールを提供します。
056-NATゲートウェイ
理論
1. VPCとサブネット
- VPC (Virtual Private Cloud) は、AWS上で独自のネットワーク環境を構築するためのサービスです。VPC内にはパブリックサブネットとプライベートサブネットを作成できます。
- パブリックサブネットには、インターネットと直接通信できるリソース（例：ALBやNATゲートウェイ）が配置されます。
- プライベートサブネットには、インターネットに直接接続できないリソース（例：EC2インスタンス）が配置され、インターネットアクセスはNATゲートウェイを介して提供されます。
2. NATゲートウェイとインターネットアクセス
- NATゲートウェイは、プライベートサブネットに配置されたインスタンスがインターネットにアクセスできるようにするためのサービスです。プライベートサブネット内のインスタンスから外部リソースにアクセスする際に、NATゲートウェイが公開IPアドレスを使って通信を行います。
- Elastic IP (EIP) は、静的なパブリックIPアドレスで、AWSリソースに割り当てることができます。EIPを使うことで、インターネット経由で外部と通信する際のIPアドレスを固定できます。
3. サードパーティAPIとの連携
- 一部のサードパーティAPIは、アクセス元IPアドレスを許可リストに登録することでセキュリティを強化しています。このようなAPIにアクセスする場合、IPアドレスが固定である必要があります。AWSでは、Elastic IPアドレスを使用することで、リソースに静的なIPを割り当てることができます。
4. AWS Global Accelerator（オプション）
- AWS Global Acceleratorは、AWSのネットワークインフラを利用して、アプリケーションのトラフィックを最適化するサービスです。グローバルなアプリケーションでのパフォーマンス向上や、特定のエンドポイントに対するトラフィックのルーティングを制御できます。Elastic IPを使って、Global Acceleratorを利用することも可能です。
まとめ
このように、AWSでのネットワーキングの基本的な設計を理解することで、VPC内での通信、インターネットアクセス、IPアドレス管理、そしてサードパーティAPIとのインタラクションにおける制約に対応する方法を学ぶことができます。
一問道場
質問 #56
あるAWS顧客がオンプレミスで実行されているWebアプリケーションを持っています。このWebアプリケーションは、ファイアウォールの背後にあるサードパーティAPIからデータを取得しています。サードパーティは、クライアントの許可リストに対して1つのパブリックCIDRブロックのみを受け入れます。顧客はWebアプリケーションをAWSクラウドに移行したいと考えています。アプリケーションは、VPC内のApplication Load Balancer(ALB)の背後にある複数のAmazon EC2インスタンスにホストされます。ALBはパブリックサブネットに配置され、EC2インスタンスはプライベートサブネットに配置されます。NATゲートウェイがプライベートサブネットにインターネットアクセスを提供します。
ソリューションアーキテクトは、移行後にWebアプリケーションがサードパーティAPIを引き続き呼び出すことができるようにするために、どのようにすべきでしょうか？
選択肢:
A. 顧客所有のパブリックIPアドレスブロックをVPCに関連付ける。VPCのパブリックサブネットでパブリックIPアドレッシングを有効にする。
B. 顧客所有のパブリックIPアドレスブロックをAWSアカウントに登録する。Elastic IPアドレスをそのアドレスブロックから作成し、VPC内のNATゲートウェイに割り当てる。
C. 顧客所有のパブリックIPアドレスブロックからElastic IPアドレスを作成し、静的Elastic IPアドレスをALBに割り当てる。
D. 顧客所有のパブリックIPアドレスブロックをAWSアカウントに登録する。AWS Global Acceleratorを設定し、そのアドレスブロックからElastic IPアドレスを使用する。ALBをアクセラレータエンドポイントとして設定する。
解説
答えはBです。
理由:
サードパーティAPIが受け入れるのは、1つのパブリックCIDRブロックだけで、そのIPアドレスからのリクエストのみを許可する場合、顧客が持っているパブリックIPアドレスをNATゲートウェイに割り当てる方法が適切です。これにより、プライベートサブネット内のEC2インスタンスがインターネットにアクセスする際に使用するIPアドレスが固定され、サードパーティAPIの許可リストにそのIPアドレスを追加できます。
Bの選択肢は、次の手順に従っています：
- 顧客所有のパブリックIPアドレスブロックをAWSアカウントに登録する。
- そのアドレスブロックからElastic IPアドレスを作成。
- そのElastic IPアドレスをVPC内のNATゲートウェイに割り当てる。
これにより、サードパーティAPIはこの特定のIPアドレスからのみリクエストを受け付けることができるようになります。
057-SCP+IAM
理論
サービスコントロールポリシー（SCP）の基本知識
- 概要
SCPはAWS Organizationsで使用されるポリシーで、組織内のアカウントで許可または拒否されるアクションを制御します。IAMポリシーのように動作しますが、アカウント全体に適用され、IAMユーザーやロールのポリシーではオーバーライドできません。
- 効果
- Allow（許可）: 明示的にアクションを許可します。
- Deny（拒否）: 明示的にアクションを拒否します。DenyはAllowより優先されます。
- デフォルトの動作
SCPを適用していない場合、AWSはすべてのサービスとアクションを許可します。ただし、SCPでDenyが設定されている場合、そのアクションは実行できません。
- リソーススコープ
SCPは組織単位（OU）または特定のアカウントにアタッチできます。SCP内のリソースやアクションは特定のサービスに限定できます。
- 設定上の注意点
- Allowのみを指定するSCP: アクションが明示的に許可されない限り、アカウント内で利用できません。
- Denyを含むSCP: 対象のアクションは無条件で拒否されます。特にDenyの範囲が広い場合、重要なサービスの利用が制限される可能性があります。
- トラブルシューティング SCPが原因で期待するアクションが実行できない場合、以下を確認します:
- SCPが必要なアクションを許可しているか。
- SCPにDenyが設定されている場合、影響範囲が過剰でないか。
- IAMポリシーとSCPの組み合わせによる制限。
- ベストプラクティス
- 必要最小限の許可（最小権限の原則）に基づいてSCPを設計する。
- 重要な操作を明示的にAllowする。
- テスト環境で適用を試し、問題がないことを確認する。
SCPはAWS環境のセキュリティとコンプライアンスを強化する強力なツールですが、設定ミスによる運用トラブルを防ぐために慎重な設計が必要です。
一問道場
質問 #57
複数のAWSアカウントを持つ企業が、AWS Organizationsとサービスコントロールポリシー（SCP）を使用しています。管理者が以下のSCPを作成し、AWSアカウント 1111-1111-1111 を含む組織単位（OU）にアタッチしました：
アカウント 1111-1111-1111 で作業している開発者たちが、「Amazon S3バケットを作成できない」と不満を訴えています。この問題を管理者はどのように対処すべきですか？
選択肢:
A. SCPに「Effect: Allow」で
s3:CreateBucketを追加する。B. アカウントをOUから削除し、SCPをアカウント 1111-1111-1111 に直接アタッチする。
C. 開発者に、Amazon S3の権限を自分のIAMエンティティに追加するよう指示する。
D. SCPをアカウント 1111-1111-1111 から削除する。
058-EBSとS3間でデータ
理論
AWS EBSとS3間でデータを移行するための基礎知識
- Amazon EBSとスナップショット
- Amazon Elastic Block Store (EBS) ボリュームは、インスタンスのストレージとして使用され、データの保存やバックアップが可能です。
- スナップショットを作成すると、ボリューム全体のデータが保存されます。スナップショットは暗号化を維持し、後で新しいボリュームや他のリージョンで復元するために使用されます。しかし、一時的にI/Oが中断
- Amazon S3とデータバックアップ
- Amazon Simple Storage Service (S3) は、オブジェクトストレージサービスで、スナップショットや他のデータを保存するための柔軟で耐久性のある選択肢です。
- データのバックアップやアーカイブに最適であり、アクセス制御や暗号化を簡単に設定できます。
- AWS Systems Manager Session Manager
- SSH キーが不要で、安全に EC2 インスタンスにアクセスできるツール。
- インスタンスに IAM ロールをアタッチし、S3 への書き込み権限を持たせることで、コマンドを実行してデータを移動できます。
- IAM ロールと権限管理
- インスタンスに IAM ロールをアタッチすることで、特定の AWS サービス（例: S3 へのアクセス）を利用する権限を付与します。これにより、セキュリティが向上し、キー管理が不要になります。
- 稼働中のアプリケーションのデータ移行
- アプリケーションが停止できない場合、ランタイム中に安全かつ効率的にデータをコピーする必要があります。Session Manager や IAM ロールを使用すれば、停止時間をゼロに抑えることが可能です。
これらの技術とサービスを適切に組み合わせることで、安全で効率的なデータ移行が実現します。
一問道場
質問 #58
ある企業は、ビジネスにとって重要なモノリシックアプリケーションを保有しています。このアプリケーションは、Amazon Linux 2 を実行している Amazon EC2 インスタンス上でホストされています。
企業のアプリケーションチームは、法務部門からインスタンスの暗号化された Amazon Elastic Block Store (Amazon EBS) ボリュームのデータを Amazon S3 バケットにバックアップするよう指示を受けました。
ただし、アプリケーションチームはインスタンスにアクセスするための管理用 SSH キーペアを持っていません。アプリケーションは引き続きユーザーにサービスを提供し続ける必要があります。
この要件を満たすためのソリューションはどれですか？
A.
インスタンスに Amazon S3 への書き込み権限を持つロールをアタッチします。AWS Systems Manager Session Manager オプションを使用してインスタンスにアクセスし、データを Amazon S3 にコピーするコマンドを実行します。
B.
再起動オプションを無効にした状態でインスタンスのイメージを作成します。そのイメージから新しい EC2 インスタンスを起動し、Amazon S3 への書き込み権限を持つロールを新しいインスタンスにアタッチします。データを Amazon S3 にコピーするコマンドを実行します。
C.
Amazon Data Lifecycle Manager (Amazon DLM) を使用して EBS ボリュームのスナップショットを作成します。そのデータを Amazon S3 にコピーします。
D.
インスタンスのイメージを作成します。そのイメージから新しい EC2 インスタンスを起動し、Amazon S3 への書き込み権限を持つロールを新しいインスタンスにアタッチします。データを Amazon S3 にコピーするコマンドを実行します。
解説
問題の要点：
- アプリケーションの稼働を停止せずに、暗号化されたEBSボリュームのデータをAmazon S3にバックアップする必要がある。
- 管理者のSSHキーはない。
選択肢ごとの評価：
- A. AWS Systems Manager Session Managerを使用してアクセスし、コマンドでデータをS3にコピー
- 適切な選択肢です。
- Session Managerを使用することで、SSHキーなしでインスタンスにアクセスできます。
- インスタンスの稼働状態を維持したまま、データをコピーできるため、アプリケーションを停止せずにバックアップが可能です。
- B. インスタンスのAMIを作成し、新しいインスタンスを起動してデータをコピー
- インスタンスを再起動して新しいインスタンスを起動するため、アプリケーションのダウンタイムが発生する可能性があります。
- SSHキーがないため、インスタンスにアクセスする方法としては不十分です。
- C. Amazon Data Lifecycle Managerを使用してEBSスナップショットを取得し、その後S3にコピー
- EBSスナップショットはブロックレベルのバックアップであり、直接S3にコピーすることはできません。
- スナップショットを取得すると、一時的にI/Oが中断され、アプリケーションの稼働要件に合致しません。
- D. インスタンスのAMIを作成し、新しいインスタンスを起動してデータをコピー（選択肢Bの繰り返し）
- 選択肢Bと同じ問題があります。
- ダウンタイムが発生し、SSHキーなしでアクセスできないため不適切です。
結論：
最適な解決策は A です。Session Managerを使ってインスタンスにアクセスし、アプリケーションを停止させることなく、データをS3にコピーすることができます。
059-aws s3 sync
理論
Amazon S3で異なるAWSアカウント間でデータをコピーするには、アクセス許可の設定が重要です。具体的には、ソースバケットとデスティネーションバケットの両方で適切なポリシーを構成する必要があります。これには、S3バケットポリシーやIAMポリシーを使用して、オブジェクトの読み取りや書き込み、ACL（アクセス制御リスト）の設定を行います。
バケットポリシー:
- バケットポリシーは、特定のバケットに対するアクセス権を定義するもので、特にS3バケット間でデータをコピーする際に必要です。例えば、ソースバケットのオブジェクトを読み取るアクセス権や、デスティネーションバケットにオブジェクトを配置するアクセス権を付与します。
IAMポリシー:
- IAMポリシーは、AWSのリソースに対するアクセス権をユーザーやロールに付与するために使用されます。ユーザーがソースバケットからデータを読み取り、デスティネーションバケットにデータを書き込むためには、適切なIAMポリシーが必要です。
aws s3 syncコマンド:
aws s3 syncコマンドは、AWS CLIを使用してS3バケット間でデータを同期するためのツールです。このコマンドを使用することで、指定されたソースバケットとデスティネーションバケット間で効率的にデータをコピーできます。
手順
- ソースバケットのアクセス権限を設定
- ソースバケットにバケットポリシーを作成し、デスティネーションアカウントのユーザーに対してソースバケットの内容をリスト表示し、オブジェクトを読み取る権限を付与します。
- デスティネーションバケットのアクセス権限を設定
- デスティネーションアカウントのユーザーに対して、デスティネーションバケットにオブジェクトを配置し、オブジェクトのACLを設定する権限を付与します。
aws s3 syncコマンドを実行- デスティネーションアカウントのユーザーとして、
aws s3 syncコマンドを使用して、ソースバケットからデータをデスティネーションバケットにコピーします。
一問道場
質問 #59
ソリューションアーキテクトは、あるAWSアカウントのAmazon S3バケットから、新しいAWSアカウントの新しいS3バケットにデータをコピーする必要があります。このプロセスには、AWS CLIを使用したソリューションが求められています。
以下のステップのうち、データを正しくコピーするためにはどの組み合わせが必要ですか？（3つ選んでください）
A.
ソースバケットに対して、以下のアクセスを許可するバケットポリシーを作成し、デスティネーションバケットに適用します：
- ソースバケットの内容をリスト表示すること
- オブジェクトをデスティネーションバケットに配置すること
- オブジェクトのACL（アクセス制御リスト）を設定すること
B.
デスティネーションアカウントのユーザーに対して、ソースバケットの内容をリストし、オブジェクトを読み取ることを許可するバケットポリシーを作成し、そのポリシーをソースバケットに適用します。
C.
ソースアカウントにIAMポリシーを作成し、ソースバケットからオブジェクトを取得するためのリスト表示および読み取り権限と、デスティネーションバケットに対する書き込み権限を付与します。このポリシーをユーザーに適用します。
D.
デスティネーションアカウントにIAMポリシーを作成し、デスティネーションアカウントのユーザーがソースバケットの内容をリストし、オブジェクトを取得する権限と、デスティネーションバケットへの書き込み権限を付与します。
E.
ソースアカウントのユーザーとして
aws s3 sync コマンドを使用し、ソースバケットからデスティネーションバケットへデータをコピーします。F.
デスティネーションアカウントのユーザーとして
aws s3 sync コマンドを使用し、ソースバケットからデスティネーションバケットへデータをコピーします。解説
この問題は、AWS CLIを使用して異なるAWSアカウント間でS3バケットからデータをコピーする方法に関するものです。要件を満たすためには、適切なアクセス権限を設定し、コピー操作を実行するための適切な手順を踏む必要があります。
以下に解説します。
選択肢の解説：
- A. ソースバケットにバケットポリシーを作成し、デスティネーションバケットにアタッチ
- 誤り: この選択肢では、ソースバケットに設定するポリシーが不完全です。ソースバケットに設定するポリシーは、ソースバケットからデータを読み取ることができるようにするためのものであり、デスティネーションバケットへの書き込みを許可するポリシーはデスティネーションバケット側に設定する必要があります。
- B. デスティネーションアカウントのユーザーにソースバケットの内容をリストし、オブジェクトを読み取ることを許可するバケットポリシーをソースバケットに適用
- 正解: ソースバケットにバケットポリシーを作成し、デスティネーションアカウントのユーザーに対してソースバケットのリスト表示とオブジェクトの読み取り権限を付与します。この設定は、デスティネーションアカウントがソースバケットのデータを取得できるようにするために必要です。
- C. ソースアカウントにIAMポリシーを作成し、ユーザーに対して必要なアクセス権限を付与
- 正解: ソースアカウントのユーザーに対して、ソースバケットからデータをリスト表示および取得する権限と、デスティネーションバケットへのデータ書き込みを許可する権限を付与するIAMポリシーを作成します。これにより、データの転送が可能になります。
- D. デスティネーションアカウントにIAMポリシーを作成し、ユーザーに必要なアクセス権限を付与
- 正解: デスティネーションアカウントのユーザーがソースバケットからデータをリストし、取得する権限と、デスティネーションバケットへの書き込み権限を付与するIAMポリシーを作成します。これにより、データ転送が実行できます。
- E. ソースアカウントのユーザーとして
aws s3 syncコマンドを実行 - 誤り: ソースアカウントのユーザーが直接データをコピーする場合、その権限がないとコピーは実行できません。ソースバケットとデスティネーションバケット両方に適切なアクセス権限が必要です。
- F. デスティネーションアカウントのユーザーとして
aws s3 syncコマンドを実行 - 正解: デスティネーションアカウントのユーザーが
aws s3 syncコマンドを使用してデータをコピーします。このコマンドは、ソースバケットとデスティネーションバケット間でデータを同期させるために使用されますが、ユーザーが必要な権限を持っている必要があります。
まとめ
データコピーには、ソースバケットからのデータ取得とデスティネーションバケットへの書き込みのための適切なアクセス権限が必要です。正しい組み合わせは、アクセス権限を設定するためにバケットポリシーとIAMポリシーを適切に使用し、
aws s3 sync コマンドを実行することで、データを正しくコピーできます。060-Lambdaのカナリアリリース
理論
カナリアリリース（Canary Release）とは、新しいソフトウェアのバージョンや機能を、少数のユーザーやリソースに対して段階的にリリースする手法です。名前の由来は、かつて炭鉱で危険を察知するためにカナリアを使っていたことから、新しいバージョンを少数のユーザーに対して試すことで問題を早期に発見し、リスクを最小限に抑えるという意味です。
カナリアリリースの特徴
- 段階的な展開
最初は少数のユーザーやトラフィックに対して新しいバージョンをデプロイし、その後、問題がないことが確認されれば、段階的に対象ユーザーやトラフィックを増やしていきます。
- 早期の問題発見
小規模にデプロイするため、問題が発生しても影響範囲を抑えることができます。また、問題が発生した場合はすぐにロールバックが可能です。
- リスク管理
新しいリリースの安定性を確認しながら本番環境に反映させるため、完全なリリースよりもリスクを低減できます。
使用例
- Lambda関数のバージョン管理：AWS Lambda では、バージョン管理とエイリアス機能を使用して、トラフィックを段階的に新しいバージョンに切り替えることができます。例えば、最初に 1% のトラフィックを新しいバージョンに流し、問題がないことが確認されたら残りの 99% にも適用します。
メリット
- 安定性の向上：新しいコードが完全に展開される前に問題を発見できるため、全体のシステムの安定性を保ちやすい。
- リスク最小化：問題が発生した場合の影響を小さく保ちながら、迅速に対応可能です。
デメリット
- 管理が複雑：段階的なリリースを管理するための追加の手順やツールが必要となる場合があります。
- パフォーマンスの問題：カナリアリリース中はトラフィックが分割されるため、処理能力に影響を与えることがあります。
カナリアリリースは、特にミッションクリティカルなシステムや大規模なユーザー基盤を持つアプリケーションにおいて、新しい機能を安全にリリースするために広く使用されています。
一問道場
質問 #60
ある企業は、AWS Lambdaを使用して構築したアプリケーションをAWS CloudFormationスタックでデプロイしています。ウェブアプリケーションの最新の本番リリースで、数分間の障害が発生する問題が発生しました。ソリューションアーキテクトは、カナリアリリースをサポートするようにデプロイメントプロセスを調整する必要があります。
どのソリューションがこの要件を満たしますか？
A.
新しくデプロイされたLambda関数のバージョンごとにエイリアスを作成します。AWS CLIの
update-aliasコマンドを使用し、routing-configパラメータで負荷分散を行います。B.
アプリケーションを新しいCloudFormationスタックにデプロイし、Amazon Route 53の重み付けルーティングポリシーを使用して負荷を分散します。
C.
新しくデプロイされたLambda関数のバージョンごとにバージョンを作成します。AWS CLIの
update-function-configurationコマンドを使用し、routing-configパラメータで負荷分散を行います。D.
AWS CodeDeployを設定し、
CodeDeployDefault.OneAtATimeというデプロイメント構成を使用して負荷分散を行います。解説
この質問では、カナリアリリース（Canary Release）をサポートするデプロイメントプロセスを求めています。カナリアリリースとは、アプリケーションの新バージョンを少数のユーザーに段階的に提供し、問題がないことを確認してから全ユーザーに展開する手法です。
要件を満たす条件
- 段階的リリース: デプロイメントが段階的に行われ、影響を最小限に抑える。
- 負荷分散: トラフィックを新旧バージョンの間で分割できる。
- 自動化: AWSのネイティブサービスを活用してデプロイメントを効率化。
選択肢の分析
A.
- 構成:
- Lambda関数の各バージョンに対してエイリアスを作成。
- AWS CLI の
update-aliasコマンドを使用し、routing-configパラメータで新旧バージョンへのトラフィック比率を制御。
- 評価:
この方法はカナリアリリースをサポートする設定として適切です。
routing-configを使用することで、トラフィックの割合を動的に調整し、新バージョンのリリースを段階的に進められます。- 結論: 正解の可能性が高い。
B.
- 構成:
- 新しいLambda関数バージョンを別のCloudFormationスタックでデプロイ。
- Route 53の重み付けルーティングを使用して負荷を分散。
- 評価:
Route 53の重み付けルーティングは、ドメイン名のDNSレベルでトラフィックを制御する方法です。ただし、Lambdaのバージョンを切り替える目的には適しておらず、Lambda関数自体の管理が複雑になります。
- 結論: 不適切。
C.
- 構成:
- 各Lambda関数バージョンを作成。
- AWS CLIの
update-function-configurationコマンドでrouting-configを使用してトラフィックを分散。
- 評価:
update-function-configuration は関数の設定を更新するコマンドであり、トラフィックの制御を直接行うものではありません。この方法は要件を満たしません。- 結論: 不適切。
D.
- 構成:
- AWS CodeDeployを設定。
CodeDeployDefault.OneAtATimeというデプロイ構成を使用。
- 評価:
CodeDeployの設定はLambda関数のデプロイを高度に管理するために適していますが、
CodeDeployDefault.OneAtATimeはインプレースデプロイメントであり、トラフィックの分割を段階的に制御するカナリアリリースとは異なります。カナリアリリースを行う場合は、CodeDeployの「カナリアデプロイ」設定（例: Canary10PercentXMinutes）を使用する必要があります。- 結論: 不適切。
正解: A
AWS CLIのupdate-aliasコマンドとrouting-configパラメータを使用する方法は、Lambda関数におけるカナリアリリースを実現するための適切なソリューションです。これにより、新バージョンへのトラフィックを段階的に増やしながらリリースを進められます。- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/169d7ae8-88e2-80c3-a763-d555e1b66f4c
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
