type
status
date
slug
summary
tags
category
icon
password

441-AWS SAP AWS 「理論・実践・一問道場」1つの組織

理論

AWS OrganizationsとSCP

1. AWS Organizations

  • 概要: 複数のAWSアカウントを一元的に管理するためのサービス。
  • 主な特徴:
    • 統合請求（Consolidated Billing）:
      • 複数のアカウントの請求をまとめて管理。
      • 各アカウントの利用状況を個別に確認可能。
    • 組織単位（OU: Organizational Units）:
      • アカウントをグループ化して管理を簡素化。
  • 主な利点:
    • コスト管理の効率化。
    • ガバナンスポリシーを組織全体に適用可能。

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

  • 概要: AWS Organizationsで使用されるポリシーで、アカウントやOUで許可するAWSサービスやアクションを制御。
  • 主な特徴:
    • サービス制限: 特定のAWSサービスを許可または禁止。
    • IAMポリシーとの違い: SCPは「何が許可されるかの上限」を設定する。IAMポリシーが許可していても、SCPで制限されている操作は実行不可。
    • ルートユーザー制御不可: SCPはルートユーザーのアクションには影響しない。
  • 活用例:
    • セキュリティ要件に基づき、特定のリージョンやサービスを制限。
    • 開発環境でコストの高いサービス（例: Amazon Redshift）を禁止。

3. 統合されたコスト管理

  • AWS Organizationsの統合請求機能を活用すると以下が可能:
    • 複数アカウントの請求をまとめて1つの請求書で管理。
    • 各アカウントのコストを分割してトラッキング。
    • 個別のアカウントごとの支出分析やコスト最適化が容易。

AWSベストプラクティス

  • 一元管理: AWS Organizationsを使用して、複数のアカウントを効率的に管理。
  • ガバナンス強化: SCPでポリシーを適用し、コンプライアンスやセキュリティ要件を満たす。
  • コスト最適化: 統合請求でアカウント間のコスト管理を効率化。
これらを組み合わせることで、セキュアかつ効率的なマルチアカウント運用が実現します。

実践

略

一問道場

質問 #441
ある企業には複数の事業部門 (LOB: Line of Business) があり、それらは親会社に統合されています。この企業は、ソリューションアーキテクトに次の要件を満たすソリューションを開発するよう依頼しました：
  • LOBが使用するすべてのAWSアカウントを対象に、1つのAWS請求書を作成する。
  • 請求書には、各LOBアカウントのコストが個別に記載される。
  • 企業のガバナンスポリシーで定義されたサービスや機能をLOBアカウントで制限できるようにする。
  • ガバナンスポリシーに関係なく、各LOBアカウントにフル管理者権限を委譲する。
これらの要件を満たすために、ソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（2つ選択してください）
A. AWS Organizations を使用して、親アカウント内に各LOB用の組織を作成し、それぞれのLOBアカウントを該当する組織に招待する。
B. AWS Organizations を使用して、親アカウント内に1つの組織を作成し、各LOBのAWSアカウントをその組織に招待する。
C. サービスクォータを実装し、許可されるサービスや機能を定義し、必要に応じて各LOBにクォータを適用する。
D. 承認されたサービスや機能のみを許可するSCP（サービスコントロールポリシー）を作成し、そのポリシーをLOBアカウントに適用する。
E. 親アカウントの請求コンソールで統合請求を有効化し、LOBアカウントをリンクする。

解説

以下は、選択肢 B と D を正解とする理由の詳細な解説です。

問題の要件整理

  1. 単一のAWS請求書で全アカウントをまとめる
      • 全てのLOBアカウントのコストを1つの請求書に統合し、各アカウントのコストを個別に追跡できる仕組みが必要です。
  1. ガバナンスポリシーに基づいた制限を適用する
      • 企業ポリシーに従い、特定のサービスや機能を制限する必要があります。
  1. LOBアカウントにはフル管理者権限を委譲する
      • 各LOBが独立してフル管理者権限を持ちつつも、中央でガバナンスを効かせる必要があります。

選択肢の評価

B. AWS Organizationsを使用して、親アカウント内に1つの組織を作成し、各LOBのAWSアカウントをその組織に招待する。

  • 理由:
      • AWS Organizationsは、複数のAWSアカウントを一元的に管理できるサービスです。親アカウントに1つの組織を作成し、各LOBアカウントを招待することで以下を実現できます：
    • 単一の請求書でコストを管理（統合請求が自動的に有効化）
    • サービスコントロールポリシー（SCP）の適用によるガバナンス強化
      • → 要件1（請求の統合）と要件2（ガバナンス）をサポートする重要な選択肢です。

D. 承認されたサービスや機能のみを許可するSCP（サービスコントロールポリシー）を作成し、そのポリシーをLOBアカウントに適用する。

  • 理由:
      • SCP（Service Control Policy）は、AWS Organizationsで使用されるポリシーで、特定のアクションやサービスを許可・制限できます。
      SCPは「ルートアカウントでの設定」を制限できないため、各LOBアカウントにフル管理者権限を委譲しながら、ガバナンスポリシーに基づいた制限を適用することが可能です。
      例えば：
    • 企業で許可されていないサービス（例: Amazon Redshift）を使用不可にする。
    • 特定のリージョンでのみリソースを作成可能にする。
      • → 要件2（ガバナンスの制限）を直接的にサポートします。

不正解の選択肢

A. AWS Organizations を使用して、親アカウント内に各LOB用の組織を作成し、それぞれのLOBアカウントを該当する組織に招待する。

  • 理由: AWS Organizationsでは、1つの親アカウントで複数の組織を作成することはできません。 組織は1つのみ作成可能で、各LOBアカウントをその組織に招待する形になります。→ 誤り。

C. サービスクォータを実装し、許可されるサービスや機能を定義し、必要に応じて各LOBにクォータを適用する。

  • 理由: サービスクォータ（Service Quotas）はリソースの上限値を設定する機能です。 例えば、特定のリソースを「100個まで」などに制限できますが、サービスそのものを使用禁止にすることはできません。 ガバナンスの要件（特定のサービスや機能を制限）には適していません。→ 誤り。

E. 親アカウントの請求コンソールで統合請求を有効化し、LOBアカウントをリンクする。

  • 理由: 統合請求はAWS Organizationsを使用することで自動的に有効化されるため、別途設定する必要はありません。また、この選択肢ではガバナンスの要件（ポリシーによる制限）が満たされません。→ 誤り。

結論

  • B: AWS Organizationsを使用してLOBアカウントを一元管理する。
  • D: SCPを用いてガバナンスポリシーに基づいた制限を適用する。
この2つを組み合わせることで、すべての要件を満たすソリューションを構築できます。
 
 
 

442-AWS SAP AWS 「理論・実践・一問道場」多重レコード

 

理論

1. Amazon Route 53

Amazon Route 53は、AWSのスケーラブルなDNSウェブサービスで、ドメイン名をIPアドレスに解決するために使用されます。Route 53には、以下の重要なルーティングポリシーがあります：
  • 遅延ベースルーティング (Latency-Based Routing):
    • 最小の遅延でユーザーにサービスを提供するために使用されます。Route 53は、ユーザーがどのリージョンから最も早くサービスを受けられるかを評価し、そのリージョンにトラフィックをルーティングします。
    • 遅延ベースルーティングは、各リージョンのパフォーマンスを監視し、最適なリージョンにトラフィックを分配します。
  • 加重レコードセット (Weighted Record Sets):
    • 複数のターゲットにトラフィックを分配するために使用されます。加重レコードセットを使用すると、異なるリソースに対して異なる割合でトラフィックを送信できます。
    • 例えば、1つのサーバーに70%のトラフィックを、別のサーバーに30%のトラフィックを分配できます。

2. 健康チェック (Health Checks)

健康チェックは、Route 53がリソースの正常性を確認するために使用する仕組みです。正常なリソースにのみトラフィックを送ることができます。
  • ターゲットの健康評価を有効にする:
    • Route 53では、エイリアスレコードやその他のリソースに対して健康チェックを有効にできます。この設定を有効にすることで、Route 53はリソースの正常性を監視し、正常でないリソースにはトラフィックを送らないようにします。
    • ターゲットの健康評価を無効にすると、リソースがダウンしていてもトラフィックはそのリソースに送られ続け、サービスの可用性が低下する可能性があります。
  • 健康チェックの設定:
    • 例えば、HTTPリクエストを送信してレスポンスを確認したり、特定のTCPポートが応答しているかを確認することができます。これにより、システムの障害を早期に検出できます。

3. Route 53の組み合わせ使用

  • 遅延ルーティングと加重ルーティングの併用:
    • 遅延ベースルーティングと加重レコードセットは、異なる目的で使用されますが、同時に使用することが可能です。
    • 遅延ベースルーティングはパフォーマンス最適化に基づき、加重レコードセットはトラフィック分配に基づいて動作します。これにより、システムが高可用性を維持しながら、最適なパフォーマンスを提供することができます。

