5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

背景

初心に帰って、「AWS 設計のベストプラクティスで最低限知っておくべき 10 (+1) のこと」 の動画コンテンツを閲覧し、内容を整理しました。とても良い内容だったので、自分なりに整理しなおして、理解度チェックが出来るように問題も作成しました。 元ネタと併せて、ご利用する事で、AWS 設計のベストプラクティスに関する知識を深めてください。

目次

  1. スケーラビリティを確保する
  2. 環境を自動化する
  3. 使い捨て可能なリソースを使用する
  4. コンポーネントを疎結合にする
  5. サーバーではなくサービスで設計する
  6. 適切なデータベースソリューションを選択する
  7. 単一障害点を排除する
  8. コストを最適化する
  9. キャッシュを使用する
  10. すべてのレイヤーでセキュリティを確保する
  11. 増加するデータの管理を行う

スケーラビリティを確保する

Auto Scalingの利用 Auto Scalingを使用することで、アラームしきい値に達した際に自動的にスケールアウトし、キャパシティーが上限に達する前に新しいサーバーの準備が整います。これにより、ユーザーがアクセスできない状態を防ぐことができます。

アンチパターン

手動でのサーバー起動 アプリケーションサーバーがキャパシティーの上限に到達した際に、管理者が手動で新しいサーバーを起動する方法は、時間がかかり、ユーザーがアクセスできない状態が発生する可能性があります。

スケーラビリティとは
ソフトウェアやシステムなどの拡張性、拡張可能性を示す言葉であり、システムの利用や負荷の増大、用途の拡大などに応じて、どれだけ柔軟に性能や機能を向上、拡張できるかを表しています。
Auto Scaling
事前設定したしきい値に合わせて、Amazon EC2インスタンス(仮想サーバー)等のリソースの増減を自動化できるサービスです。

項目 ベストプラクティス アンチパターン
サーバーの起動方法 Auto Scalingを使用して自動的にスケールアウトする。 管理者が手動で新しいサーバーを起動する。
キャパシティー管理 キャパシティーが上限に達する前に新しいサーバーの準備が整っている。 新しいサーバーの起動には時間がかかり、ユーザーがアクセスできない状態が発生する。
柔軟性と拡張性 システムの利用や負荷の増大に応じて柔軟に性能や機能を向上、拡張できる。 手動での対応が必要なため、柔軟性と拡張性に欠ける。

問題文

スケーラビリティを確保するためのベストプラクティスに該当するものを選んでください。

選択肢

A. アプリケーションサーバーがキャパシティーの上限に到達した際に、管理者が手動で新しいサーバーを起動する。
B. Auto Scalingを使用して、アラームしきい値に達したアプリケーションサーバーを自動的にスケールアウトする。
C. 新しいサーバーの起動には時間がかかるため、ユーザーがアクセスできない状態が発生する。
D. アプリケーションサーバーがキャパシティーの上限に達する前に、新しいサーバーの準備が整っている。

正解

B. Auto Scalingを使用して、アラームしきい値に達したアプリケーションサーバーを自動的にスケールアウトする。
D. アプリケーションサーバーがキャパシティーの上限に達する前に、新しいサーバーの準備が整っている。

環境を自動化する

Amazon CloudWatchの利用 Amazon CloudWatchを使用することで、異常のあるインスタンスを自動的に検出し、管理者に通知することができます。
Auto Scalingの利用 Auto Scalingを使用して、アラートを受信した際に自動的に同じサーバーを起動して設定することができます。
変更管理ソリューションの利用 変更管理ソリューションにアクションを自動的に記録することで、変更履歴を管理しやすくなります。

アンチパターン

手動でのサーバー起動と設定 アプリケーションサーバーがクラッシュした際に、管理者が手動で新しいサーバーを起動して設定する方法は、時間がかかり、効率が悪いです。
手動での通知 ユーザーが手動で管理者に通知する方法は、迅速な対応が難しくなります。

プロビジョニングとは
システムやサービスへの需要に対して、資源の割り当てや設定を行い、利用や運用が可能な状態にすることです。

