type
status
date
slug
summary
tags
category
icon
password
书籍
081-S3 Transfer Acceleration
理論
S3 Transfer Accelerationの概要
- 目的：S3へのデータ転送を高速化するサービス。特に、送信元がS3バケットのあるリージョンから遠く離れている場合に効果的。
- 使用方法：
- S3バケットのプロパティから「Transfer Acceleration」を有効化。
- その後、転送アクセラレーション署名付きURLを使ってデータをアップロード。
ユースケース
- 世界中からデータをアップロードする場合：大陸間でのデータ転送や、海外から日本のS3バケットにデータをアップロードする場合に効果的。
- 大規模なデータ転送：定期的にGB〜TB規模のデータを転送する場合。
費用
- アップロード1GBあたり、$0.04の追加料金が発生。
CloudFrontとの関連
- CloudFrontは静的コンテンツの配信に使用され、S3 Transfer AccelerationはS3へのアップロードの高速化に役立つ。用途が異なるが、組み合わせて使う場合もある。
結論
- S3 Transfer Accelerationは、特に遠距離からのS3へのアップロードを迅速にするためのサービスです。
エッジ最適化APIエンドポイント
以下の表に、エッジ最適化APIエンドポイント、リージョンAPIエンドポイント、プライベートAPIエンドポイントの違いを整理しました。
エンドポイントタイプ | 説明 | 利用シーン |
エッジ最適化APIエンドポイント | CloudFrontを利用して、低遅延でグローバルに配信 | グローバルなユーザーに対する高速レスポンスが必要な場合 |
リージョンAPIエンドポイント | 特定リージョン内でAPIをホストし、そのリージョンへのリクエスト処理 | 特定リージョン向けのサービスに使用 |
プライベートAPIエンドポイント | VPC内でAPIをホストし、インターネットからのアクセスを制限 | セキュアな内部アクセスが必要な場合 |
一問道場
質問 #81
ある企業が電子文書管理システムを構築しています。このシステムでは、ユーザーが自身の文書をアップロードします。アプリケーションスタックは完全にサーバーレスで、AWSのeu-central-1リージョンで稼働しています。このシステムには、Amazon S3をオリジンとして使用するAmazon CloudFrontディストリビューションで配信されるウェブアプリケーションが含まれています。ウェブアプリケーションはAmazon API Gatewayのリージョナルエンドポイントと通信します。API GatewayのAPIはAWS Lambda関数を呼び出し、Lambda関数はAmazon Aurora Serverlessデータベースにメタデータを保存し、文書をS3バケットに格納します。
企業は順調に成長しており、最大顧客との概念実証（PoC）を完了しました。この企業は、ヨーロッパ以外での遅延を改善する必要があります。
この要件を満たすアクションの組み合わせはどれですか？（2つ選択してください）
選択肢：
A. S3バケットでS3転送アクセラレーションを有効化する。ウェブアプリケーションが転送アクセラレーション署名付きURLを使用するようにする。
B. AWS Global Acceleratorでアクセラレーターを作成し、そのアクセラレーターをCloudFrontディストリビューションにアタッチする。
C. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変更する。
D. 世界中に分散した他の2か所でスタック全体をプロビジョニングする。Aurora Serverlessクラスターでグローバルデータベースを使用する。
E. Lambda関数とAurora Serverlessデータベースの間にAmazon RDSプロキシを追加する。
解説
問題の要点
- 主に「ヨーロッパ以外での遅延を改善する」ことが求められています。
- S3に保存される文書と、それに関連するAPIとLambda、Aurora Serverlessの連携があります。
選択肢の再評価
A. S3バケットでS3転送アクセラレーションを有効化する。ウェブアプリケーションが転送アクセラレーション署名付きURLを使用するようにする。
- S3転送アクセラレーションは、S3バケットへのデータ転送を最適化する方法で、特に遠隔地のユーザーからのアップロードを高速化できます。
- これにより、ユーザーがアップロードする際の遅延を改善できます。ヨーロッパ以外の地域でのアップロードの遅延を減少させるために有効です。
- この選択肢は、S3へのアップロード時の遅延改善に貢献します。
- 結論：適切です。
C. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変更する。
- API Gatewayのエッジ最適化エンドポイントを使用すると、APIへのリクエストが最寄りのCloudFrontエッジロケーションを通じてルーティングされ、アクセスの遅延を削減します。
- これにより、特にヨーロッパ以外の地域からのAPI呼び出しの遅延を改善できます。
- 結論：適切です。
B. AWS Global Acceleratorでアクセラレーターを作成し、そのアクセラレーターをCloudFrontディストリビューションにアタッチする。
- AWS Global Acceleratorは、主にネットワークレベルでのパフォーマンス向上を目的としていますが、ここでの遅延改善は主にAPI呼び出しやS3アップロードに関連する部分であり、Global Acceleratorは適用範囲外です。
- CloudFront自体がすでに遅延改善のために使用されており、Global Acceleratorは追加の効果を発揮しにくいです。
- 結論：不適切です。
D. 世界中に分散した他の2か所でスタック全体をプロビジョニングする。Aurora Serverlessクラスターでグローバルデータベースを使用する。
- グローバルデータベースの使用は、遅延改善には有効ですが、ここでは主にS3アップロードとAPI遅延が問題となっており、Auroraのグローバルデータベースは遅延改善には直接関係しません。
- スタック全体を分散することは非常にコストと手間がかかるため、最適解ではありません。
- 結論：不適切です。
E. Lambda関数とAurora Serverlessデータベースの間にAmazon RDSプロキシを追加する。
- RDSプロキシは、データベース接続の効率化を目的としており、遅延改善には寄与しません。特にS3アップロードやAPIの遅延改善には関連性がありません。
- 結論：不適切です。
正解：A と C
- A. S3バケットでS3転送アクセラレーションを有効化する。ウェブアプリケーションが転送アクセラレーション署名付きURLを使用するようにする。
- ユーザーがアップロードする際の遅延を改善。
- C. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変更する。
- APIの遅延を改善するために、最寄りのCloudFrontエッジロケーションを利用。
解説
- S3転送アクセラレーションとAPI Gatewayのエッジ最適化エンドポイントの両方を使用することで、ユーザーがどの地域にいても遅延を最小化できます。
- AはS3へのアップロードの遅延を改善し、
- CはAPI呼び出しの遅延を改善します。
082-S3のストレージクラス
理論
- S3のストレージクラスとコスト最適化:
- S3 Standard: 頻繁にアクセスされるデータ向け。高いアクセス性能を提供するが、コストは比較的高い。
- S3 Intelligent-Tiering: データアクセス頻度に基づいて自動的にストレージクラスを変更することで、コストを最適化。頻繁にアクセスされるデータは「S3 Standard」、アクセス頻度が低いデータは「S3 IA（Infrequent Access）」や「S3 One Zone-IA」へ移行。
- S3 GlacierおよびS3 Glacier Deep Archive: 長期間アクセスされないアーカイブデータ向けの低コストストレージ。ミリ秒単位のアクセスが必要な場合には不向き。
- S3ライフサイクルポリシー:
- 定期的にデータを異なるストレージクラスに移行する自動化ルールを設定でき、データが一定期間使用されていない場合にコストを削減できます。
- CloudFrontキャッシュの最適化:
- CloudFrontはCDN（コンテンツ配信ネットワーク）として機能し、S3バケットから静的コンテンツ（画像、動画など）を高速で配信する。キャッシュを適切に設定することで、繰り返しアクセスされるデータに対してパフォーマンスを向上させる。
- アクセスパターンの理解:
- データが頻繁にアクセスされる場合と、長期間アクセスされない場合に分けて適切なストレージクラスを選択することで、コストを最小限に抑えることができる。
まとめ:
アクセス頻度に基づいたストレージクラスの選択と、ライフサイクルポリシーやCloudFrontキャッシュの設定が、AWSのコスト最適化とパフォーマンス向上のカギとなります。
一問道場
問題 #82
あるアウトドア活動を提供する会社がモバイルアプリに新しい機能を追加しました。この機能を使って、ユーザーはハイキングやラフティングの写真やビデオをいつでもアップロードできるようになっています。これらの写真やビデオは、Amazon S3 Standardストレージに保存され、Amazon CloudFrontを通じて配信されます。会社はストレージコストを最適化する必要があります。ソリューションアーキテクトが調査したところ、アップロードされた写真やビデオのほとんどは30日後にはほとんどアクセスされなくなりますが、一部は30日後も頻繁にアクセスされることがわかりました。ソリューションアーキテクトは、最低コストでミリ秒単位の迅速なアクセスを維持する方法を実装する必要があります。
どのソリューションがこの要件を満たしますか？
A. S3バケットにS3 Intelligent-Tieringを設定する。
B. S3ライフサイクルポリシーを設定し、30日後に画像オブジェクトとビデオオブジェクトをS3 Glacier Deep Archiveに移行する。
C. Amazon EC2インスタンスにマウントされたAmazon Elastic File System (Amazon EFS)ファイルシステムにAmazon S3を置き換える。
D. S3画像オブジェクトとS3ビデオオブジェクトにCache-Control:max-ageヘッダーを追加し、ヘッダーを30日間に設定する。
解説
この問題では、30日後にほとんどアクセスされなくなる写真やビデオのストレージコストを最適化し、迅速なアクセスを維持する方法を求めています。
最適な解答は A. S3 Intelligent-Tieringを設定するです。
- 理由: S3 Intelligent-Tieringは、アクセス頻度に基づいて自動的にデータを低コストのストレージクラスに移行し、コスト最適化しながらも必要な時に迅速にアクセス可能です。
他の選択肢の説明:
- B: Glacier Deep Archiveは低コストだが、ミリ秒単位のアクセスが必要な場合には不適切。
- C: EFSはコストが高く、S3とCloudFrontの使用には適さない。
- D: Cache-Controlはキャッシュ管理に関する設定で、ストレージコストの最適化には関係ない。
結論: S3 Intelligent-Tieringを使用することで、コストを抑えながら迅速なアクセスが可能になります。
083-S3 Storage Class Analysis
理論
S3ストレージクラスの最適化とコスト削減
Amazon S3では、データのアクセス頻度に応じて複数のストレージクラスを選択することができます。適切なストレージクラスを選択することで、コストを最適化できます。
1. S3のストレージクラス
- S3 Standard: 頻繁にアクセスされるデータに適しており、最も高価ですが、ミリ秒単位でアクセス可能です。
- S3 Intelligent-Tiering: アクセスパターンを自動で分析し、最適なストレージクラスにデータを移動します。これによりコスト削減が可能です。
- S3 Glacier / S3 Glacier Deep Archive: アーカイブデータに適したクラスで、非常に低コストですが、リトリーブに数分から数時間かかることがあります。
- S3 Standard-IA (Infrequent Access): 頻繁にアクセスされないが、迅速にアクセスする必要があるデータ向けです。コストはStandardより低いですが、アクセス時に料金がかかります。
2. S3ストレージクラス分析
- S3 Storage Lens は、S3の利用状況、アクセスパターン、コストのトレンドを視覚化するツールで、データの最適化をサポートします。
- S3 Storage Class Analysis は、どのオブジェクトが頻繁にアクセスされ、どのオブジェクトが稀にしかアクセスされないかを分析するために使用されます。これにより、適切なストレージクラスへの移行が可能となります。
以下のように簡潔に整理しました：
特徴 | S3 Storage Lens | S3 Storage Class Analysis |
分析単位 | バケット単位 | オブジェクト単位 |
目的 | バケット全体の使用状況とコスト分析 | オブジェクトのアクセスパターンに基づくストレージクラスの最適化 |
提供する情報 | ストレージコスト、トレンドなど | アクセス頻度に基づくストレージクラス提案 |
S3 Storage Lensはバケット全体の分析、S3 Storage Class Analysisはオブジェクトのアクセスパターンに基づく最適化を行います。
3. コスト削減のための戦略
- データのアクセス頻度を監視し、適切なストレージクラスに移動することで、ストレージコストを削減できます。
- ライフサイクルポリシー: 定期的にアクセスされないデータを低コストのストレージクラス（GlacierやDeep Archive）に移行する自動化の設定が可能です。
4. ストレージの最適化ツール
- S3 Storage Lens や S3 Intelligent-Tiering を使用することで、アクセス頻度に基づいたストレージクラスの最適化をリアルタイムで実現できます。
- ライフサイクル管理: 期間に基づいてデータを適切なストレージクラスに移動させるポリシー設定が可能です。
これらのツールと戦略を駆使することで、Amazon S3のコストを効果的に削減し、データのアクセス頻度に基づいた最適なストレージ管理が可能になります。
一問道場
質問 #83
ある企業は、さまざまなストレージクラスでファイルや画像をAmazon S3に保存しています。過去1年間でS3のコストが大幅に増加しました。
ソリューションアーキテクトは、過去12か月間のデータの傾向を確認し、オブジェクトに適切なストレージクラスを特定する必要があります。
どのソリューションがこの要件を満たしますか？
A. 過去12か月分のS3使用状況についてAWSコストおよび使用状況レポートをダウンロードし、コスト削減のためのAWS Trusted Advisorの推奨事項を確認する。
B. S3ストレージクラス分析を使用し、データの傾向をAmazon QuickSightダッシュボードにインポートしてストレージ傾向を分析する。
C. Amazon S3 Storage Lensを使用し、デフォルトのダッシュボードをアップグレードしてストレージ傾向の詳細なメトリクスを含める。
D. S3のアクセスアナライザーを使用し、過去12か月分のS3レポートをダウンロードして、.csvファイルをAmazon QuickSightダッシュボードにインポートする。
解説
この問題では、過去12か月間のデータ傾向を分析して、S3オブジェクトに最適なストレージクラスを特定する方法を問うています。
各選択肢を解説します。
A. AWSコストおよび使用状況レポートをダウンロードし、AWS Trusted Advisorの推奨事項を確認する。
- 誤り: AWSコストと使用状況レポートはコスト管理には有用ですが、ストレージクラスを最適化するための詳細なアクセス傾向やオブジェクトレベルのデータを提供しません。AWS Trusted Advisorは主に全体的な最適化提案を行うツールであり、ストレージクラスの最適化には直接関連しません。
B. S3ストレージクラス分析を使用し、データの傾向をAmazon QuickSightダッシュボードにインポートしてストレージ傾向を分析する。
- 正解: S3ストレージクラス分析は、オブジェクト単位でアクセス傾向を追跡し、どのオブジェクトが低頻度アクセスやアーカイブに適しているかを特定するのに役立ちます。このデータをQuickSightダッシュボードにインポートして、詳細に分析することができます。これにより、適切なストレージクラスへの移行を計画できます。
C. Amazon S3 Storage Lensを使用し、デフォルトのダッシュボードをアップグレードしてストレージ傾向の詳細なメトリクスを含める。
- 誤り: S3 Storage Lensはバケット単位でストレージの使用状況を可視化しますが、ストレージクラスの最適化には特化していません。詳細なストレージクラス分析を行うためには、S3ストレージクラス分析が適切です。
D. S3のアクセスアナライザーを使用し、過去12か月分のS3レポートをダウンロードして、.csvファイルをAmazon QuickSightダッシュボードにインポートする。
- 誤り: S3アクセスアナライザーは、S3バケットへのアクセス権限の監査に使用され、ストレージクラスの最適化には関連しません。このツールはデータのアクセス傾向を分析するものではなく、アクセス権限の確認を目的としています。
結論
最適なソリューションは B です。S3ストレージクラス分析を使用することで、データの傾向を詳細に分析し、適切なストレージクラスを選定することができます。
084-StackSets
理論
AWS Control Tower は、複数のAWSアカウントをまとめて管理できるツールです。特に、企業が複数のクラウド環境を一貫して安全に管理するために使われます。
具体的には、以下のことができます：
- 複数アカウントの一元管理: AWSで複数のアカウントを持っている場合、それらを一括で管理するための基本的な設定を自動で行ってくれます。
- セキュリティとコンプライアンスのガイドライン設定: 企業が守るべきセキュリティルールや規則を簡単に設定し、それを全てのアカウントに適用します。これにより、安心して運用できます。
- 管理作業の簡素化: AWSの設定やポリシーを手動で行う必要がなく、全体の管理が簡単になります。
つまり、AWS Control Towerは、複数のAWSアカウントを効率的に、安全に管理できる仕組みを提供するサービスです。
CloudFormation StackSets は、複数のAWSアカウントやリージョンにまたがるインフラを一貫して管理できる機能です。これを使うと、1つのテンプレートで定義したインフラを、複数の場所に同時にデプロイできます。
具体的には、以下のようなことが可能です：
- 複数アカウント/リージョンへのデプロイ: 1つのCloudFormationテンプレートを使って、異なるアカウントやリージョンにリソースを一括でデプロイできます。
- 管理の簡素化: 複数の環境にインフラをデプロイし、同じテンプレートを使って一貫した管理を行うことができます。これにより、管理が統一され、エラーが減ります。
- 更新と変更の一括適用: インフラの変更があった場合、StackSetsを使って、複数のアカウントやリージョンでその変更を自動的に適用できます。
例:
- グローバルに展開しているアプリケーションのインフラを、複数のAWSリージョンに展開する際に、CloudFormation StackSetsを使って一度にデプロイ・管理する。
要するに、CloudFormation StackSets は、複数のAWSアカウントやリージョンにまたがるインフラ管理を効率化するための強力なツールです。
スイッチロールとは、AWSのユーザーが別のロールに一時的に切り替えて、そのロールに割り当てられた権限を利用できる機能です。これにより、必要な作業をする際に、特定の権限を一時的に与えることができ、最小権限の原則を守りつつ、柔軟なアクセス管理が可能になります。
StackSetsの仕組み
管理アカウントからターゲットアカウントに、スタックを作成するためには、 IAMロールが管理アカウントおよびターゲットアカウントに必要になります。
そのIAMロールを準備する方法は、以下の通り、2パターン存在します。
- サービスマネージド型AWS Organizationsの機能を使うパターン※マスターアカウントが管理アカウントになります。 また、この機能を利用するためには、Organizationsの[全ての機能]を有効にする必要があります。
- セルフマネージド型AWSが公開しているテンプレートを使い、手動でIAMロールを作成するパターン※指定したアカウントを管理アカウントにできます。
![[新機能] CloudFormation StackSetsを試してみた | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdev.classmethod.jp%2Ffavicon.ico?table=block&id=1b9d7ae8-88e2-800c-849c-f983410f47c2&t=1b9d7ae8-88e2-800c-849c-f983410f47c2)
![[新機能] CloudFormation StackSetsを試してみた | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAWS_CloudFormation.png?table=block&id=1b9d7ae8-88e2-800c-849c-f983410f47c2&t=1b9d7ae8-88e2-800c-849c-f983410f47c2)
一問道場
問題 #84
ある企業は、AWS上にクラウドインフラストラクチャを構築しています。ソリューションアーキテクトは、このインフラストラクチャをコードとして定義する必要があります。現在、インフラストラクチャは1つのAWSリージョンにデプロイされていますが、企業のビジネス拡大計画には、複数のAWSアカウントにわたる複数のリージョンへのデプロイメントが含まれています。
これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？
A. AWS CloudFormationテンプレートを使用し、IAMポリシーを追加してさまざまなアカウントを制御します。その後、複数のリージョンにテンプレートをデプロイします。
B. AWS Organizationsを使用し、管理アカウントからAWS CloudFormationテンプレートをデプロイします。AWS Control Towerを使用してアカウント間のデプロイメントを管理します。
C. AWS OrganizationsとAWS CloudFormation StackSetsを使用し、必要なIAM権限を持つアカウントからCloudFormationテンプレートをデプロイします。
D. AWS CloudFormationテンプレートでネストされたスタックを使用し、ネストされたスタックを使用してリージョンを変更します。
解説
- A: AWS CloudFormationテンプレートで複数リージョンにデプロイ可能だが、複数アカウントへの展開には手動設定が必要。
- B: AWS OrganizationsとAWS CloudFormationでデプロイ管理可能だが、AWS Control Towerはガバナンス管理用で、インフラ管理には適さない。
- C: 正解。AWS OrganizationsとCloudFormation StackSetsで、複数リージョンおよびアカウントに効率的にデプロイ可能。
- D: ネストされたスタックは同リージョン内での管理に適しており、複数リージョンへの対応には不向き。
正解: C. AWS OrganizationsとCloudFormation StackSets
086-AWS Elastic Beanstalk CICD
理論
CI/CDパイプラインとアプリケーションの迅速なデプロイメントとロールバック
- *CI/CD（継続的インテグレーション/継続的デリバリー）**は、ソフトウェア開発の効率を大幅に向上させる手法であり、頻繁なコード変更を自動化して、迅速に本番環境にデプロイすることを目指します。以下のポイントが重要です：
1. 迅速なデプロイメント
- AMI（Amazon Machine Image）やコンテナを利用したインスタンスの展開は、アプリケーションのバージョン管理と環境の迅速な構築に役立ちます。
- Elastic Beanstalkのようなマネージドサービスを利用すると、設定不要で迅速なデプロイメントが可能です。
2. ロールバックの容易さ
- URLの切り替え（ステージングと本番環境の入れ替え）は、アプリケーションのデプロイ後に問題が発生した場合にすぐに元に戻せる方法です。
- Auto Scalingやインスタンスの置き換えを用いる方法は、段階的に新しいインスタンスを追加し、古いインスタンスを削除することで、ダウンタイムなしでロールバックが可能です。
3. インフラストラクチャの管理
- AWS Systems ManagerやCloudFormationを活用すると、インフラ全体をコードとして管理し、デプロイメントの一貫性と可用性を確保できます。
- 加重ルーティング（Route 53など）を使ってトラフィックを徐々に新しい環境に移行することで、リスクを最小限に抑えつつ更新できます。
4. スケーラビリティと自動化
- Auto Scalingは、トラフィックの負荷に応じてインスタンスを自動で追加・削除でき、システムのパフォーマンスを最適化します。これにより、更新時のリソース管理が簡素化され、迅速なスケールアップ/スケールダウンが可能です。
5. 運用の効率化
- マネージドサービスを利用することで、デプロイの時間を短縮し、運用にかかる手間を削減できます。例えば、Elastic Beanstalkは、インフラの設定や管理を簡素化し、開発者がコードに集中できる環境を提供します。
これらの技術やアーキテクチャを活用することで、CI/CDパイプラインは、頻繁でリスクの少ないデプロイメントと迅速なロールバックを実現し、開発のスピードと信頼性を向上させます。
特徴 | AWS CloudFormation | AWS Systems Manager |
目的 | インフラのコード管理 | インフラとアプリケーションの運用管理 |
主な機能 | リソースのプロビジョニングと管理 | システム運用の自動化（パッチ、設定管理など） |
適用対象 | AWSリソース（EC2、S3など） | EC2、オンプレミス、パラメータストア |
自動化の範囲 | インフラ構築、更新 | 運用タスク（コマンド実行、アクセス管理など） |
運用管理 | インフラの設定と依存関係管理 | リモート管理、トラブルシューティング、監視 |
一問道場
質問 #86
ある企業は、モノリシックなアプリケーションをAWS上に展開された現代的なアプリケーション設計にリファクタリングする計画をしています。CI/CDパイプラインは、アプリケーションの現代的な設計をサポートするためにアップグレードする必要があります。以下の要件を満たす必要があります：
- 変更を毎時間数回リリースできること。
- 変更をできるだけ迅速にロールバックできること。
どの設計がこれらの要件を満たすでしょうか？
A.
アプリケーションとその設定を含むAMIを取り入れたCI/CDパイプラインを展開する。
Amazon EC2インスタンスを置き換えることでアプリケーションを展開する。
B.
AWS Elastic Beanstalkを使用して、CI/CDパイプラインのデプロイ先として別の環境を指定する。
デプロイ時に、ステージング環境と本番環境のURLを交換する。
C.
AWS Systems Managerを使用して、各デプロイメントのためにインフラを再プロビジョニングする。
Amazon EC2ユーザーデータを更新して、Amazon S3から最新のコードアーティファクトを取得し、
Amazon Route 53の加重ルーティングを使用して新しい環境にポイントする。
D.
Auto Scalingイベントの一部としてアプリケーションの更新を展開する。
新しいバージョンのAMIを使用してインスタンスを追加し、デプロイメントイベント中に設定された終了ポリシーで
以前のAMIバージョンを使用するインスタンスを段階的に廃止する。
解説
この質問では、CI/CDパイプラインを通じて、頻繁なリリースと迅速なロールバックが求められています。選択肢ごとにその特徴を解説します。
A. AMIを使用してEC2インスタンスを置き換える方法
- 解説: この方法では、アプリケーションとその設定を含むAMI（Amazon Machine Image）を使って、CI/CDパイプラインを構築します。新しいAMIを作成し、それを使ってEC2インスタンスを置き換えることで、アプリケーションを展開します。
- 長所: インスタンスを再作成することで、新しいバージョンのアプリケーションを迅速に展開できます。
- 短所: ロールバックが迅速ではなく、新しいAMIを作成する必要があり、失敗した場合に素早く元に戻すのが難しいです。頻繁にリリースを行うには不便です。
B. AWS Elastic Beanstalkを使い、ステージングと本番環境を切り替える方法
- 解説: AWS Elastic Beanstalkは、アプリケーションのデプロイ、管理、スケーリングを簡単にするサービスです。ここでは、ステージング環境と本番環境を切り替えることによって、デプロイを行います。
- 長所: ステージング環境と本番環境のURLを交換することで、簡単にデプロイとロールバックを行うことができます。特に、迅速なロールバックが可能です。
- 短所: 追加の設定や運用が必要ですが、CI/CDパイプラインに組み込むことで非常に効果的に機能します。
C. AWS Systems Managerを使用してインフラを再プロビジョニングする方法
- 解説: AWS Systems Managerを使用して、インフラを再プロビジョニングする方法では、インフラの更新と最新のコードアーティファクトの取得が行われます。また、Amazon Route 53の加重ルーティングを使って、トラフィックを新しい環境に向けることができます。
- 長所: インフラの再プロビジョニングによって最新の環境を構築できます。
- 短所: 設定が複雑で、加重ルーティングなどの管理が必要です。頻繁な変更を加えるにはやや手間がかかり、素早いロールバックも難しい場合があります。
D. Auto Scalingイベントを使用してAMIでインスタンスを追加・削除する方法
- 解説: この方法では、Auto Scalingを使用して、新しいバージョンのAMIを展開し、新しいインスタンスを追加します。既存のインスタンスをフェーズアウトすることで、更新を行います。
- 長所: 段階的なインスタンスの追加と削除により、新しいインスタンスを追加しながら古いインスタンスを削除するので、スムーズな更新が可能です。自動スケーリングにより、負荷に応じたインスタンスの追加ができます。
- 短所: インスタンスを更新する手順が少し複雑になる場合がありますが、安定した更新とロールバックが可能です。
最適解
Bが最も適切な選択肢です。理由として、AWS Elastic Beanstalkを使用すると、ステージング環境と本番環境のURLの切り替えが非常に簡単で、素早いデプロイとロールバックを実現できます。この方法は、頻繁なリリースと迅速なロールバックという要件を最も効果的に満たします。
087-SG セキュリティグループ間の参照
理論
この問題に関連する本質的な知識は、セキュリティグループの基本的な概念と、最小権限アクセスの原則に基づいたネットワークの設計方法です。
1. セキュリティグループの役割
セキュリティグループは、AWSの仮想ファイアウォールとして、インスタンスやリソースへのアクセスを制御します。セキュリティグループは、インバウンド（受信）とアウトバウンド（送信）トラフィックをフィルタリングするルールを設定します。
- インバウンドルール: 外部からインスタンスへのアクセスを許可します。DBクラスタにアクセスする場合、DBクラスタ側のインバウンドルールにEC2インスタンスをソースとして指定します。
- アウトバウンドルール: インスタンスから外部へのアクセスを許可します。EC2インスタンスがDBクラスタにアクセスするためには、アウトバウンドルールでDBクラスタを宛先として指定します。
2. 最小権限アクセス
最小権限アクセスの原則は、リソースへのアクセスを最小限に制限することで、セキュリティリスクを減らすことを目的としています。この問題では、EC2インスタンスとAurora DBクラスタ間で、必要最低限の通信だけを許可する設定が求められています。
3. セキュリティグループ間の参照
セキュリティグループ同士をソースや宛先として指定することができ、これによりインスタンス同士の通信を制御します。EC2インスタンスからAurora DBクラスタにアクセスする場合、EC2インスタンスのセキュリティグループをソースに、DBクラスタのセキュリティグループを宛先に指定することで、適切なアクセス権を設定できます。
まとめ
AWSのセキュリティグループを使って最小権限アクセスを実現するためには、インバウンドおよびアウトバウンドのルールを適切に設定し、リソース間のアクセスを明確に制御することが重要です。
一問道場
問題 #87
ある会社には、Amazon EC2インスタンスで実行されるアプリケーションがあります。ソリューションアーキテクトは、アプリケーションがAmazon Aurora DBクラスタにアクセスする必要があるAWSリージョンでVPCインフラストラクチャを設計しています。EC2インスタンスはすべて同じセキュリティグループに関連付けられています。DBクラスタは独自のセキュリティグループに関連付けられています。
ソリューションアーキテクトは、最小権限アクセスをDBクラスタに提供するためにセキュリティグループにルールを追加する必要があります。
この要件を満たすために必要な手順の組み合わせはどれですか？（2つ選んでください。）
- A. EC2インスタンスのセキュリティグループにインバウンドルールを追加します。DBクラスタのセキュリティグループをソースとして、デフォルトのAuroraポートを指定します。
- B. EC2インスタンスのセキュリティグループにアウトバウンドルールを追加します。DBクラスタのセキュリティグループを宛先として、デフォルトのAuroraポートを指定します。
- C. DBクラスタのセキュリティグループにインバウンドルールを追加します。EC2インスタンスのセキュリティグループをソースとして、デフォルトのAuroraポートを指定します。
- D. DBクラスタのセキュリティグループにアウトバウンドルールを追加します。EC2インスタンスのセキュリティグループを宛先として、デフォルトのAuroraポートを指定します。
- E. DBクラスタのセキュリティグループにアウトバウンドルールを追加します。EC2インスタンスのセキュリティグループを宛先として、エフェメラルポートを指定します。
解説
正解は B と C です。
- B: EC2インスタンスのセキュリティグループにアウトバウンドルールを追加し、DBクラスタのセキュリティグループを宛先として指定します。
- C: DBクラスタのセキュリティグループにインバウンドルールを追加し、EC2インスタンスのセキュリティグループをソースとして指定します。
A は誤りで、EC2インスタンスのインバウンドルールは不要です。D と E はアウトバウンドルールの設定に関して誤りです。
088-AWS OrganizationsのAWS Budgets
理論
AWSのコスト管理と予算管理は、クラウド環境で効率的にリソースを運用するために非常に重要です。特に、複数のアカウントやビジネスユニットが存在する大規模な組織では、集中管理と自動化が鍵となります。
AWSでは、AWS Budgets と AWS Cost Explorer といったツールを使うことで、コストを細かく管理できます。これらのツールを活用して、以下のような機能が提供されます。
- 予算設定: AWS Budgetsでは、月単位で予算を設定し、予算を超えた場合にアラートを送信することができます。予算はアカウント単位、リソース単位、タグ単位で設定でき、アプリケーションや環境ごとにコストを把握できます。
- アラート機能: 予算の閾値を超えた場合、SNS（Simple Notification Service）を通じて自動的に通知を受け取ることができます。これにより、リアルタイムでコストのオーバーランを把握でき、対策を講じることが可能です。
- Cost Explorer: Cost Explorerは、過去のコストデータを分析して、支出の傾向を可視化します。これにより、無駄なリソースの使用を発見し、改善点を特定することができます。
- AWS Organizationsの活用: 複数のAWSアカウントを管理する場合、AWS Organizationsを使ってアカウントをグループ化し、一元的にコストを管理できます。これにより、ビジネスユニットごとに予算を分けて管理し、集中してレポートを生成することができます。
これらのツールを活用することで、コストの予測、管理、最適化が効率的に行えるようになります。特に、AWS Organizationsを使用することで、複数のアカウントやビジネスユニットの支出を一元的に管理することができ、コスト管理の負担を軽減できます。
ビジネスユニット（Business Unit、BU） とは、企業の中で特定の製品ラインやサービス、地域などを担当する、比較的独立した組織のことを指します。ビジネスユニットは通常、企業全体の戦略目標に沿って、独自の戦略や運営方針を持ち、効率的に事業を推進します。
企業が大規模である場合、ビジネスユニットは組織内の専門分野を担当し、以下のような特徴があります：
- 製品やサービスごとに分かれている：例えば、ソフトウェア開発部門、マーケティング部門、営業部門など、各ビジネスユニットは自分の担当領域に特化しています。
- 地域や市場ごとに分かれている：多国籍企業の場合、地域別にビジネスユニットを分け、各市場で最適な戦略を実行します。
- 戦略的な独立性：各ビジネスユニットは、自分の目標を設定し、財務状況や経営の自由度を持つことが一般的です。
例: 大手テクノロジー企業が「クラウドサービス」「AI」「データセンター」などの分野ごとに異なるビジネスユニットを運営している場合、それぞれのビジネスユニットが自分の予算やリソースを管理し、その領域に特化した戦略を展開します。
一問道場
質問 #88
ある企業が、各ビジネスユニットの内部クラウド請求戦略を変更したいと考えています。現在、クラウドガバナンステームは、各ビジネスユニットの責任者に対して、全体的なクラウド支出に関するレポートを共有しています。この企業は、各ビジネスユニットのために異なるAWSアカウントを管理するためにAWS Organizationsを使用しています。現在のタグ付け基準には、アプリケーション、環境、および所有者が含まれています。クラウドガバナンステームは、各ビジネスユニットが月次でクラウド支出レポートを受け取り、設定された閾値を超える支出に関する通知を受け取るような集中管理のソリューションを求めています。この要件を満たすための最もコスト効果の高い方法はどれですか？
A. 各アカウントでAWS Budgetsを設定し、アプリケーション、環境、および所有者でグループ化された予算アラートを設定します。各ビジネスユニットをAmazon SNSトピックに追加し、アラートごとに通知を送信します。各アカウントでCost Explorerを使用して月次レポートを作成します。
B. AWS Organizationsの管理アカウントでAWS Budgetsを設定し、アプリケーション、環境、および所有者でグループ化された予算アラートを設定します。各ビジネスユニットをAmazon SNSトピックに追加し、アラートごとに通知を送信します。Organizationsの管理アカウントでCost Explorerを使用して月次レポートを作成します。
C. 各アカウントでAWS Budgetsを設定し、アプリケーション、環境、および所有者でグループ化された予算アラートを設定します。各ビジネスユニットをAmazon SNSトピックに追加し、アラートごとに通知を送信します。各アカウントでAWS Billing and Cost Managementダッシュボードを使用して月次レポートを作成します。
D. AWS Organizationsの管理アカウントでAWS Cost and Usage Reportsを有効にし、アプリケーション、環境、および所有者でグループ化されたレポートを設定します。AWS Lambda関数を作成し、AWS Cost and Usage Reportsを処理し、予算アラートを送信し、月次レポートを各ビジネスユニットのメールリストに送信します。
解説
この問題の解決策を選ぶためのポイントは、複数のビジネスユニットが管理するAWSアカウントのクラウド支出を集中管理し、最小のコストで運用する方法です。これに関する各選択肢の詳細を解説します。
各選択肢の解説
A. 各アカウントでAWS Budgetsを設定し、アプリケーション、環境、および所有者でグループ化された予算アラートを設定します。各ビジネスユニットをAmazon SNSトピックに追加し、アラートごとに通知を送信します。各アカウントでCost Explorerを使用して月次レポートを作成します。
- 問題点: 各アカウントに個別にAWS BudgetsとCost Explorerを設定する必要があり、ビジネスユニットごとの支出を管理するために複数の設定作業が発生します。また、個別に管理するための手間が増え、集中管理には向いていません。
- コストと管理の観点: 複数のアカウントに設定が必要なため、手間がかかり、コスト効率が悪い。
B. AWS Organizationsの管理アカウントでAWS Budgetsを設定し、アプリケーション、環境、および所有者でグループ化された予算アラートを設定します。各ビジネスユニットをAmazon SNSトピックに追加し、アラートごとに通知を送信します。Organizationsの管理アカウントでCost Explorerを使用して月次レポートを作成します。
- 正解: このアプローチは、AWS Organizationsの管理アカウントで集中管理を行う方法です。管理アカウントで予算設定とアラートを集中して設定し、SNSを通じてビジネスユニットごとに通知を送信します。さらに、Cost Explorerも管理アカウントで使用することで、全体の支出を一元的に分析できます。
- コストと管理の観点: 集中管理のため、管理アカウントで一度設定すれば、全てのビジネスユニットのクラウド支出を簡単に管理できます。この方法は最も効率的でコスト効果が高いです。
C. 各アカウントでAWS Budgetsを設定し、アプリケーション、環境、および所有者でグループ化された予算アラートを設定します。各ビジネスユニットをAmazon SNSトピックに追加し、アラートごとに通知を送信します。各アカウントでAWS Billing and Cost Managementダッシュボードを使用して月次レポートを作成します。
- 問題点: 各アカウントで個別に設定を行う必要があり、管理が分散してしまいます。これもまた管理負担が大きく、集中管理には向いていません。
- コストと管理の観点: 個別のアカウントで設定を行うため、手間が増え、集中管理による効率化が図れません。
D. AWS Organizationsの管理アカウントでAWS Cost and Usage Reportsを有効にし、アプリケーション、環境、および所有者でグループ化されたレポートを設定します。AWS Lambda関数を作成し、AWS Cost and Usage Reportsを処理し、予算アラートを送信し、月次レポートを各ビジネスユニットのメールリストに送信します。
- 問題点: AWS Lambdaを使ったカスタム処理が必要であり、これには開発と運用コストが発生します。より簡単でコスト効率の良い方法（B）の方が適しています。
- コストと管理の観点: Lambda関数を使用するため、開発・運用コストが発生し、シンプルな解決策としては不適切です。
最適解: B
選択肢 B は、AWS Organizationsの管理アカウントで予算設定とアラートを集中管理する方法です。これにより、全ビジネスユニットの支出を一元管理し、通知の配信や月次レポートの作成を効率化できます。個別アカウントでの設定作業を省略し、最小のコストで管理できます。
まとめ
最もコスト効率が良い解決策は、AWS Organizationsの管理アカウントで集中管理を行い、AWS BudgetsとCost Explorerを使って、ビジネスユニットごとの支出を管理する方法です。これにより、手間とコストを最小限に抑えながら、ビジネスユニットごとの月次レポートと予算アラートを実現できます。
089-CloudFormationのDeletionPolicy
理論
実践
一問道場
質問 #89
ある企業がAWS CloudFormationを使用してインフラストラクチャをデプロイしています。この企業は、プロダクション環境のCloudFormationスタックが削除された場合、Amazon RDSデータベースやAmazon EBSボリュームに保存されている重要なデータも削除される可能性を懸念しています。
企業はこのような誤ったデータ削除をどのように防ぐことができますか？
選択肢
A. CloudFormationテンプレートを変更して、RDSおよびEBSリソースにDeletionPolicy属性を追加する。
B. RDSおよびEBSリソースの削除を禁止するスタックポリシーを設定する。
C. IAMポリシーを変更して、「aws:cloudformation:stack-name」タグが付いたRDSおよびEBSリソースの削除を拒否する。
D. AWS Configルールを使用して、RDSおよびEBSリソースの削除を防ぐ。
解説
この問題では、CloudFormationスタックが削除される際に、重要なデータが保存されているRDSデータベースやEBSボリュームも一緒に削除されるのを防ぐ方法を問われています。解答の選択肢を以下のように解説します。
A. CloudFormationテンプレートを変更して、RDSおよびEBSリソースにDeletionPolicy属性を追加する。
正解です。この方法は、CloudFormationテンプレート内で
DeletionPolicy属性を使用し、RDSやEBSリソースに対して「Retain」を指定することで実現できます。この設定により、スタックが削除されても対象のリソースは削除されず保持されます。理由:
DeletionPolicyはCloudFormationが提供する公式機能であり、スタックの操作においてリソースの削除を制御する最適な方法です。B. RDSおよびEBSリソースの削除を禁止するスタックポリシーを設定する。
不正解です。スタックポリシーはスタック全体に対する操作を制御するものであり、特定のリソースに適用されるものではありません。RDSやEBSなどの個別リソースの削除防止には利用できません。
C. IAMポリシーを変更して、「aws:cloudformation:stack-name」タグが付いたRDSおよびEBSリソースの削除を拒否する。
不正解です。この方法は一見効果的に見えますが、IAMポリシーはユーザーやロールのアクセス制御を行うもので、CloudFormationのスタック削除プロセスに直接影響を与えるものではありません。また、タグを基にしたポリシーは管理の手間が増え、実用性が低い場合があります。
D. AWS Configルールを使用して、RDSおよびEBSリソースの削除を防ぐ。
不正解です。AWS Configはリソースの設定変更を監視するサービスであり、リソースの削除を直接防ぐ機能はありません。Configルールで削除を検知することは可能ですが、事前に削除を防ぐ仕組みにはなりません。
まとめ
- 最適な解決策: 選択肢 A の
DeletionPolicy属性を使用する方法です。 これにより、重要なデータが誤って削除されるリスクを効率的かつ簡単に軽減できます。
090-AWS SAP AWS 「理論・実践・一問道場」NAT-SG EC2-SG
理論
未承諾のインバウンドトラフィックは、以下の理由により通常はVPC内部のリソースに直接接続できません：
1. NATゲートウェイの動作
NATゲートウェイは以下の設計原則に基づいて動作します：
- 応答トラフィックのみを許可する：NATゲートウェイは、EC2インスタンスが能動的に送信したリクエストに対する応答トラフィックのみを通過させます。
- 未承諾のインバウンドトラフィックを拒否する：内部からのリクエストと関連付けられていないインバウンドトラフィックはすべて破棄されます。
したがって、外部IPアドレス
198.51.100.2 がNATゲートウェイに直接接続を試みた場合、内部からのリクエストが発生していなければ、そのトラフィックはEC2インスタンスに到達しません。2. セキュリティグループによる制限
たとえNATゲートウェイがトラフィックを許可したとしても（設定ミスやルールの誤りなどで）、セキュリティグループが未承諾のインバウンド接続をさらにブロックします。
- セキュリティグループはステートフル（Stateful）：内部からのリクエストに対する応答トラフィックは自動的に許可されます。
- 明示的な許可が必要：外部トラフィックが未承諾の状態でEC2インスタンスに直接アクセスしようとする場合、セキュリティグループでそのトラフィックを明示的に許可するルールが必要です。そうでなければ、トラフィックは拒否されます。
これらのメカニズムにより、未承諾のインバウンドトラフィックは通常、VPC内部のリソースに到達することはできません。
一問道場
質問
ある企業が、NATゲートウェイに対してVPCフローログを有効化しています。この企業では、パブリックIPアドレス「198.51.100.2」からプライベートなAmazon EC2インスタンス宛てに送信されるインバウンドトラフィックについて、Actionが「ACCEPT」となっていることを確認しています。
ソリューションアーキテクトは、このトラフィックがインターネットからの意図しないインバウンド接続を表しているかどうかを確認する必要があります。VPC CIDRブロックの最初の2つのオクテットは「203.0」です。
ソリューションアーキテクトは、この要件を満たすためにどの手順を取るべきですか？
選択肢
A. AWS CloudTrailコンソールを開きます。NATゲートウェイのElastic Network Interface（ENI）とプライベートインスタンスのENIを含むロググループを選択します。
クエリを実行し、宛先アドレスを「like 203.0」、送信元アドレスを「like 198.51.100.2」に設定してフィルタリングします。
送信元アドレスと宛先アドレスごとに転送されたバイト数の合計をフィルタリングするために
statsコマンドを実行します。B. Amazon CloudWatchコンソールを開きます。NATゲートウェイのENIとプライベートインスタンスのENIを含むロググループを選択します。
クエリを実行し、宛先アドレスを「like 203.0」、送信元アドレスを「like 198.51.100.2」に設定してフィルタリングします。
送信元アドレスと宛先アドレスごとに転送されたバイト数の合計をフィルタリングするために
statsコマンドを実行します。C. AWS CloudTrailコンソールを開きます。NATゲートウェイのENIとプライベートインスタンスのENIを含むロググループを選択します。
クエリを実行し、宛先アドレスを「like 198.51.100.2」、送信元アドレスを「like 203.0」に設定してフィルタリングします。
送信元アドレスと宛先アドレスごとに転送されたバイト数の合計をフィルタリングするために
statsコマンドを実行します。D. Amazon CloudWatchコンソールを開きます。NATゲートウェイのENIとプライベートインスタンスのENIを含むロググループを選択します。
クエリを実行し、宛先アドレスを「like 198.51.100.2」、送信元アドレスを「like 203.0」に設定してフィルタリングします。
送信元アドレスと宛先アドレスごとに転送されたバイト数の合計をフィルタリングするために
statsコマンドを実行します。解説
この問題では、NATゲートウェイを使用している場合に、インターネットからプライベートなEC2インスタンスへのインバウンドトラフィックが意図しない接続であるかどうかを確認する必要があります。
NATゲートウェイの基本的な動作は、内部インスタンスが外部にリクエストを送信した場合にのみ、外部からの応答トラフィックを許可するというものです。このため、NATゲートウェイが受け入れるトラフィックは通常、内部インスタンスからのリクエストに対応する応答であり、意図しないインバウンド接続であることは考えにくいです。
そのため、今回の調査目的は、このトラフィックが本当に内部からのリクエストに関連する応答であるのか、あるいは外部からの誤った接続でないかを確認することにあります。
解答に関しては、以下の理由でDが正解です：
- Dのクエリは、送信元アドレスを「203.0」(VPCのCIDRブロックに関連する範囲) とし、宛先アドレスを「198.51.100.2」としてフィルタリングすることで、外部からの誤った接続がないかを確認しています。
- Bは逆に宛先アドレスを「203.0」、送信元アドレスを「198.51.100.2」と設定していますが、この設定ではトラフィックの方向が正しくありません。具体的には、外部から内部に向かう流れ（未リクエストの接続）を正しく調べることができません。
結論として、Dは外部からの誤った接続を特定するために適切なアクションであるため、正解となります。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16cd7ae8-88e2-80cd-a3da-fd398728201e
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