4. 災害復旧シナリオにおけるRoute 53の役割

災害復旧シナリオでは、システムの冗長性を確保し、万が一の障害時に自動的に他のリージョンやサーバーにトラフィックをリダイレクトできるようにすることが重要です。
  • 健康チェックと自動リダイレクト:
    • 健康チェックを使用することで、Webサーバーがダウンした場合、トラフィックを他のリージョンやサーバーに自動的にリダイレクトできます。
    • 健康チェックが設定されていないと、Route 53はサーバーがダウンしているかどうかを認識せず、トラフィックを停止したサーバーに送信し続ける可能性があります。

まとめ

  • 遅延ベースルーティングと加重レコードセットを併用することは可能ですが、両方が正常に機能するためにはターゲットの健康評価を有効にし、健康チェックを設定することが必要です。
  • これにより、障害時にトラフィックを自動的に適切なターゲットにリダイレクトし、高可用性を保つことができます。

実践

略

一問道場

問題 #442
ソリューションアーキテクトは、カスタムドメインの下で2つのAWSリージョンにわたるユーザーにサービスを提供するWebアプリケーションをデプロイしました。このアプリケーションは、Amazon Route 53のレイテンシーベースのルーティングを使用しています。ソリューションアーキテクトは、各リージョンの別々のアベイラビリティゾーンにあるWebサーバーのペアに重み付きレコードセットを関連付けました。
ソリューションアーキテクトはディザスタリカバリシナリオを実行します。1つのリージョンのWebサーバーがすべて停止したとき、Route 53は自動的にユーザーを別のリージョンにリダイレクトしませんでした。
この問題の可能性がある根本的な原因はどれですか？（2つ選択してください。）
A. Webサーバーが停止したリージョンの重みが、他のリージョンの重みよりも高く設定されている。
B. セカンダリリージョンのWebサーバーの1つがHTTPヘルスチェックに合格しなかった。
C. レイテンシーリソースレコードセットは、重み付きリソースレコードセットと組み合わせて使用することはできない。
D. Webサーバーが停止したリージョンのドメインに関連付けられたレイテンシーエイリアスリソースレコードセットの評価ターゲットヘルス設定が有効になっていない。
E. 停止したWebサーバーに関連付けられた1つ以上の重み付きリソースレコードセットにHTTPヘルスチェックが設定されていない。

解説

正解は D と E です。それぞれの選択肢について詳しく解説します。

D. 遅延エイリアスリソースレコードセットに対してターゲット健康評価を有効にする設定がされていない

  • 遅延エイリアスリソースレコードセットに対してターゲットの健康チェックを評価する設定が無効になっている場合、Route 53はWebサーバーが停止したかどうかを認識できません。
  • ターゲットの健康評価は、リソース（Webサーバーなど）が正常であるかどうかを判別するための機能であり、これが有効になっていないと、サーバーが停止しても他のリージョンに自動的にリダイレクトされません。
  • これを有効にすることで、健康チェックが正常に動作し、トラフィックを適切に他のリージョンにルーティングできるようになります。

E. 健康チェックが設定されていない

  • Route 53は、トラフィックをルーティングする際、健康チェックを使用して各ターゲットの正常性を確認します。
  • もし、健康チェックが設定されていない場合、Route 53はリソースがダウンしていることを検出できず、停止したサーバーにトラフィックを送り続けます。
  • 健康チェックを設定し、サーバーがダウンした場合には他のリージョンにリダイレクトされるようにする必要があります。

なぜ他の選択肢が誤りか

  • A. 「1つのリージョンのWebサーバーの重みが他のリージョンより高い」:
      • これは加重レコードセットの設定に関する問題であり、遅延ベースのルーティングと健康チェックには直接関係しません。遅延ベースのルーティングは、最小の遅延を選択するため、重みの設定が間違っていても自動的に別のリージョンに切り替わる可能性があるため、この問題の原因にはなりません。
  • B. 「1つのWebサーバーが健康チェックに合格しなかった」:
      • 健康チェックに合格しない場合、Route 53はそのサーバーを無効と見なし、他の正常なサーバーにリダイレクトします。しかし、これが問題の原因とは限りません。設定が間違っている場合に該当するため、直接的な原因とは言えません。
  • C. 「遅延リソースレコードセットと加重リソースレコードセットを同時に使用できない」:
      • これは誤りです。遅延ベースのルーティングと加重レコードセットは、異なる目的で使われますが、両方を同時に使用することは可能です。この問題では、ルーティングポリシーの組み合わせは問題ではありません。

まとめ

  • D と E の選択肢が正解です。
    • D：ターゲットの健康評価を有効にしないと、健康チェックが機能しません。
    • E：健康チェックが設定されていないと、Route 53はリソースが正常かどうかを判断できません。
  • これらの設定を適切に行うことで、災害復旧シナリオでのトラフィックの自動的なリダイレクトが正常に行われるようになります。
 
 
 
 

443-AWS SAP AWS 「理論・実践・一問道場」 Parquet形式

 

理論

1. AWS IoT Core

  • 概要: AWS IoT Coreは、デバイスからAWSクラウドへのデータ送信を簡単にし、デバイス間のメッセージング、データ収集、デバイス管理を行うためのサービスです。センサーやIoTデバイスがクラウドに直接データを送信する際に利用されます。
  • 用途: IoTデバイスが送信するメッセージを受信し、処理、保存、分析するために使用されます。

2. Amazon Kinesis Data Firehose

  • 概要: Amazon Kinesis Data Firehoseは、リアルタイムデータストリーミングサービスで、データを簡単にAmazon S3、Amazon Redshift、Amazon Elasticsearchなどに取り込むことができます。
  • 用途: 大量のデータをリアルタイムで集め、データをストレージに保存するために使用されます。このサービスは、データストリームの変換や圧縮もサポートしています。

3. AWS Lambda

  • 概要: AWS Lambdaは、サーバーレスコンピューティングサービスで、コードを実行するためにインフラの管理を不要にします。データの変換、集約、保存などのタスクを簡単に自動化できます。
  • 用途: Kinesis Data FirehoseやS3に送られたデータを処理・変換し、他のサービスへ渡す際に使用されます。例えば、センサーから送られたデータをCSVやParquet形式に変換する処理など。

4. Amazon S3

  • 概要: Amazon S3 (Simple Storage Service)は、データを高い耐久性で保存するためのオブジェクトストレージサービスです。大規模なデータの保存に最適で、非常にスケーラブルです。
  • 用途: Kinesis Data FirehoseやLambdaから受け取ったデータを長期間保存するために使用されます。特に、データ分析やアーカイブの目的でよく利用されます。

5. Apache Parquet

  • 概要: Apache Parquetは、列指向のデータフォーマットで、大規模データのクエリ性能を向上させるために使用されます。特に、ビッグデータ環境や分析に適しています。
  • 用途: データの保存形式として選ばれることが多く、S3に保存されるデータの形式として適しています。Parquetフォーマットは、ストレージ効率が良く、読み込み/書き込みが高速です。

6. Amazon Athena

  • 概要: Amazon Athenaは、S3に保存されたデータに対して直接SQLクエリを実行できるインタラクティブなクエリサービスです。データを別途ロードすることなく、S3上で直接分析できます。
  • 用途: S3に保存されたデータに対して、データアナリストが迅速にSQLクエリを実行して分析を行うために使用されます。Athenaは、ParquetやCSV形式のデータに対して非常に効率的に動作します。

推奨アーキテクチャの概念

  • データフロー:
      1. センサーからのデータがAWS IoT Coreに送信され、Kinesis Data Firehoseに転送されます。
      1. AWS Lambdaを使用して、受け取ったデータを適切な形式（例えば、Apache Parquet）に変換します。
      1. 変換されたデータは、Amazon S3に保存されます。
      1. データアナリストは、Amazon Athenaを使用してS3に保存されたデータに対してSQLクエリを実行します。
  • 利点:
    • スケーラビリティ: 各コンポーネントはスケーラブルであり、必要に応じてリソースを自動的に拡張できます。
    • コスト効率: サーバーレスで、使った分だけ課金されるため、コスト効率が良いです。
    • 管理負担の軽減: サーバーの管理が不要で、データ処理が自動化されているため、運用の負担が軽減されます。

実際のシナリオでの使用方法

このアーキテクチャは、IoTセンサーからのデータ収集を効率的に処理するために使用されます。特に、センサーからのデータが常に発生するシナリオでは、リアルタイムでのデータ処理、保存、および迅速なクエリ処理が必要です。AthenaとParquetの組み合わせは、データ分析のパフォーマンスを大幅に向上させます。

実践

略

一問道場