項目 ベストプラクティス アンチパターン
サーバーの起動方法 Auto Scalingを使用して自動的に同じサーバーを起動して設定する。 管理者が手動で新しいサーバーを起動して設定する。
異常検出と通知 Amazon CloudWatchを使用して異常のあるインスタンスを自動的に検出し、管理者に通知する。 ユーザーが手動で管理者に通知する。
変更管理 変更管理ソリューションにアクションを自動的に記録する。 変更管理が手動で行われ、記録が不完全になる可能性がある。

問題文

環境を自動化するためのベストプラクティスに該当するものを選んでください。

選択肢

A. アプリケーションサーバーがクラッシュした際に、管理者が手動で新しいサーバーを起動して設定する。
B. Amazon CloudWatchによって異常のあるインスタンスが自動的に検出され、管理者に通知される。
C. ユーザーが手動で管理者に通知する。
D. Auto Scalingにアラートを送信し、自動的に同じサーバーを起動して設定するようにする。
E. 変更管理ソリューションにアクションを自動的に記録する。

正解

B. Amazon CloudWatchによって異常のあるインスタンスが自動的に検出され、管理者に通知される。
D. Auto Scalingにアラートを送信し、自動的に同じサーバーを起動して設定するようにする。
E. 変更管理ソリューションにアクションを自動的に記録する。

使い捨て可能なリソースを使用する

ステートレスサーバー サーバーには状態(ステート)を持たせず、必要に応じていつでも捨てられるようにします。これにより、サーバーのスケーリングや置き換えが容易になります。
ラベル(タグ)での管理 クラウド環境では、リソース1つ1つに名前を付けるのではなく、ラベル(タグ)を使用して管理します。これにより、リソースの管理が簡単になります。

アンチパターン

名前を付けて管理 クラウド環境でリソース1つ1つに名前を付けて管理する方法は、管理が煩雑になり、スケーラビリティが低下します。
不要なリソースの稼働 必要でないときにもリソースが稼働している状態は、コストの無駄遣いとなります。

使い捨て可能なリソース
クラウドではいつでも捨てられるようにリソースを準備しておくことが重要です。リソースはラベル(タグ)で管理し、サーバーには状態(ステート)を持たせない(ステートレス)ように設計します。

項目 ベストプラクティス アンチパターン
リソースの管理方法 クラウドではリソースをラベル(タグ)で管理する。 クラウドではリソース1つ1つに名前を付けて管理する。
サーバーの状態 サーバーには状態(ステート)を持たせない(ステートレス)。 サーバーに状態(ステート)を持たせる。
リソースの稼働状況 必要でないリソースは終了する。 必要でないときにもリソースが稼働している。
IPアドレスの管理 新しいIPアドレスに自動的に切り替える。 IPアドレスの固定により柔軟性が失われている。
更新とテスト 新しいリソースの更新内容をテストしてから、古いリソースを置き換える。 使用中のハードウェアで新しい更新をテストすることが難しく不便である。

問題文

使い捨て可能なリソースを使用するためのベストプラクティスに該当するものを選んでください。

選択肢

A. クラウドではリソース1つ1つに名前を付けて管理する。
B. サーバーには状態(ステート)を持たせない(ステートレス)。
C. オンプレミス環境ではサーバー1台1台に名前を付ける。
D. クラウドではリソースをラベル(タグ)で管理する。
E. 必要でないときにもリソースが稼働している。

正解

B. サーバーには状態(ステート)を持たせない(ステートレス)。
D. クラウドではリソースをラベル(タグ)で管理する。

コンポーネントを疎結合にする

コンポーネントの細分化 処理種別やデータ特性ごとにコンポーネントを細分化することで、各コンポーネントの独立性を高めます。
データの分離 データは常にデータストアに格納し、処理側には持たせないようにします。これにより、データの一貫性と可用性が向上します。
依存関係の弱化 システムの構成要素間の結びつきや依存関係を弱くすることで、各コンポーネントの独立性を高め、変更や障害時の影響を最小限に抑えます。