質問 #443
洪水監視機関は、10,000台以上の水位監視センサーを展開しています。センサーは継続的にデータ更新を送信し、各更新は1MB未満のサイズです。この機関には、これらのセンサーからの更新を受け取るオンプレミスのアプリケーションサーバー群があります。サーバーは生データを人間が読みやすい形式に変換し、その結果をオンプレミスのリレーショナルデータベースサーバーに書き込みます。データ分析者は、その後、簡単なSQLクエリを使用してデータを監視します。
機関は、アプリケーションの可用性を向上させ、メンテナンスタスクに必要な労力を削減したいと考えています。これらのメンテナンスタスクには、アプリケーションサーバーへの更新やパッチが含まれており、そのためダウンタイムが発生します。アプリケーションサーバーがダウンしている間、残りのサーバーではセンサーからの全てのワークロードを処理できないため、データが失われます。
機関は、運用オーバーヘッドとコストを最適化するソリューションを望んでいます。ソリューションアーキテクトは、AWS IoT Coreを使用してセンサーデータを収集することを推奨しました。これらの要件を満たすために、ソリューションアーキテクトは何を推奨すべきですか？
A. センサーデータをAmazon Kinesis Data Firehoseに送信します。AWS Lambda関数を使用して、Kinesis Data Firehoseのデータを読み取り、CSV形式に変換して、Amazon Aurora MySQL DBインスタンスに挿入します。データ分析者には、DBインスタンスから直接データをクエリするように指示します。
B. センサーデータをAmazon Kinesis Data Firehoseに送信します。AWS Lambda関数を使用して、Kinesis Data Firehoseのデータを読み取り、Apache Parquet形式に変換して、Amazon S3バケットに保存します。データ分析者には、Amazon Athenaを使用してデータをクエリするように指示します。
C. センサーデータをAmazon Managed Service for Apache Flink（以前のAmazon Kinesis Data Analytics）アプリケーションに送信して、データをCSV形式に変換し、Amazon S3バケットに保存します。その後、データをAmazon Aurora MySQL DBインスタンスにインポートします。データ分析者には、DBインスタンスから直接データをクエリするように指示します。
D. センサーデータをAmazon Managed Service for Apache Flink（以前のAmazon Kinesis Data Analytics）アプリケーションに送信して、データをApache Parquet形式に変換し、Amazon S3バケットに保存します。データ分析者には、Amazon Athenaを使用してデータをクエリするように指示します。

解説

正解はBです。

問題の解説

この問題は、IoTセンサーからのデータ収集、処理、および分析に関するものです。具体的には、センサーからのデータを受け取って、効果的に処理し、データアナリストが簡単に分析できるようにするためのアーキテクチャ設計に関する問題です。

正解選択肢：B

  • B: センサーからのデータをAmazon Kinesis Data Firehoseに送信し、AWS Lambda関数を使用してデータを読み取り、Apache Parquet形式に変換してAmazon S3バケットに保存します。その後、データアナリストがAmazon Athenaを使ってデータをクエリします。
    • 理由:
      • Kinesis Data Firehoseは、データをリアルタイムで収集し、Amazon S3などのストレージサービスに直接送信できるサービスです。
      • AWS Lambdaを使って、Kinesisからのデータを変換する処理を簡単に自動化できます。
      • Apache Parquetは、列指向のデータフォーマットで、データのクエリ性能を向上させるため、大規模データに対する効率的な分析を実現します。
      • Amazon Athenaは、S3に保存されたデータに対して直接SQLクエリを実行できるサービスです。データをデータベースにロードせずに、効率的にクエリができます。

他の選択肢の説明

  • A: センサーのデータをKinesis Data Firehoseに送信し、AWS Lambda関数を使用してCSV形式に変換し、Amazon Aurora MySQL DBインスタンスに挿入します。データアナリストはDBインスタンスから直接データをクエリします。
    • 問題点: CSVは大規模データに対する効率的なクエリを提供しません。さらに、Aurora MySQLはリレーショナルデータベースであり、スケーラビリティやパフォーマンスの面で制限があります。
  • C: センサーのデータをAmazon Managed Service for Apache Flinkに送信し、データをCSV形式に変換してAmazon S3に保存し、その後、データをAmazon Aurora MySQL DBインスタンスにインポートします。
    • 問題点: Apache Flinkは強力なストリーム処理を提供しますが、CSV形式で保存するとパフォーマンスが低下します。また、最終的なDBに保存する手順が冗長で、Athenaを使った方が効率的です。
  • D: センサーのデータをAmazon Managed Service for Apache Flinkに送信し、データをApache Parquet形式に変換してAmazon S3に保存し、データアナリストがAmazon Athenaを使ってデータをクエリします。
    • 問題点: これは理想的な選択肢に近いですが、Flinkの使用はこのケースではオーバーキルです。Kinesis Data FirehoseとLambdaで十分に処理可能です。

結論

選択肢Bが最適です。理由は、Kinesis Data Firehose、Lambda、S3、Athenaの組み合わせが非常にスケーラブルで、運用コストも低く、簡単に設定できます。また、データをApache Parquet形式で保存することで、後で効率的にクエリを実行でき、全体的に効率的なデータ処理と分析が可能です。
 
 

444-AWS SAP AWS 「理論・実践・一問道場」ヘルスチェック

 

理論

1. Amazon EC2 とターゲットグループのヘルスチェック

  • ヘルスチェックは、アプリケーションやインスタンスの稼働状況を監視する重要な手段です。ターゲットグループのヘルスチェックが失敗すると、オートスケーリングが自動的にインスタンスを交換することがあります。
  • ヘルスチェックの設定を適切に行うことが大切で、シンプルなページや応答時間の長いページではなく、アプリケーションの重要な機能を評価するエンドポイントに設定するべきです。

2. RDS と読み取りレプリカ

  • Amazon RDS MySQLでは、データベースの読み取り負荷を分散するために読み取りレプリカを使用することができます。これにより、読み取り要求を複数のインスタンスに分散させ、プライマリデータベースへの負荷を軽減できます。
  • 書き込み負荷が問題である場合、読み取りレプリカは効果がありません。データベースのスケーリングやパフォーマンス改善には、適切な監視と対策が求められます。

3. CloudWatch アラーム

  • Amazon CloudWatchは、AWSリソースのパフォーマンスや状態を監視し、アラームを設定して通知を受けることができます。特に、RDSインスタンスが高負荷の状態にある場合にアラームを設定することで、早期に問題を検出し、対応ができます。
  • CloudWatchは、メトリクスを監視することで、アプリケーションのパフォーマンスを改善し、障害の予兆を検出できます。

4. ElastiCache の導入

  • Amazon ElastiCacheは、インメモリキャッシュサービスで、アプリケーションのバックエンドデータベースへのアクセス負荷を軽減できます。キャッシュを使用することで、読み取り性能が向上し、データベースの負荷を大幅に削減できます。
  • 特に、頻繁にアクセスされるデータや計算結果をキャッシュすることで、応答時間が短縮され、全体的なアプリケーションのパフォーマンスが向上します。

5. オートスケーリング

  • オートスケーリングは、アプリケーションの負荷に応じて自動的にインスタンス数を調整する機能です。ターゲットグループのヘルスチェック結果を元に、スケーリングが実行されますが、バックエンドのデータベース層のパフォーマンスが低下していると、インスタンスのスケーリングでは効果が出ないことがあります。
  • 高負荷の問題がデータベース層にある場合、データベース層のスケーリングやキャッシュの導入など、他の手段で負荷を軽減する必要があります。

まとめ

  • アプリケーションの可用性とパフォーマンスを最適化するためには、データベース層への負荷軽減が重要です。読み取りレプリカやElastiCacheを使用して、データベースへの負荷を分散・削減しましょう。
  • CloudWatchを利用して、RDSインスタンスのパフォーマンスを監視し、問題が発生する前にアラームを設定して通知を受けることが、迅速な対応に繋がります。
  • ヘルスチェックを適切に設定し、アプリケーション全体の機能性を評価することで、可用性を保ちつつパフォーマンスの向上を図れます。

実践

略

一問道場

質問 #444
ある公共の小売ウェブアプリケーションは、アプリケーションロードバランサー (ALB) を使用して複数のアベイラビリティゾーン (AZ) に展開された Amazon EC2 インスタンスをフロントエンドとして使用し、バックエンドには Amazon RDS MySQL のマルチ AZ 配備を利用しています。ターゲットグループのヘルスチェックは HTTP を使用し、商品カタログページを指しています。オートスケーリングは ALB のヘルスチェックに基づいてウェブフリートのサイズを維持するように設定されています。最近、このアプリケーションで障害が発生しました。オートスケーリングは障害中にインスタンスを継続的に交換しましたが、後の調査でウェブサーバーのメトリクスは正常である一方、データベース層が高負荷にあり、クエリ応答時間が大きく遅延していたことが判明しました。
このアプリケーションの可用性と機能性の監視能力を改善し、将来の成長に備えるために、次の変更を2つ選ぶべきです。
A. Amazon RDS MySQL に読み取りレプリカを構成し、ウェブアプリケーションで単一のリーダーエンドポイントを使用して、バックエンドのデータベース層への負荷を軽減します。
B. ターゲットグループのヘルスチェックを商品カタログページではなく、シンプルな HTML ページに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。
C. ターゲットグループのヘルスチェックを Amazon EC2 ウェブサーバーの TCP チェックに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。
D. 高負荷の状態にある Amazon RDS インスタンスを回復させるアクションを設定した Amazon RDS 用の Amazon CloudWatch アラームを構成します。
E. Amazon ElastiCache クラスターを構成し、ウェブアプリケーションと RDS MySQL インスタンスの間に配置して、バックエンドのデータベース層への負荷を軽減します。