アンチパターン

依存関係の強化 システムの構成要素間の結びつきや依存関係を強くする方法は、各コンポーネントの独立性を低下させ、変更や障害時の影響が大きくなります。
コンポーネントの統合 すべてのコンポーネントを1つのサーバーにまとめる方法は、スケーラビリティや可用性が低下します。

疎結合とは
システムの構成要素(コンポーネント)間の結びつきや依存関係が弱く、各々の独立性が高い状態のことです。
密結合とは
システムの構成要素(コンポーネント)間の結びつきや依存関係が強く、各々の独立性が低い状態のことです。

項目 ベストプラクティス アンチパターン
依存関係 システムの構成要素間の結びつきや依存関係を弱くする。 システムの構成要素間の結びつきや依存関係を強くする。
コンポーネントの細分化 処理種別やデータ特性ごとにコンポーネントを細分化する。 すべてのコンポーネントを1つのサーバーにまとめる。
データの管理 データは常にデータストアに格納し、処理側には持たせない。 データを処理側に持たせる。
障害時の対応 障害ポイントが判別しやすく、必要な部分のみに変更を適用できる。 障害ポイントが判別しにくく、全体に影響が及ぶ。

問題文

コンポーネントを疎結合にするためのベストプラクティスに該当するものを選んでください。

選択肢

A. システムの構成要素間の結びつきや依存関係を強くする。
B. 処理種別やデータ特性ごとにコンポーネントを細分化する。
C. データは常にデータストアに格納し、処理側には持たせない。
D. システムの構成要素間の結びつきや依存関係を弱くする。
E. すべてのコンポーネントを1つのサーバーにまとめる。

正解

B. 処理種別やデータ特性ごとにコンポーネントを細分化する。
C. データは常にデータストアに格納し、処理側には持たせない。
D. システムの構成要素間の結びつきや依存関係を弱くする。

サーバーではなくサービスで設計する

メッセージキューの利用 メッセージキューを使用してアプリケーション間の通信を処理することで、アプリケーションの疎結合を実現し、スケーラビリティと可用性を向上させます。
マネージドサービスの利用 ユーザー認証やユーザー状態の保存には、AWSのマネージドサービスを使用することで、運用管理の負担を軽減し、セキュリティと可用性を向上させます。
サーバーレスソリューションの利用 必要に応じてサーバーレスソリューションをプロビジョニングすることで、インフラストラクチャの管理を最小限に抑え、スケーラビリティとコスト効率を向上させます。

アンチパターン

永続的なサーバー実行 シンプルなアプリケーションを永続的にサーバー上で実行する方法は、スケーラビリティや可用性が低下し、運用管理の負担が増加します。
ローカルインスタンスへの保存 静的ウェブアセットをローカルのインスタンスに保存する方法は、スケーラビリティや可用性が低下し、データの一貫性が保たれにくくなります。

マネージドサービス
AWSにおけるマネージドサービスは、耐障害性や可用性が組み込まれており、テクノロジーをサービスとして活用できるものです。例えば、Elastic Load Balancingを使用することで、リクエストの負荷分散制御に集中でき、ロードバランサーの運用管理やキャパシティコントロールはAWSに任せることができます。

項目 ベストプラクティス アンチパターン
アプリケーションの実行 必要に応じてサーバーレスソリューションをプロビジョニングする。 シンプルなアプリケーションを永続的にサーバー上で実行する。
通信の処理 メッセージキューを使用してアプリケーション間の通信を処理する。 アプリケーション間で直接通信が行われる。
データの保存 静的ウェブアセットはAmazon S3などの外部のデータストアに保存する。 静的ウェブアセットはローカルのインスタンスに保存する。
ユーザー認証と状態管理 ユーザー認証とユーザー状態の保存にはAWSのマネージドサービスを使用する。 ユーザー認証とユーザー状態の保存はバックエンドサーバーによって処理される。

問題文