解説

A. Amazon RDS MySQL に読み取りレプリカを構成し、ウェブアプリケーションで単一のリーダーエンドポイントを使用して、バックエンドのデータベース層への負荷を軽減します。

  • 評価: 読み取りレプリカを使用することで、データベースの読み取り負荷を分散できますが、このケースではアプリケーションで発生している高負荷の問題が「クエリ応答時間の遅延」に関係しているため、読み取りレプリカが解決するのは読み取りの負荷軽減に限られます。書き込み負荷が問題である場合、この変更だけでは効果が薄いです。

B. ターゲットグループのヘルスチェックを商品カタログページではなく、シンプルな HTML ページに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。

  • 評価: ヘルスチェックの対象を簡単なページに変更することは、インスタンスが正常に稼働しているかどうかを確認するための一歩ではありますが、アプリケーションのバックエンド（特にデータベースのパフォーマンス）の問題を特定するには不十分です。商品ページに対するRoute 53のヘルスチェックは機能的には有効ですが、根本的なデータベースのパフォーマンス問題に対処することはできません。

C. ターゲットグループのヘルスチェックを Amazon EC2 ウェブサーバーの TCP チェックに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。

  • 評価: TCP チェックはEC2インスタンスの稼働状況を確認するには有効ですが、アプリケーションのパフォーマンスやバックエンドデータベースの状態を反映するものではありません。商品ページに対するRoute 53のヘルスチェックは有効ですが、この変更もデータベース層の問題には対応していません。

D. 高負荷の状態にある Amazon RDS インスタンスを回復させるアクションを設定した Amazon RDS 用の Amazon CloudWatch アラームを構成します。

  • 評価: RDSの高負荷状態に対するアラームを設定することは非常に重要です。これにより、高負荷が発生した際に早期に検出し、対応策を取ることができます。データベースのパフォーマンスに関する問題を迅速に把握し、適切な対処が可能となります。これは非常に有効な変更です。

E. Amazon ElastiCache クラスターを構成し、ウェブアプリケーションと RDS MySQL インスタンスの間に配置して、バックエンドのデータベース層への負荷を軽減します。

  • 評価: ElastiCacheを導入することで、頻繁に読み込まれるデータをキャッシュし、データベース層へのアクセス負荷を軽減できます。これにより、データベースの負荷が軽減され、クエリ応答時間が短縮されるため、アプリケーションのパフォーマンスが向上します。これは非常に効果的な変更です。

結論:

アプリケーションの可用性と機能性を改善するために適切な変更は、D (RDSインスタンスに対するCloudWatchアラームの設定) と E (ElastiCacheの導入) です。この2つの変更がデータベースのパフォーマンスを改善し、アプリケーション全体の可用性を向上させるために有効です。
 
 

445-AWS SAP AWS 「理論・実践・一問道場」AWS Outposts

 

理論

AWSでオンプレミスとクラウドを統合したKubernetesの運用

1. AWS Outposts

  • AWS Outpostsは、AWSのクラウドインフラをオンプレミスに拡張するサービスです。これにより、オンプレミスでAWSのサービスを利用できるため、既存のデータセンター環境とクラウドを統合することが可能になります。
  • ローカルクラスター構成：EKSのコントロールプレーンはAWSクラウドで管理され、データプレーン（ワークロード実行部分）はOutposts上のオンプレミスに配置されます。これにより、オンプレミスでのワークロード実行とクラウドでの管理を統合でき、運用負荷が最小化されます。

2. Amazon EKS (Elastic Kubernetes Service)

  • EKSは、AWSのフルマネージドKubernetesサービスで、Kubernetesクラスターの管理をAWSが代行します。これにより、インフラ管理にかかる負担を軽減できます。
  • EKS Anywhere：EKS Anywhereは、AWSが提供するオンプレミス向けKubernetes管理ツールですが、オンプレミスでの完全なKubernetesクラスター管理が必要です。フルマネージドサービスではないため、運用負荷が増加します。

3. 運用負荷の軽減方法

  • EKSの管理機能を活用すると、クラウドの利点（スケーラビリティ、セキュリティ、メンテナンス）を最大限に活かしつつ、オンプレミスのインフラにも対応できます。
  • オンプレミスにAWS Outpostsを使用することで、AWSがインフラの一部として管理を提供し、ローカルクラスター構成を採用することで、クラウドとオンプレミスの両方の利点を享受できます。

4. ハイブリッドクラウド戦略

  • ハイブリッドクラウドでは、オンプレミス環境とクラウド環境の統合が重要です。特に、データセンターの既存のインフラをクラウドの管理下で運用することで、柔軟性や拡張性が向上します。
  • AWSのOutpostsやEKSは、ハイブリッドクラウドを構築するための強力なツールであり、特に低レイテンシ要求や特定の規制要件がある場合に有効です。

まとめ

  • AWS Outpostsを利用して、EKSの管理機能をフル活用し、オンプレミスとクラウドを統合する方法が最適です。
  • EKS Anywhereなどのオンプレミス向けツールは、管理負荷が高くなるため、運用負担を最小化することが重要です。

実践

略

一問道場

質問 #445
ある会社がオンプレミスのデータセンターを利用しており、AWS上で新しいソリューションを開発するためにKubernetesを使用しています。この会社は、開発およびテスト環境のためにAmazon Elastic Kubernetes Service (Amazon EKS) クラスターを利用しています。
生産ワークロードのためのEKSコントロールプレーンとデータプレーンはオンプレミスに配置する必要があります。この会社はKubernetesの管理に関するAWSの管理されたソリューションを必要としています。
どのソリューションが最小の運用負荷でこれらの要件を満たしますか？
A. オンプレミスのデータセンターにAWS Outpostsサーバーをインストールし、Outpostsサーバー上でローカルクラスター構成を使用してAmazon EKSを展開し、生産ワークロードを実行します。
B. 会社のハードウェアにAmazon EKS Anywhereをインストールし、オンプレミスのデータセンターでEKS Anywhereクラスターを展開して生産ワークロードを実行します。
C. オンプレミスのデータセンターにAWS Outpostsサーバーをインストールし、Outpostsサーバー上で拡張クラスター構成を使用してAmazon EKSを展開し、生産ワークロードを実行します。
D. オンプレミスのデータセンターにAWS Outpostsサーバーをインストールし、OutpostsサーバーにAmazon EKS Anywhereをインストールして、生産ワークロードをEKS Anywhereクラスターで実行します。

解説

選択肢Aが正解である理由についての解説を詳しく説明します。

前提の要件

  • AWSでのKubernetes管理: 会社は、AWSの管理されたKubernetesソリューションを必要としており、オンプレミスに配置する必要があるのはEKSコントロールプレーンとデータプレーンです。
  • 最小の運用負荷: 要件の一つは、管理の負荷を最小限に抑えることです。これは、AWSのフルマネージドサービスを利用し、オンプレミスのデータセンターにおける管理を可能な限りシンプルにする必要があります。

各選択肢の解説

A. オンプレミスのデータセンターにAWS Outpostsサーバーをインストールし、Outpostsサーバー上でローカルクラスター構成を使用してAmazon EKSを展開し、生産ワークロードを実行します。

  • AWS Outposts は、AWSが提供するオンプレミスのインフラストラクチャで、AWSのサービスをオンプレミス環境でも利用できるようにするものです。
  • ローカルクラスター構成では、AWSのEKSコントロールプレーン（Kubernetesの管理部分）がAWSクラウド上に配置され、データプレーン（実際のワークロード部分）がオンプレミスに配置されます。この構成は、AWSのフルマネージドEKSの管理機能を活用しつつ、ワークロードをオンプレミスで実行することができるため、運用負荷が最小化されます。
    • 管理負荷が少ない: EKSのコントロールプレーンはAWS側で管理されるため、インフラの管理が簡素化されます。データプレーン（ワークロードの実行）はオンプレミスですが、AWSによってバックエンドの運用が支えられ、管理がAWSに任せられます。

B. 会社のハードウェアにAmazon EKS Anywhereをインストールし、オンプレミスのデータセンターでEKS Anywhereクラスターを展開して生産ワークロードを実行します。

  • EKS Anywhereは、AWSが提供する、オンプレミスでKubernetesを実行するためのツールですが、これはAWSの管理されたサービスではありません。オンプレミスの環境でKubernetesクラスターを管理する責任が企業にあるため、管理負荷が増加します。
    • 管理負荷が高い: EKS Anywhereでは、Kubernetesのコントロールプレーンとデータプレーンが両方ともオンプレミスで管理され、AWSのフルマネージドサービスの利点が活かされません。

C. オンプレミスのデータセンターにAWS Outpostsサーバーをインストールし、Outpostsサーバー上で拡張クラスター構成を使用してAmazon EKSを展開し、生産ワークロードを実行します。

  • 拡張クラスター構成では、EKSのコントロールプレーンはAWSクラウドに配置され、データプレーン（ワークロード実行部分）はオンプレミスに配置されますが、クラスターの管理が異なるという点で、より複雑で運用負荷が増えます。
    • 運用負荷が増す可能性: これはローカルクラスター構成と比較して、コントロールプレーンとデータプレーンの運用の一貫性が欠ける場合があります。したがって、管理のシンプルさにおいては劣ることがあります。

D. オンプレミスのデータセンターにAWS Outpostsサーバーをインストールし、OutpostsサーバーにAmazon EKS Anywhereをインストールして、生産ワークロードをEKS Anywhereクラスターで実行します。

  • AWS Outpostsを使いながらEKS Anywhereをオンプレミスで運用する構成です。EKS Anywhereは、完全にオンプレミスでKubernetesを管理するため、AWSのフルマネージドサービスを活用できず、管理の負担が増大します。
    • 運用負荷が非常に高い: EKS Anywhereでは、Kubernetesの完全な管理を企業自身が行うことになり、AWSのマネージドサービスの恩恵を享受できません。

結論

A. が正解です。AWS Outpostsを使用して、EKSのローカルクラスター構成を採用することで、最小の運用負荷でAWSのフルマネージドKubernetesソリューションを活用できます。EKSのコントロールプレーンはAWSで管理され、データプレーンはオンプレミスで運用されるため、管理が簡素化され、運用負荷が最小化されます。
 
 
 

446-AWS SAP AWS 「理論・実践・一問道場」RAM

 

理論

AWS Organizations とマルチアカウントネットワーク接続のベストプラクティス

AWS Organizations を使用したマルチアカウント環境では、共有リソース（例: Aurora DB クラスター）へのアクセスを効率的に提供することが重要です。この目的を達成するために、以下の主要なアプローチとそのメリットを押さえておきましょう。

1. トランジットゲートウェイを活用したネットワーク接続

  • 概要: トランジットゲートウェイ（Transit Gateway）は、複数のアカウントや VPC を簡単かつ効率的に接続できるサービスです。
  • 利点:
    • 中央集権型のネットワーク管理が可能。
    • 各 VPC の CIDR ブロックが重複しない場合、スムーズな通信を実現。
    • AWS Resource Access Manager (AWS RAM) を使用して、簡単に他のアカウントと共有可能。
  • ユースケース: 共有サービスアカウント内のデータベースや共有アプリケーションリソースへのアクセス。

2. AWS Resource Access Manager (AWS RAM) の利用

  • 概要: AWS RAM は、リソースの共有を簡単に行うためのサービスです。特定のリソース（例: Transit Gateway、VPC エンドポイントなど）を他のアカウントと共有可能。
  • 利点:
    • シンプルなアクセス管理。
    • 複数アカウント環境でのリソース重複を削減。
  • 注意点: 直接共有できるリソースは限定されており、Aurora DB クラスターそのものは共有対象外。

3. AWS PrivateLink の使用

  • 概要: PrivateLink を使用すると、Amazon VPC 内のサービスに対してプライベート接続を提供できます。
  • 利点:
    • セキュリティが向上し、インターネット経由のトラフィックを回避。
    • 接続先が固定であり、サービスのエンドポイントとして使用可能。
  • 欠点:
    • エンドポイントサービスの設定が複雑。
    • 接続の柔軟性がトランジットゲートウェイに比べて低い。

4. Site-to-Site VPN の利用

  • 概要: AWS Site-to-Site VPN は、オンプレミス環境や別の AWS アカウント間でセキュアな接続を提供する手段です。
  • 利点:
    • VPN 接続によるセキュリティの確保。
  • 欠点:
    • 設定が複雑でコストが高い。
    • 複数アカウント環境での運用負荷が増大。

ベストプラクティス

  1. リソースの共有にはトランジットゲートウェイを活用:
      • 複数アカウント環境での効率的なネットワーク管理を実現。
  1. AWS RAM を使用してリソースを簡単に共有:
      • リソースの重複や運用負荷を最小限に。
  1. PrivateLink は限定的なユースケースで使用:
      • 接続先が特定のサービスに限られる場合に有効。
  1. VPN は最終手段として利用:
      • 他の方法が使えない場合のみ採用。

まとめ

AWS マルチアカウント環境では、効率性と運用負荷の低減を両立する設計が鍵です。トランジットゲートウェイと AWS RAM を組み合わせることで、多くのユースケースに対応可能です。

実践

略

一問道場

質問 #446

ある企業が、AWS Organizations を使用して開発環境を管理しています。各開発チームは独自の AWS アカウントを持っています。各アカウントには単一の VPC があり、CIDR ブロックは重複していません。
企業は、共有サービスアカウントに Amazon Aurora DB クラスターを所有しています。すべての開発チームが、この DB クラスターのライブデータを使用する必要があります。
最小限の運用負荷で DB クラスターへの接続を提供するソリューションはどれですか？
A.
AWS Resource Access Manager (AWS RAM) のリソース共有を作成し、DB クラスターをすべての開発アカウントと共有します。
B.
共有サービスアカウントでトランジットゲートウェイを作成します。AWS Resource Access Manager (AWS RAM) のリソース共有を作成し、トランジットゲートウェイをすべての開発アカウントと共有します。開発者にリソース共有を承認するよう指示し、ネットワーキングを設定します。
C.
DB クラスターの IP アドレスをポイントする Application Load Balancer (ALB) を作成します。AWS PrivateLink エンドポイントサービスを ALB を使用して作成します。各開発アカウントがエンドポイントサービスに接続できるよう、アクセス許可を追加します。
D.
共有サービスアカウントで AWS Site-to-Site VPN 接続を作成します。ネットワーク設定を行います。AWS Marketplace の VPN ソフトウェアを各開発アカウントで使用して、Site-to-Site VPN 接続に接続します。

解説

この問題は、AWS Organizations を使用して複数の開発アカウントから共有サービスアカウント内の Aurora DB クラスターに接続するための最適な方法を問うものです。選択肢ごとの解説は以下の通りです。

A. AWS Resource Access Manager (AWS RAM) を使用して DB クラスターを共有

AWS RAM は、リソースを共有するための便利なツールですが、Amazon Aurora DB クラスターそのものは直接共有することはできません。そのため、この選択肢は 不適切 です。

B. トランジットゲートウェイを使用してネットワーク接続を共有

トランジットゲートウェイは、複数のアカウントや VPC 間でネットワークを効率的に接続するための強力なソリューションです。AWS RAM を使用してトランジットゲートウェイを共有し、各開発アカウントの VPC を接続することで、Aurora DB クラスターへの接続を簡素化できます。ネットワークの一元管理が可能であり、最小限の運用負荷 で要件を満たすため、この選択肢は 適切 です。

C. Application Load Balancer (ALB) と AWS PrivateLink を使用

PrivateLink は、エンドポイントを通じて安全に接続を提供するためのサービスですが、ALB を用いて Aurora DB クラスターの IP アドレスに接続する設計は非効率です。PrivateLink の使用にはエンドポイントサービスの設定や許可の管理が必要であり、運用負荷が高くなるため、この選択肢は 不適切 です。

D. Site-to-Site VPN を使用

AWS Site-to-Site VPN を利用する方法は、Aurora DB クラスターにアクセスするためのコストと運用負荷が非常に高いです。また、各開発アカウントで VPN 接続を個別に設定する必要があり、ネットワークの複雑さが増します。このため、この選択肢は 不適切 です。

正解: B

  • トランジットゲートウェイを使用すると、各アカウントの VPC を効率的に接続できます。
  • AWS RAM を用いてトランジットゲートウェイを共有することで、運用負荷を最小限に抑えつつ、すべての開発アカウントが DB クラスターにアクセスできます。
 
 

447-AWS SAP AWS 「理論・実践・一問道場」Cost Anomaly Detection

 

理論

AWSでのコスト管理

AWSを利用する際、コストの増加を防ぎ効率的にリソースを管理することが重要です。以下は、コスト管理に関連する重要なポイントです。

1. 未使用リソースの特定

  • 未使用リソースの例:
    • 停止されたが削除されていないEC2インスタンス。
    • 利用されていないElastic IPやスナップショット。
    • 過剰にプロビジョニングされたストレージやデータベース。
  • 対策方法:
    • AWS Trusted Advisorを利用して未使用リソースを特定。
    • 定期的にリソース使用状況を確認する。

2. コスト異常検出

  • AWS Cost Anomaly Detection:
    • 機械学習を活用して、コストの異常を検出するサービス。
    • 「Linked account」や「AWS services」などのモニタータイプを選択可能。
    • 異常検出時にSNS経由で通知を送信。
  • メリット:
    • 異常なコスト増加を早期に検出。
    • 対応が遅れるリスクを軽減。