サーバーではなくサービスで設計するためのベストプラクティスに該当するものを選んでください。

選択肢

A. シンプルなアプリケーションを永続的にサーバー上で実行する。
B. メッセージキューを使用してアプリケーション間の通信を処理する。
C. 静的ウェブアセットはローカルのインスタンスに保存する。
D. ユーザー認証とユーザー状態の保存にはAWSのマネージドサービスを使用する。
E. 必要に応じてサーバーレスソリューションをプロビジョニングする。

正解

B. メッセージキューを使用してアプリケーション間の通信を処理する。
D. ユーザー認証とユーザー状態の保存にはAWSのマネージドサービスを使用する。
E. 必要に応じてサーバーレスソリューションをプロビジョニングする。

適切なデータベースソリューションを選択する

ワークロードに基づいてテクノロジーを選択する テクノロジーに基づいてワークロードを選択するのではなく、ワークロードに基づいて最適なテクノロジーを選択します。これにより、ワークロードの要件に最適なデータベースソリューションを選ぶことができます。
レイテンシーの要件を考慮する データベースの選択において、レイテンシーの要件を考慮することが重要です。低レイテンシーが求められる場合は、それに適したデータベースソリューションを選択します。
最大同時接続ユーザー数を考慮する データベースがサポートできる最大同時接続ユーザー数を考慮し、スケーラビリティの高いソリューションを選択します。

アンチパターン

テクノロジーに基づいてワークロードを選択する テクノロジーに基づいてワークロードを選択する方法は、ワークロードの要件に最適なソリューションを選ぶことができず、パフォーマンスやスケーラビリティに問題が生じる可能性があります。
クエリの特性を無視する クエリの特性を無視することは、データベースのパフォーマンスに悪影響を与える可能性があります。

検討事項
データベースソリューションを選択する際には、レイテンシーの要件、サポートされる最大同時接続ユーザー数、クエリの特性、必要とされる整合性統制の強度、読み取りと書き込みのニーズ、必要なストレージの合計サイズ、オブジェクトの標準的なサイズとオブジェクトへのアクセスの特性、耐久性の要件などを考慮します。

項目 ベストプラクティス アンチパターン
選択基準 ワークロードに基づいてテクノロジーを選択する。 テクノロジーに基づいてワークロードを選択する。
レイテンシーの要件 レイテンシーの要件を考慮する。 レイテンシーの要件を無視する。
同時接続ユーザー数 サポートされる最大同時接続ユーザー数を考慮する。 同時接続ユーザー数を考慮しない。
クエリの特性 クエリの特性を考慮する。 クエリの特性を無視する。
整合性統制の強度 必要とされる整合性統制の強度を考慮する。 整合性統制の強度を無視する。
読み取りと書き込みのニーズ 読み取りと書き込みのニーズを考慮する。 読み取りと書き込みのニーズを無視する。
ストレージの合計サイズ 必要なストレージの合計サイズを考慮する。 ストレージの合計サイズを無視する。
オブジェクトのサイズとアクセス特性 オブジェクトの標準的なサイズとオブジェクトへのアクセスの特性を考慮する。 オブジェクトのサイズとアクセス特性を無視する。
耐久性の要件 耐久性の要件を考慮する。 耐久性の要件を無視する。

問題文

適切なデータベースソリューションを選択するためのベストプラクティスに該当するものを選んでください。

選択肢

A. テクノロジーに基づいてワークロードを選択する。
B. ワークロードに基づいてテクノロジーを選択する。
C. レイテンシーの要件を考慮する。
D. サポートされる最大同時接続ユーザー数を考慮する。
E. クエリの特性を無視する。

正解

B. ワークロードに基づいてテクノロジーを選択する。
C. レイテンシーの要件を考慮する。
D. サポートされる最大同時接続ユーザー数を考慮する。

単一障害点を排除する