3. コスト予測とアラート設定

  • AWS Cost Explorer:
    • 過去の利用状況やコストトレンドを分析。
    • コストの予測値を確認可能。
  • Amazon CloudWatchアラーム:
    • 月々の請求額やリソースの利用量に基づくアラームを設定。
    • 特定のしきい値を超えた場合に通知を受け取る。

4. 自動化の活用

  • インフラ管理ツール:
    • AWS CloudFormationやTerraformを活用し、リソースのライフサイクルを管理。
    • 不要なリソースを自動削除するスクリプトの導入。
  • タグ付けポリシー:
    • リソースに環境（例: テスト、プロダクション）や所有者を示すタグを付与。
    • タグベースで未使用リソースをフィルタリング。

5. サービスごとのコスト最適化

  • Amazon EC2:
    • 必要以上のインスタンスサイズやリージョン選択に注意。
    • スポットインスタンスやリザーブドインスタンスの利用。
  • Amazon S3:
    • データライフサイクルポリシーを設定して古いデータをアーカイブ。
  • AWS Lambda:
    • メモリ割り当てや実行時間を最適化。

6. ベストプラクティス

  • 定期的なコストレビュー:
    • 毎月のAWS請求書を確認し、不審な増加がないかチェック。
  • 権限の制限:
    • IAMポリシーを適切に設定し、不要なリソース作成を防止。
  • 運用チームへの通知:
    • コストの異常や未使用リソースの情報を即時共有。
これらの知識を活用することで、AWS環境のコストを効率的に管理し、無駄な支出を防ぐことが可能です。

実践

略

一問道場

質問 #447

ある会社が、AWS CloudFormation を使用して、AWS メンバーアカウント内のすべての新しいインフラストラクチャを作成しました。リソースはほとんど変更されず、予想される負荷に対して適切なサイズになっています。月々のAWS請求額は一貫しています。
時折、開発者がテスト目的で新しいリソースを作成し、テストが終了した後にそのリソースを削除するのを忘れることがあります。これらのテストのほとんどは数日間しか続かず、その後リソースは不要になります。
会社は未使用のリソースを見つけるプロセスを自動化したいと考えています。ソリューションアーキテクトは、AWS請求書の費用が増加しているかどうかを判断できるソリューションを設計する必要があります。このソリューションは、費用の増加を引き起こすリソースを特定し、自動的に会社の運用チームに通知する必要があります。
以下のどのソリューションがこれらの要件を満たしますか？
A.
  • 請求アラートを有効化します。
  • AWS Cost Explorer を使用して、過去1か月のコストを特定します。
  • 推定総額のAmazon CloudWatchアラームを作成します。
  • Cost Explorer で特定したコストより高いコストしきい値を指定します。
  • アラームのしきい値が超えた場合、運用チームに通知が届くよう設定します。
B.
  • 請求アラートを有効化します。
  • AWS Cost Explorer を使用して、過去3か月間の平均月額コストを特定します。
  • 推定総額のAmazon CloudWatchアラームを作成します。
  • Cost Explorer で特定したコストより高いコストしきい値を指定します。
  • アラームのしきい値が超えた場合、運用チームに通知が届くよう設定します。
C.
  • AWS Cost Anomaly Detection を使用して、モニタータイプ「Linked account」のコストモニターを作成します。
  • 毎日、AWSコストサマリーを運用チームに送信するサブスクリプションを作成します。
  • コストの変動に対するしきい値を指定します。
D.
  • AWS Cost Anomaly Detection を使用して、モニタータイプ「AWS services」のコストモニターを作成します。
  • 毎日、AWSコストサマリーを運用チームに送信するサブスクリプションを作成します。
  • コストの変動に対するしきい値を指定します。

解説

背景

  • 会社はAWS CloudFormationを使用してインフラを作成し、通常はリソースがほとんど変更されません。
  • 時々、開発者がテスト目的で一時的なリソースを作成し、削除を忘れることでコストが増加します。
  • 会社の目標は、未使用リソースの検出を自動化し、コストの増加を引き起こすリソースを特定して通知することです。

選択肢の比較

  1. A: 請求アラート + CloudWatch アラーム (過去1か月のデータ)
      • メリット:
        • 過去1か月のコストを基にしたシンプルなコスト監視。
        • CloudWatchアラームによる通知が可能。
      • デメリット:
        • 短期間の異常を検出するには不十分。
        • コストが増加した理由やリソースの特定が難しい。
  1. B: 請求アラート + CloudWatch アラーム (過去3か月のデータ)
      • メリット:
        • 過去3か月間の平均コストを基にしており、より長期的な傾向を把握可能。
        • CloudWatchアラームによる通知が可能。
      • デメリット:
        • 短期間の異常検出には不向き。
        • どのリソースが問題を引き起こしているかを特定できない。
  1. C: AWS Cost Anomaly Detection (Linked account)
      • メリット:
        • アカウント全体のコスト異常を短期間で検出できる。
        • 毎日の通知により運用チームが迅速に対応可能。
      • デメリット:
        • コスト異常の原因が特定のAWSサービスに関連する場合、その詳細な内訳を把握するには追加の手間が必要。
  1. D: AWS Cost Anomaly Detection (AWS services)
      • メリット:
        • 各AWSサービスごとのコスト異常を検出できる。
        • 問題を引き起こしている具体的なリソースを特定しやすい。
        • 毎日の通知で迅速に対応可能。
      • デメリット:
        • サービス単位のモニタリングに絞られるため、アカウント全体の大局的な異常検出には追加のモニターが必要かもしれない。

最適な選択肢: D

  • 「AWS services」モニターを使用することで、コスト異常を引き起こす具体的なAWSサービスを特定でき、未使用リソースの削除という課題に直接対応可能です。
  • このアプローチは、短期間のテストリソースが原因で生じるコスト増加の特定に最適です。

ソリューションの流れ

  1. Cost Anomaly Detection の設定
      • 「AWS services」モニタータイプを選択。
      • 運用チームに送信する通知のしきい値を設定。
  1. 通知の自動化
      • 毎日AWSコストサマリーを運用チームに送信するサブスクリプションを作成。
      • 異常が検出された場合、アラートを発生させる。
  1. 運用チームのアクション
      • 通知を受け取り、不要なリソースを特定して削除。

補足情報

  • AWS Cost Anomaly Detectionは機械学習を活用しており、コストの増加や異常を動的に検出できます。
  • この機能を使うことで、請求アラートやCloudWatchアラームと比較して、より洗練されたコスト管理が可能になります。
 
 

448-AWS SAP AWS 「理論・実践・一問道場」Amazon EFS Multi-AZ

 

理論

Amazon EFS（Elastic File System）に関する汎用的知識

  1. EFSの特徴:
      • サーバーレス: ストレージ容量やパフォーマンスの管理が不要。自動的にスケーリングする。
      • ファイルシステム: 複数のEC2インスタンスやオンプレミスからファイルアクセスを可能にする。
      • 高可用性と耐障害性: 複数のアベイラビリティゾーン（AZ）でデータを自動的にレプリケートし、シームレスな可用性を提供。
  1. Multi-AZレプリケーション:
      • データは複数のAZ間でレプリケートされ、障害発生時でも高い可用性を提供。
      • 災害復旧: 他のAWSリージョンにレプリケーションを行うことで、災害復旧の要件（RPO）を達成可能。
  1. プロビジョンドスループット:
      • 必要なスループット（例：225 MiBps）を指定し、ピーク時の要求にも対応。
      • スループット管理: 容量やバーストキャパシティに依存せず、指定したスループットが保証される。
  1. 用途:
      • アプリケーションデータの共有、ログの集約、バックアップのストレージ、コンテンツ管理など。
      • 高可用性、スケーラビリティ、簡単な管理が求められるシナリオに最適。

他のストレージサービス（Amazon EBS, FSx for Lustre, FSx for OpenZFS）

  • EBSは単一のEC2インスタンスで利用するため、複数インスタンスの共有アクセスには不向き。
  • FSx for Lustreは計算集約型ワークロードに強みがあるが、並列書き込みアクセスが制限される。
  • FSx for OpenZFSは高性能を提供するが、管理が複雑でコストが高くなる可能性がある。
Amazon EFSは、スケーラブルで管理が容易なファイルストレージとして、複数インスタンス間でのデータ共有や高可用性・災害復旧が重要なシナリオに最適です。

実践

 
略

一問道場

問題 #448