冗長性の実装 冗長性を実装することで、単一の障害によってシステム全体が停止するのを避けることができます。例えば、複数のアプリケーションサーバーやデータベースサーバーを使用して冗長性を確保します。
逆算して設計 すべてのものは故障するものと考え、逆算して設計することで、障害が発生した際の影響を最小限に抑えることができます。
セカンダリデータベースサーバーの作成 セカンダリ(スタンバイ)データベースサーバーを作成し、データをレプリケートすることで、プライマリサーバーがオフラインになった場合でもセカンダリサーバーが負荷を引き継ぐことができます。

アンチパターン

単一障害点の存在 システムの全体が停止する可能性のある単一障害点を持つことは、システムの可用性を低下させます。
単一のデータベースサーバーに依存 単一のデータベースサーバーに依存することは、障害が発生した際にシステム全体が停止するリスクを高めます。

単一障害点(SPOF)とは
その箇所が停止するとシステムの全体が停止するような箇所のことです。SPOFを排除するためには、冗長性を実装し、すべてのものは故障するものと考えて設計することが重要です。

項目 ベストプラクティス アンチパターン
冗長性の実装 冗長性を実装して、単一の障害によってシステム全体が停止するのを避ける。 システムの全体が停止する可能性のある単一障害点を持つ。
設計のアプローチ すべてのものは故障するものと考え、逆算して設計する。 故障の可能性を考慮せずに設計する。
データベースの冗長性 セカンダリ(スタンバイ)データベースサーバーを作成して、データをレプリケートする。 単一のデータベースサーバーに依存する。
障害時の対応 障害が発生した際にセカンダリサーバーが負荷を引き継ぐ。 障害が発生した際にシステム全体が停止する。

問題文

単一障害点を排除するためのベストプラクティスに該当するものを選んでください。

選択肢

A. システムの全体が停止する可能性のある単一障害点を持つ。
B. 冗長性を実装して、単一の障害によってシステム全体が停止するのを避ける。
C. すべてのものは故障するものと考え、逆算して設計する。
D. 単一のデータベースサーバーに依存する。
E. セカンダリ(スタンバイ)データベースサーバーを作成して、データをレプリケートする。

正解

B. 冗長性を実装して、単一の障害によってシステム全体が停止するのを避ける。
C. すべてのものは故障するものと考え、逆算して設計する。
E. セカンダリ(スタンバイ)データベースサーバーを作成して、データをレプリケートする。

コストを最適化する

リソースの使用頻度のモニタリング: リソースの使用頻度を定期的にモニタリングすることで、不要なリソースを特定し、コストを削減することができます。
マネージドサービスの利用: サーバーのいずれかをマネージドサービスに置き換えることで、運用管理の負担を軽減し、コストを最適化することができます。
リソースの適切なサイズとタイプの選択: リソースのサイズとタイプがジョブに適しているかを確認し、最適なリソースを選択することで、コストを削減することができます。
コストエクスプローラーの活用: コストエクスプローラーを活用して日々の利用料金を把握することで、コストの可視化と管理が容易になります。

アンチパターン

使⽤されていないリソースの稼働 使⽤されていないリソースを常に稼働させておくことは、無駄なコストを発生させる原因となります。

AWSのコスト特性
AWSでは初期投資が不要であり、従量課金制(変動費)を採用しています。TCO(総所有コスト)を考慮し、システムや資産の維持管理のために必要なランニングコストも含めてコストを最適化します。
コストエクスプローラー
コストエクスプローラーは、毎月または毎日のコストを7日間から最大1年間表示可能なコスト可視化ツールです。

項目 ベストプラクティス アンチパターン
リソースの使用頻度 リソースの使用頻度を定期的にモニタリングする。 使⽤されていないリソースを常に稼働させておく。
マネージドサービスの利用 サーバーのいずれかをマネージドサービスに置き換えることを検討する。 すべてのサーバーを手動で管理する。
リソースの適切な選択 リソースのサイズとタイプがジョブに適しているかを確認する。 リソースのサイズとタイプを無視して選択する。
コストの可視化 コストエクスプローラーを活用して日々の利用料金を把握する。 コストの可視化を行わない。

問題文

コストを最適化するためのベストプラクティスに該当するものを選んでください。

選択肢

A. リソースの使⽤頻度を定期的にモニタリングする。
B. サーバーのいずれかをマネージドサービスに置き換えることを検討する。
C. リソースのサイズとタイプがジョブに適しているかを確認する。
D. 使⽤されていないリソースを常に稼働させておく。
E. コストエクスプローラーを活用して日々の利用料金を把握する。

正解

A. リソースの使⽤頻度を定期的にモニタリングする。
B. サーバーのいずれかをマネージドサービスに置き換えることを検討する。
C. リソースのサイズとタイプがジョブに適しているかを確認する。
E. コストエクスプローラーを活用して日々の利用料金を把握する。

キャッシュを使用する

CDNの利用 CDN(Contents Delivery Network)を使用して、クライアントに近いエッジサーバーにコンテンツをキャッシュすることで、レイテンシーを低減し、アクセス速度を向上させます。
インメモリデータベースの利用 インメモリデータベース(Memcached, Redisなど)を使用して、データをメインメモリに保存することで、ディスクやSSDに比べて高速なアクセスを実現します。

アンチパターン

直接リクエスト データが保存されているAmazon S3バケットに対して、毎回直接リクエストを送信する方法は、レイテンシーが高くなり、コストも増加します。
キャッシュを使用しない キャッシュを使用せずに、すべてのデータをディスクやSSDに保存する方法は、アクセス速度が遅くなり、システムのパフォーマンスが低下します。

キャッシュとは
一度アクセスしたデータを一時的に保管し、次回アクセス時により高速にアクセスする仕組みです。Webアプリケーションにおけるキャッシュの例として、CDNやインメモリデータベースがあります。

項目 ベストプラクティス アンチパターン
CDNの利用 CDNを使用して、クライアントに近いエッジサーバーにコンテンツをキャッシュする。 データが保存されているAmazon S3バケットに対して、毎回直接リクエストを送信する。
インメモリデータベース インメモリデータベースを使用して、データをメインメモリに保存する。 キャッシュを使用せずに、すべてのデータをディスクやSSDに保存する。
データの読み取り キャッシュを使用して、重複するデータ取り出しオペレーションを最小限にする。 データベースに対するすべての読み取りリクエストを直接データベースに送信する。

問題文

キャッシュを使用するためのベストプラクティスに該当するものを選んでください。

選択肢

A. データが保存されているAmazon S3バケットに対して、毎回直接リクエストを送信する。
B. CDN(Contents Delivery Network)を使用して、クライアントに近いエッジサーバーにコンテンツをキャッシュする。
C. インメモリデータベース(Memcached, Redisなど)を使用して、データをメインメモリに保存する。
D. データベースに対するすべての読み取りリクエストを直接データベースに送信する。
E. キャッシュを使用せずに、すべてのデータをディスクやSSDに保存する。

正解

B. CDN(Contents Delivery Network)を使用して、クライアントに近いエッジサーバーにコンテンツをキャッシュする。
C. インメモリデータベース(Memcached, Redisなど)を使用して、データをメインメモリに保存する。

すべてのレイヤーでセキュリティを確保する

すべてのレイヤーでセキュリティを確保するためには、いくつかのポイントを押さえる必要があります。

1. インフラストラクチャの各部分を隔離する

ネットワークセグメンテーション 各コンポーネントやサービスを異なるネットワークセグメントに分け、アクセス制御を厳格にします。
仮想プライベートクラウド(VPC) AWSのVPCを使用して、異なるアプリケーションやデータの流れを分離します。

2. 転送中および保管中のデータを暗号化する

データ暗号化 データが転送中(TLS/SSL)や保管中(AES-256など)で暗号化されていることを確認します。
AWS Key Management Service (KMS) AWS KMSを使用して、暗号化キーの管理を行います。

3. 最小権限の原則を使用して、きめ細かなアクセスコントロールを実施する