ある企業が新しいウェブベースのアプリケーションを展開しており、Linuxアプリケーションサーバー用のストレージソリューションが必要です。企業は、すべてのインスタンスでアプリケーションデータの更新用の単一の場所を作成したいと考えています。アクティブなデータセットは最大で100GBのサイズになります。ソリューションアーキテクトは、ピーク操作が毎日3時間行われ、合計で225 MiBpsの読み取りスループットが必要であることを確認しました。
ソリューションアーキテクトは、データのバックアップを別のAWSリージョンに複製するMulti-AZソリューションを設計する必要があります。このDR（ディザスタリカバリ）コピーには、1時間未満のRPO（目標復旧時点）が必要です。
どのソリューションがこれらの要件を満たすでしょうか？
A. 新しいAmazon Elastic File System (Amazon EFS) Multi-AZファイルシステムを展開します。ファイルシステムのスループットを75 MiBpsに設定します。DRリージョンにあるファイルシステムに複製を実装します。
B. 新しいAmazon FSx for Lustreファイルシステムを展開します。ファイルシステムにバーストスループットモードを設定します。AWS Backupを使用してファイルシステムをDRリージョンにバックアップします。
C. 225 MiBpsのスループットを持つGeneral Purpose SSD（gp3）Amazon Elastic Block Store（Amazon EBS）ボリュームを展開します。EBSボリュームにMulti-Attachを有効にします。AWS Elastic Disaster Recoveryを使用してEBSボリュームをDRリージョンに複製します。
D. Amazon FSx for OpenZFSファイルシステムを本番リージョンとDRリージョンに展開します。AWS DataSyncのスケジュールされたタスクを作成し、10分ごとに本番ファイルシステムからDRファイルシステムにデータを複製します。

解説

この問題は、AWSのストレージサービスに関する選択肢から最適なソリューションを選ぶ問題です。要件としては、以下の条件が与えられています。

要件：

  1. データセットサイズ: 最大100GB
  1. ピークスループット: 3時間の日次ピークで、225 MiBpsの読み取りスループット
  1. Multi-AZ: 高可用性と耐障害性を確保するために、複数のアベイラビリティゾーン（AZ）でデータを管理
  1. 災害復旧（DR）: 別リージョンにデータを複製し、RPO（復旧時点目標）を1時間未満にする
この要件を満たす最適なソリューションを選ぶ必要があります。

各選択肢の解説：

A. Amazon EFS Multi-AZファイルシステム

  • 正解の理由: EFSは、要件に対して最も簡単でスケーラブルな解決策です。
    • サーバーレスのストレージ: Amazon EFSはサーバーレスでスケーラブルなファイルストレージであり、容量やパフォーマンスを自動的に調整します。これにより、アプリケーションデータを1つの場所で管理し、複数のインスタンスからアクセスすることができます。
    • Multi-AZレプリケーション: EFSは複数のアベイラビリティゾーン（AZ）にわたってデータをレプリケートすることで、高可用性と耐障害性を提供します。
    • プロビジョンドスループット: 必要なスループット（ここでは225 MiBps）をプロビジョニングすることが可能で、これによりピーク時のスループット要件を満たすことができます。
    • 災害復旧（DR）: EFSは別リージョンにデータをレプリケートすることができ、RPOを1時間未満に保ちながら災害復旧を実現できます。

B. Amazon FSx for Lustre

  • 不正解の理由:
    • FSx for Lustreは、計算集約型ワークロードに最適な高性能ストレージですが、複数のインスタンスからの同時書き込みアクセスをサポートしません。したがって、全インスタンスからのデータ共有には向いていません。
    • また、AWS Backupでバックアップを取ることはできますが、リアルタイムのデータ複製を提供せず、災害復旧に必要なRPOを満たしません。

C. Amazon EBS (gp3)ボリューム + AWS Elastic Disaster Recovery

  • 不正解の理由:
    • EBSは、EC2インスタンス専用のブロックストレージですが、複数のインスタンスからの並行アクセスをサポートしません（Multi-Attachを有効にした場合でも、同一AZ内のみ）。
    • EBSボリュームはMulti-AZレプリケーションをサポートせず、災害復旧に必要なRPO要件を満たすことができません。また、Elastic Disaster Recoveryはクロスリージョンでのデータ複製を提供しますが、リアルタイムでの同期は行われません。

D. Amazon FSx for OpenZFS + DataSync

  • 不正解の理由:
    • FSx for OpenZFSは高性能で強力なデータ管理機能を提供しますが、EFSに比べて管理が複雑でコストが高くなる可能性があります。
    • DataSyncを使ってデータを複製することはできますが、これは10分ごとの同期であり、リアルタイムのデータ複製には対応していません。1時間未満のRPOを維持するためには、連続的なデータ複製が必要ですが、DataSyncはそれをサポートしません。

結論：

最適な解決策はA. Amazon EFS Multi-AZファイルシステムです。これにより、アプリケーションデータの一元管理、複数インスタンスからのデータ共有、Multi-AZによる高可用性、リアルタイムの災害復旧が可能になります。EFSのシンプルでスケーラブルなアーキテクチャは、この問題の要件に最も適しています。
 
 

449-AWS SAP AWS 「理論・実践・一問道場」AWS Snowcone

 

理論

この問題に関連する汎用的な知識として、以下のポイントが挙げられます：

1. AWS Snowcone

  • AWS Snowconeはストレージデバイスです。具体的には、エッジコンピューティングとデータ転送を目的とした小型で携帯可能なストレージデバイスです。
  • AWS Snowconeは、エッジコンピューティングとストレージ向けの小型デバイスです。これを使用すると、ネットワーク接続がない場所でデータを保存し、後でAWSに転送できます。
  • デバイスは、最大8TBのデータを保存でき、持ち運び可能です。データ転送が完了した後、デバイスはAWSに返却してデータをクラウドストレージ（通常はS3）にアップロードできます。
  • ユースケース: オフライン環境でのデータ収集やエッジロケーションでのデータ処理。

2. FTP（File Transfer Protocol）

  • FTPは、ネットワーク上でファイルを転送するためのプロトコルです。多くのセンサーやシステムは、このプロトコルを使用してデータを定期的にアップロードします。
  • FTPサーバーは、データの受信場所として設定され、センサーはこのサーバーにファイルを送信します。AWS上でのデータ収集を自動化するには、FTPサーバーをデバイスにインストールしてセンサーが送信したデータを受け取る必要があります。

3. AWS EC2インスタンス

  • Amazon EC2（Elastic Compute Cloud）は、クラウド上で仮想サーバー（インスタンス）を提供するサービスです。これを利用して、FTPサーバーをホスティングしたり、スクリプトでデータの収集や転送処理を行ったりできます。
  • EC2インスタンスは、SnowconeやSnowballデバイス内で起動し、外部データソースからのデータ収集・転送の役割を果たします。

4. データ転送と同期

  • AWS DataSyncは、オンプレミスのストレージとAWS間、またはAWSサービス間でデータを高速で同期・転送するサービスです。大量のデータを効率よく移動させるために使用されますが、リアルタイムでのデータ転送には向いていません。特に、バックグラウンドで定期的な同期を行うことに向いています。

5. Amazon S3

  • Amazon S3（Simple Storage Service）は、AWSのオブジェクトストレージサービスで、大量のデータを保存するのに非常に適しています。センサーからデータを定期的にアップロードし、後でクラウドに転送するのに利用できます。
  • オフラインデータ収集において、Snowconeなどのデバイスから直接S3にデータを転送するのは非常に便利で効率的です。

まとめ

AWS Snowconeを使用してオフラインでデータを収集し、FTPサーバーを利用してセンサーからのデータを受信後、データをAmazon S3に転送するアプローチは、ネットワーク接続がないリモート環境で効率的にデータを収集し、クラウドへ移行する方法として最適です。

実践

略

一問道場

質問 #449
ある会社は、インターネット接続のない遠隔地で実験データを収集する必要があります。実験中、センサーがローカルネットワークに接続されており、1週間で6 TBのデータを専用フォーマットで生成します。センサーはデータファイルを定期的にFTPサーバーにアップロードするように設定できますが、センサー自身にはFTPサーバーがありません。また、センサーは他のプロトコルをサポートしていません。会社はデータを中央で収集し、できるだけ早くAWSクラウドのオブジェクトストレージにデータを移動する必要があります。
どのソリューションがこの要件を満たしますか？
A. AWS Snowball Edge Compute Optimizedデバイスを注文します。デバイスをローカルネットワークに接続します。AWS DataSyncをターゲットバケット名で設定し、データをNFS経由でデバイスに転送します。実験後、デバイスをAWSに返却して、データをAmazon S3にロードします。
B. AWS Snowconeデバイスを注文し、Amazon Linux 2 AMIを含めます。デバイスをローカルネットワークに接続します。デバイス上でAmazon EC2インスタンスを起動します。シェルスクリプトを作成して、各センサーからデータを定期的にダウンロードします。実験後、デバイスをAWSに返却し、データをAmazon Elastic Block Store（Amazon EBS）ボリュームとしてロードします。
C. AWS Snowconeデバイスを注文し、Amazon Linux 2 AMIを含めます。デバイスをローカルネットワークに接続します。デバイス上でAmazon EC2インスタンスを起動します。FTPサーバーをインストールして構成し、センサーがEC2インスタンスにデータをアップロードするように設定します。実験後、デバイスをAWSに返却して、データをAmazon S3にロードします。
D. AWS Snowconeデバイスを注文します。デバイスをローカルネットワークに接続します。デバイスをAmazon FSxを使用するように設定します。センサーがデバイスにデータをアップロードするように設定します。AWS DataSyncをデバイスで構成し、アップロードされたデータをAmazon S3バケットと同期させます。デバイスをAWSに返却して、データをAmazon Elastic Block Store（Amazon EBS）ボリュームとしてロードします。