IAMポリシー: AWS IAMを使用して、ユーザーやサービスに最小限の必要な権限だけを付与します。
ロールベースアクセス制御(RBAC) 役割に基づいてアクセス権を付与し、必要なリソースへのアクセスを制限します。

4. 多要素認証を使用する

MFA(多要素認証) ユーザーアカウントにMFAを有効にし、ログイン時に追加の認証要素を要求します。
AWS MFA AWSアカウントやIAMユーザーにMFAを設定します。

5. マネージドサービスを活用する

AWSマネージドサービス AWSのマネージドサービス(RDS、DynamoDB、S3など)を使用して、セキュリティパッチやインフラの管理をAWSに任せます。
セキュリティコンプライアンス AWSのサービスは多くのセキュリティ認証を取得しているため、コンプライアンス要件を満たすのに役立ちます。

6. リソースへのアクセスを記録する

監査ログ AWS CloudTrailを使用して、すべてのAPIコールやユーザーアクティビティを記録し、監査ログを保持します。
ログ管理とモニタリング Amazon CloudWatchを使用して、リソースのログを集約し、異常なアクティビティをリアルタイムでモニタリングします。

7. デプロイを自動化して、セキュリティの整合性を維持する

インフラストラクチャコード化(IaC) AWS CloudFormationやTerraformを使用してインフラの設定をコード化し、一貫性を確保します。
CI/CDパイプライン AWS CodePipelineを使用して、セキュアなデプロイメントプロセスを自動化します。

レイヤー ベストプラクティス アンチパターン
ネットワークセグメンテーション 異なるネットワークセグメントに分けてアクセス制御を厳格にする
- AWS VPCを使用してアプリケーションやデータの流れを分離する
すべてのリソースを同じネットワークに配置する
セグメンテーションを行わない
データ暗号化 転送中(TLS/SSL)および保管中(AES-256など)でデータを暗号化する
- AWS KMSを使用して暗号化キーを管理する
データを平文のまま転送および保存する
暗号化キーの管理を手動で行う
アクセスコントロール AWS IAMを使用して最小権限の原則を適用する
ロールベースアクセス制御(RBAC)を導入する
過剰な権限を付与する
個別のユーザーアカウントに直接アクセス権を設定する
多要素認証(MFA) AWS MFAを有効にして、追加の認証要素を要求する パスワードのみで認証を行う
MFAを設定しない
マネージドサービス AWSのマネージドサービスを使用してセキュリティパッチやインフラ管理を任せる セルフホストで全ての管理を行う
パッチ管理を怠る
監査ログ AWS CloudTrailを使用してすべてのAPIコールやユーザーアクティビティを記録する ログを収集しない
監査ログを保持しない
ログ管理とモニタリング Amazon CloudWatchを使用してリソースのログを集約し、リアルタイムでモニタリングする ログを監視しない
異常なアクティビティの検知を行わない
インフラストラクチャコード化 AWS CloudFormationやTerraformを使用してインフラの設定をコード化する 手動でインフラを設定する
設定の一貫性を確保しない
CI/CDパイプライン AWS CodePipelineを使用してセキュアなデプロイメントプロセスを自動化する 手動でデプロイメントを行う
セキュリティチェックを含まない

問題文

ある企業が、世界中のユーザーが複数のAWSリージョンのAmazon EC2インスタンスにデプロイされたHTTPベースのアプリケーションにアクセスできるように設計しています。同社は、アプリケーションの可用性とパフォーマンスを向上させると同時に、セキュリティを強化したいと考えています。また、静的IPアドレスが必要です。

同社は、すべてのレイヤーでセキュリティを確保するために、以下のセキュリティ対策を実施することを計画しています。

  1. インフラストラクチャの各部分を隔離する
  2. 転送中および保管中のデータを暗号化する
  3. 最小権限の原則を使用して、きめ細かなアクセスコントロールを実施する
  4. 多要素認証を使用する

これらの要件を満たすために、ソリューションアーキテクトは何を推奨すべきでしょうか?

選択肢