解説

この問題の解説を行います。

要件の確認:

  • インターネット接続がない遠隔地でデータを収集する。
  • センサーはFTPを使って定期的にデータをアップロードする。
  • 収集したデータをAWSのオブジェクトストレージ（Amazon S3）に移動する。
  • データは実験後にAWSに移行される必要がある。
  • センサーはFTPサーバーを持っていない。

適切なソリューション:

正しい選択肢は C です。

理由:

  1. AWS Snowconeデバイス:
      • Snowconeは、小型で移動可能なストレージデバイスです。このデバイスを使用すると、オフライン環境でデータを保存し、後でAWSに転送できます。
      • Amazon EC2インスタンスをデバイス上で起動し、その中にFTPサーバーをインストールして、センサーがFTP経由でデータをアップロードできるようにします。これにより、センサーはデータをFTPで送信できるようになります。
      • 実験後、データをAmazon S3に転送するためにデバイスをAWSに返却します。これが最も簡単でスムーズな方法です。

他の選択肢の問題点:

  • A:
      • Snowball Edge Compute Optimizedは大規模データ転送向けで、NFSを利用してデータをアップロードする方法です。しかし、センサーはFTPしかサポートしておらず、NFSに直接データをアップロードできません。このため、センサーが直接データをSnowball Edgeにアップロードすることができません。
  • B:
      • SnowconeにEC2インスタンスを立てて、シェルスクリプトでデータをダウンロードする方法ですが、センサーがFTPを使う必要があり、またデータをダウンロードしてEBSに保存する設計は、データ転送の効率や後処理の点で最適ではありません。Snowcone自体がFTPの受け入れに適していないため、最適ではないです。
  • D:
      • Amazon FSxは高性能なファイルシステムであり、特に大規模なデータのストレージに使用されますが、この問題の要件には不要です。また、DataSyncで同期させる方法は、FTPのサポートが前提となるため、実装が複雑で効率が悪くなります。SnowconeはFTPサーバーとしての利用に適しており、FSxはこのユースケースには適しません。

結論:

選択肢Cが最適です。AWS Snowconeデバイスを使用し、EC2インスタンスにFTPサーバーをインストールすることで、センサーがデータをFTP経由でアップロードでき、実験後にデータをAmazon S3に転送できます。
 
 

450-AWS SAP AWS 「理論・実践・一問道場」CUR

 

理論

  1. AWS Cost and Usage Report (CUR)
      • *Cost and Usage Report (CUR)**は、AWSアカウントの使用状況やコストを詳細に追跡できるレポートです。これには、サービスごとのコストや使用量が含まれます。レポートはS3バケットに配信され、AthenaやRedshiftを使ってクエリを実行できます。
      • AWS Athenaは、S3バケットに保存されたCURデータをクエリして分析できるインタラクティブなクエリエンジンです。これを使用して、複数アカウントのコスト分析を行うことができます。
  1. AWS Organizations
      • AWS Organizationsを使用すると、複数のAWSアカウントを一元管理し、リソースやポリシーを共有できます。コスト管理においても、Organizationsを使用して全アカウントのコストデータを集約し、特定のアカウントや部門ごとにコスト分析を行うことができます。
  1. S3バケットとアクセス管理
      • S3バケットは、AWSのストレージサービスであり、コストレポートやその他のデータを格納するために使用されます。適切なアクセス制御を設定することで、各アカウントやユーザーに対してデータへのアクセス権限を管理できます。
      • S3バケットのアクセスは、IAMポリシー、バケットポリシー、またはS3アクセスポイントを使用して制御できます。
  1. AWS Cost Explorerとレポート
      • AWS Cost Explorerは、コストと使用状況を視覚化するツールで、さまざまなフィルターや視点でコストデータを分析できます。個別のレポートを作成して、アカウントごとの詳細なコスト情報を表示できますが、複数のアカウントで集中管理したい場合には、CURを使用した方が一元管理がしやすいです。
運用の最適化
  • 複数のAWSアカウントでコストを一元管理する場合、AWS OrganizationsとCost and Usage Reportを使用して、すべてのデータを集約し、必要なアカウントに対して適切なアクセス権限を設定することが重要です。最小限の運用の複雑さを保ちながら、管理とアクセスを簡素化できます。

実践

略

一問道場

会社には複数の事業部門があり、AWS Organizationsを使用してすべての機能が有効化されています。各事業部門には独自のAWSアカウントがあり、各アカウントの管理者はAmazon Athenaを使用して自分のアカウントの詳細なコストと利用状況データを表示する必要があります。各事業部門は自分のコストと利用状況データのみを閲覧できる必要があります。AWS Cost and Usage Reportsの設定を管理するためのIAMポリシーは既に設定されています。また、組織全体のデータを含む中央のコストと利用状況レポートが既にAmazon S3バケットに格納されています。 この要件を最小限の運用の複雑さで満たすための解決策はどれですか？
A. 組織の管理アカウントで、AWS Resource Access Manager (AWS RAM)を使用して、各メンバーアカウントとコストと利用状況レポートデータを共有します。
B. 組織の管理アカウントで、S3バケットに新しいファイルが到着するたびにAWS Lambda関数を呼び出すS3イベントを設定します。Lambda関数を設定して、各メンバーアカウントのデータを抽出し、それを別のプレフィックスでAmazon S3に配置します。S3バケットポリシーを変更して、各メンバーアカウントが自分のプレフィックスにアクセスできるようにします。
C. 各メンバーアカウントで、AWS Cost Explorerにアクセスし、アカウントに関連するコスト情報を含む新しいレポートを作成します。レポートをCost Explorerに保存します。アカウント管理者が保存されたレポートにアクセスするための手順を提供します。
D. 各メンバーアカウントで、Cost and Usage Reportデータを保存するための新しいS3バケットを作成します。新しいS3バケットにデータを配信するようにCost and Usage Reportを設定します。

解説

この問題では、各事業部門の管理者が、自分のアカウントのコストと利用状況データを確認する必要があります。AWS Athenaを使用してデータを確認できるようにするため、最小限の運用の複雑さでソリューションを提供する必要があります。
選択肢の解説:
  • A. AWS Resource Access Manager (AWS RAM)でデータを共有
    • この選択肢では、AWS RAMを使ってコストと利用状況レポートのデータを各メンバーアカウントに共有することを提案しています。しかし、AWS RAMは、リソース（VPCやTransit Gatewayなど）を共有するために使用されるもので、S3バケットのデータに対しては直接的な方法ではありません。したがって、この解決策は適切ではありません。
  • B. S3イベントとLambda関数を使用してデータを抽出
    • S3イベントをトリガーとしてLambda関数を使い、レポートのデータを抽出して各アカウントごとに保存する方法です。この方法は動的で柔軟ですが、運用の複雑さが増します。Lambda関数の設定、S3のプレフィックス管理、バケットポリシーの設定が必要で、運用がやや複雑になります。
  • C. AWS Cost Explorerで個別にレポートを作成
    • この選択肢では、各アカウントの管理者がAWS Cost Explorerでレポートを作成し、それを保存してアクセスできるようにする提案です。しかし、この方法では各アカウントごとに手動で設定が必要で、組織全体での一元的な管理が欠けるため、最小限の運用の複雑さにはなりません。
  • D. 各メンバーアカウントに新しいS3バケットを作成
    • 各メンバーアカウントに専用のS3バケットを作成し、Cost and Usage Reportをそのバケットに配信する方法です。AWS Organizationsを使用すると、各アカウントごとにレポートを配信でき、アクセス権限の管理が容易です。この方法は、シンプルで効果的であり、運用の複雑さを最小限に抑えられるため、最適な解決策です。
結論: 最小限の運用の複雑さで要件を満たすための解決策は D です。各メンバーアカウントに専用のS3バケットを作成し、コストと利用状況レポートをそのバケットに配信することで、シンプルで効果的なデータ管理が可能になります。
 
 
Relate Posts
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
初心者向け！コンテナ化WordPressサイト構築ガイド（超詳細版）
Lazy loaded image
EFSを活用！AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
00-AWS SAP「理論・実践・10問道場」
Lazy loaded image
01-AWS SAP「理論・実践・10問道場」
Lazy loaded image
02-AWS SAP「理論・実践・10問道場」
Lazy loaded image
43-AWS SAP「理論・実践・10問道場」45-AWS SAP「理論・実践・10問道場」
Loading...
Catalog
0%
minami
minami
一个普通的干饭人🍚
Announcement

🎉 ブログへようこそ 🎉

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

📚 主な内容

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

🔍 コンテンツの探し方

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