A. EC2インスタンスを各リージョンのネットワークロードバランサー(NLB)の背後に配置します。AWS WAFをNLBにデプロイします。AWS Global Acceleratorを使用してアクセラレータを作成し、NLBをエンドポイントとして登録します。

B. EC2インスタンスを各リージョンのアプリケーションロードバランサー(ALB)の背後に配置します。ALBにAWS WAFをデプロイします。AWS Global Acceleratorを使用してアクセラレータを作成し、ALBをエンドポイントとして登録します。

C. EC2インスタンスを各リージョンのネットワークロードバランサー(NLB)の背後に配置します。AWS WAFをNLBにデプロイします。Amazon Route 53レイテンシーベースのルーティングを使用してリクエストをNLBにルーティングするオリジンを持つAmazon CloudFrontディストリビューションを作成します。

D. EC2インスタンスを各リージョンのアプリケーションロードバランサー(ALB)の背後に配置します。Amazon Route 53レイテンシーベースのルーティングを使用してリクエストをALBにルーティングするオリジンを持つAmazon CloudFrontディストリビューションを作成します。CloudFrontディストリビューションにAWS WAFをデプロイします。

正解

B. EC2インスタンスを各リージョンのアプリケーションロードバランサー(ALB)の背後に配置します。ALBにAWS WAFをデプロイします。AWS Global Acceleratorを使用してアクセラレータを作成し、ALBをエンドポイントとして登録します。

静的IPアドレス AWS Global Acceleratorを使用することで、静的IPアドレスが提供されます。
可用性とパフォーマンス AWS Global Acceleratorはトラフィックを最適なエンドポイントにルーティングするため、アプリケーションの可用性とパフォーマンスが向上します。
セキュリティ ALBにAWS WAFをデプロイすることで、一般的なWebエクスプロイトからアプリケーションを保護します。さらに、転送中および保管中のデータの暗号化、多要素認証、最小権限の原則などのセキュリティ対策を実施することで、すべてのレイヤーでセキュリティを確保します。

増加するデータの管理を行う

従来のデータ分析とデータレイクの違い

従来のデータ分析では、データ量が少ないため、データウェアハウスでデータを構造化して保存していました。しかし、近年ではデータ量が急増し、データの種類も多様化しています。データウェアハウスでは対応が難しくなり、データレイクが注目されています。

データレイクは、構造化データと非構造化データをそのままの状態で保存できるストレージサービスです。データ分析の柔軟性を高め、将来の分析ニーズにも対応することができます。

AWSにおけるデータレイク

AWSには、Amazon S3、Amazon EMR、Amazon Athena、Amazon Redshiftなどのデータレイク関連サービスが用意されています。これらのサービスを活用することで、効率的なデータ管理と分析を実現することができます。

データレイクを導入する際の注意事項

すべてのデータを1箇所に集めて保存する
データを分散させると、分析が複雑になり、コストも高くなります。
データストアとデータ処理の分離
データストアとデータ処理を分離することで、スケーラビリティと柔軟性を向上させることができます。
用途に応じた適切な処理方法の選択
分析ワークロードの種類に応じて、適切なデータ処理サービスを選択します。
コストを節約するための戦略を活用する
Amazon S3のストレージクラス、Amazon Glacierのアーカイブストレージ、AWSの割引プログラムなどのコスト節約戦略を活用します。

項目 ベストプラクティス アンチパターン
スケーラビリティ オンデマンドでスケーラブルなインフラストラクチャを使用する 固定サイズのインフラストラクチャを使用する
データベース 適切なデータベースソリューションを選択する すべてのデータに 1 つのデータベースを使用する
データ品質 データ品質を監視して管理する データ品質を監視または管理しない

問題文

増加するデータの管理に関する適切な手法として最も適切なものはどれですか?

選択肢

  1. スケーラビリティを確保する
  2. 環境を⾃動化する
  3. 使い捨て可能なリソースを使⽤する
  4. コンポーネントを疎結合にする

正解

  1. スケーラビリティを確保する

意外と、勉強になったのではないでしょうか?

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?