type
status
date
slug
summary
tags
category
icon
password

471-AWS SAP AWS 「理論・実践・一問道場」GWLB

 

理論

AWSでのセキュリティアプライアンスのスケーリングと高可用性

AWS環境でセキュリティアプライアンス（例：防火壁、IDS/IPS）のスケーリングと高可用性を実現するためのベストプラクティスを以下に簡潔にまとめます。

1. Gateway Load Balancer (GWLB)

  • 概要：GWLBは、セキュリティアプライアンス（防火壁、ネットワークセキュリティサービスなど）を横断的にスケーリングするための専用サービスです。
  • 特徴：トラフィックを自動でセキュリティインスタンスに分散し、需要に応じてインスタンスのスケーリングが可能。
  • メリット：セキュリティアプライアンス専用に設計されており、高可用性とスケーラビリティを簡単に実現。

2. Auto Scaling Group (ASG)

  • 概要：Auto Scalingを使用して、インスタンスのスケールアウト/スケールインを自動化します。特にセキュリティインスタンスに適用可能。
  • 特徴：トラフィックの増加に応じてインスタンス数を自動的に調整。設定スクリプトやテンプレートを利用してインスタンスを自動構成。
  • メリット：コスト効率良く、需要の変動に対応できる。

3. VPCエンドポイント (PrivateLink)

  • 概要：VPCエンドポイントは、VPC内からAWSサービスやカスタムサービスへのプライベートな接続を提供します。
  • 特徴：セキュアな接続を提供し、外部インターネット経由ではなく、AWS内部のネットワーク経由でアクセスを確保します。
  • メリット：セキュリティ向上と通信コスト削減、信頼性の高い接続を提供。

4. 高可用性と冗長性の設計

  • 概要：インスタンスの複数アベイラビリティゾーンへの展開により、障害に対する冗長性を確保します。
  • 特徴：障害発生時でもトラフィックが他のインスタンスに自動的にリダイレクトされ、ダウンタイムを最小限に抑えます。
  • メリット：サービスの高可用性を維持し、運用の信頼性を向上。

まとめ

  • Gateway Load BalancerとAuto Scalingの組み合わせで、セキュリティアプライアンスはスケーラブルで高可用な状態を実現可能です。
  • VPCエンドポイントは、メンバーアカウントとの効率的な接続をサポートします。
  • 高可用性を確保するためには、複数のアベイラビリティゾーンでのデプロイが重要です。
これらを駆使することで、ネットワークセキュリティの強化と運用効率を高めることができます。

実践

略

一問道場

質問 #471

ある企業はAWS Organizationsを使用しています。この企業は、中央ネットワークアカウント内で2つのファイアウォールアプライアンスを運用しています。各ファイアウォールアプライアンスは、高可用性を手動で構成したAmazon EC2インスタンス上で実行されています。トランジットゲートウェイを使用して、中央ネットワークアカウントのVPCとメンバーアカウントのVPCを接続しています。各ファイアウォールアプライアンスは静的なプライベートIPアドレスを使用しており、メンバーアカウントからインターネットへのトラフィックをルーティングするために使用されています。
最近のインシデントでは、誤った構成のスクリプトが原因で両方のファイアウォールアプライアンスが終了しました。ファイアウォールアプライアンスの再構築中に、企業は起動時にファイアウォールアプライアンスを構成する新しいスクリプトを作成しました。
この企業は、ファイアウォールアプライアンスの展開を近代化したいと考えています。ネットワークが拡張されたときに増加するトラフィックを処理できるように、ファイアウォールアプライアンスが水平スケールできる必要があります。また、企業ポリシーに準拠するため、ファイアウォールアプライアンスを引き続き使用する必要があります。ファイアウォールアプライアンスのプロバイダーは、最新バージョンのファイアウォールコードがすべてのAWSサービスで動作することを確認しています。
この要件を最も費用対効果の高い方法で満たすために、ソリューションアーキテクトが推奨すべき手順の組み合わせはどれですか？（3つ選択してください）
A. 中央ネットワークアカウントにGateway Load Balancerをデプロイします。AWS PrivateLinkを使用するエンドポイントサービスを設定します。
B. 中央ネットワークアカウントにNetwork Load Balancerをデプロイします。AWS PrivateLinkを使用するエンドポイントサービスを設定します。
C. Auto Scalingグループと、ユーザーデータとして新しいスクリプトを使用してファイアウォールアプライアンスを構成する起動テンプレートを作成します。インスタンスタイプのターゲットグループを作成します。
D. Auto Scalingグループを作成します。ユーザーデータとして新しいスクリプトを使用してファイアウォールアプライアンスを構成するAWS Launch Wizardのデプロイを設定します。IPターゲットタイプのターゲットグループを作成します。
E. 各メンバーアカウントにVPCエンドポイントを作成します。ルートテーブルを更新してVPCエンドポイントを指すようにします。
F. 中央ネットワークアカウントにVPCエンドポイントを作成します。各メンバーアカウントのルートテーブルを更新してVPCエンドポイントを指すようにします。

解説

この問題は、ネットワークセキュリティとトラフィック管理の要件を満たすために、Amazon EC2を使用して構築された現行の防火壁アーキテクチャをどのように最適化するかを問うものです。以下は解説です：

背景のポイント

  1. 現行の構成
      • 2台のEC2インスタンスが防火壁として動作し、インターネットトラフィックを検査。
      • 中央ネットワークアカウントに配置され、静的なプライベートIPでトラフィックをルーティング。
      • メンバーアカウントのVPCからのトラフィックは、Transit Gatewayを介してこの防火壁に送信される。
  1. 問題
      • 高可用性の欠如：最近のインシデントで2台のインスタンスが誤って終了した。
      • スケーラビリティの不足：現在の構成では、トラフィックが増加した場合に対処できない。
      • 手動設定の負担：防火壁の設定は再構築時にスクリプトで対応しているが、自動化が不足。
  1. 要件
      • 水平スケーリング：ネットワークの成長に合わせてトラフィックを処理できるようにする。
      • 高可用性：誤動作や障害時にも迅速に復旧できる仕組みを確保。
      • 既存ポリシーの継続使用：既存の防火壁アプライアンスを使い続ける。

選択肢の詳細解説

以下は各選択肢の解説です。

A. Gateway Load Balancerを使用する（推奨）

  • 内容 Gateway Load Balancer（GWLB）を中央ネットワークアカウントにデプロイし、AWS PrivateLinkを使用してエンドポイントサービスを設定する。
  • 利点
    • GWLBはネットワークトラフィックを防火壁インスタンスに自動分散できる。
    • インスタンスのスケールアウト（増加）やスケールイン（減少）をサポートし、水平スケーリングが容易になる。
    • PrivateLinkを使うことで、メンバーアカウントのVPCとの統合が簡単になる。
  • 適用性 非常に効率的で、推奨されるモダンなアプローチ。

B. Network Load Balancerを使用する

  • 内容 Network Load Balancer（NLB）を中央ネットワークアカウントにデプロイし、AWS PrivateLinkを使用してエンドポイントサービスを設定する。
  • 利点
    • NLBはトラフィックの分散が可能。
    • GWLBと比較するとセキュリティアプライアンス専用ではないため、柔軟性は低い。
  • 適用性 GWLBが利用可能な状況では、NLBはあまり推奨されない。

C. Auto Scaling Group + Launch Template（推奨）

  • 内容 Auto Scaling Group（ASG）を作成し、起動テンプレートを利用して防火壁のインスタンスを自動的にスケールアウト/スケールインできるようにする。
  • 利点
    • トラフィック増加時に自動でインスタンスを追加し、負荷を分散できる。
    • インスタンス起動時にスクリプトを実行し、設定を自動化。
  • 適用性 防火壁インスタンスの水平スケーリングと自動化を実現する重要なステップ。

D. Auto Scaling Group + AWS Launch Wizard

  • 内容 AWS Launch Wizardを使用してASGとターゲットグループを設定。
  • 利点
    • IPターゲットタイプを使うことで動的にインスタンスを管理可能。
    • ただし、Launch Wizardは特定のユースケースに最適化されており、柔軟性が低い。
  • 適用性 Launch WizardよりもLaunch Templateの方が一般的かつ柔軟なため、こちらは優先度が低い。

E. 各メンバーアカウントにVPCエンドポイントを作成

  • 内容 各メンバーアカウントでVPCエンドポイントを作成し、ルートテーブルを更新してトラフィックをリダイレクトする。
  • 利点
    • トラフィックのルーティングが確実になる。
    • ただし、スケーラビリティや効率性を向上させるには不十分。
  • 適用性 運用負担が大きいため、優先度が低い。

F. 中央ネットワークアカウントにVPCエンドポイントを作成（推奨）

  • 内容 中央ネットワークアカウントでVPCエンドポイントを作成し、メンバーアカウントのルートテーブルを更新。
  • 利点
    • 中央化された管理が可能。
    • トラフィックを効率的にルーティングできる。
  • 適用性 Gateway Load Balancerと組み合わせることで、より効果的な構成になる。

推奨される解答

以下の3つの選択肢が、要件を最も効果的に満たします：
  • A. Gateway Load Balancerを使用する
  • C. Auto Scaling Group + Launch Template
  • F. 中央ネットワークアカウントにVPCエンドポイントを作成する
この組み合わせにより、防火壁アーキテクチャが以下のように改善されます：
  1. 水平スケーリングと高可用性が実現。
  1. メンバーアカウントとの接続が簡略化。
  1. 全体の管理が効率化し、コスト効果も向上。
 
 

472-AWS SAP AWS 「理論・実践・一問道場」Amazon RDS for PostgreSQL

 

理論

1. マルチリージョンアーキテクチャ

  • 高可用性を確保するためには、複数のリージョンにリソースを配置することが重要です。AWSでは、複数のリージョンにまたがるリソースを配置し、リージョン間でのフェイルオーバーを実現することで、高可用性を向上させます。

2. Amazon RDSのクロスリージョンレプリケーション

  • クロスリージョンレプリケーションを利用することで、セカンダリリージョンにリアルタイムでデータを複製できます。障害が発生した場合には、セカンダリリージョンに昇格させてサービスを維持できます。

3. AWS Lambdaによる自動フェイルオーバー

  • AWS Lambdaを使用して、特定のイベント（例えば、データベースの障害検出）に反応し、必要なアクション（例えば、レプリカの昇格、Route 53のDNS更新）を自動的に実行できます。

4. Route 53のフェイルオーバールーティング

  • Route 53はDNSサービスで、フェイルオーバールーティングポリシーを設定することで、プライマリリージョンに障害が発生した際に、トラフィックを自動的にセカンダリリージョンに切り替えます。

5. RTOとRPO

  • *RTO（復旧時間目標）とRPO（復旧時点目標）**は、システム障害時のサービス復旧とデータ損失の許容範囲を示す重要な指標です。高可用性アーキテクチャの設計では、これらの目標を満たすためにバックアップ、レプリケーション、フェイルオーバーなどの技術を駆使します。

6. バックアップ戦略

  • 自動バックアップやスナップショットを利用して、最新のデータを保持し、障害発生時には迅速に復元できる体制を整えます。バックアップの頻度や保管場所を適切に設定することが、RPOの達成に寄与します。
これらの知識を活用して、AWS上での高可用性アーキテクチャを設計することができます。

実践

略

一問道場

質問 #472
ソリューションアーキテクトは、ウェブアプリケーションをサポートするAmazon RDS for PostgreSQLデータベースのために、マルチリージョンアーキテクチャを実装する必要があります。
データベースは、プライマリリージョンとセカンダリリージョンの両方で利用可能なAWSサービスと機能を含むAWS CloudFormationテンプレートから起動されます。
データベースは自動バックアップを構成しており、RTO（復旧時間目標）は15分、RPO（復旧時点目標）は2時間です。
ウェブアプリケーションは、Amazon Route 53のレコードを使用してデータベースへのトラフィックをルーティングするように構成されています。
どの組み合わせの手順が、すべての要件を満たす高可用性アーキテクチャを実現するでしょうか？（2つ選択してください。）
A. セカンダリリージョンにデータベースのクロスリージョン読み取りレプリカを作成します。
セカンダリリージョンでAWS Lambda関数を設定して、フェイルオーバーイベント時に読み取りレプリカを昇格させます。
B. プライマリリージョンで、データベースのヘルスチェックを作成し、障害が検出されたときにAWS Lambda関数を呼び出します。
Lambda関数をプログラムして、セカンダリリージョンで最新のデータベーススナップショットからデータベースを再作成し、Route 53のホストレコードを更新します。
C. 最新の自動バックアップをセカンダリリージョンに2時間ごとにコピーするAWS Lambda関数を作成します。
D. Route 53でフェイルオーバールーティングポリシーを作成し、データベースのDNSレコードに対してプライマリとセカンダリのエンドポイントを設定します。
E. セカンダリリージョンにホットスタンバイデータベースを作成し、プライマリデータベースが失敗した場合に最新のRDS自動バックアップからセカンダリデータベースを復元するためにAWS Lambda関数を使用します。

解説

このシナリオでは、Amazon RDS for PostgreSQLを使用した高可用性アーキテクチャを構築するために、以下の要件があります：
  • *RTO（復旧時間目標）**が15分で、障害が発生した場合にサービスの復旧が迅速に行われる必要があります。
  • *RPO（復旧時点目標）**が2時間で、データ損失を最小限に抑える必要があります。
  • マルチリージョンで高可用性を提供するために、プライマリとセカンダリリージョン間で適切なバックアップとフェイルオーバー戦略を設定する必要があります。
この要件を満たすために最適な手順を選択する必要があります。

選択肢の解説

A. セカンダリリージョンにデータベースのクロスリージョン読み取りレプリカを作成

  • クロスリージョン読み取りレプリカを作成することで、セカンダリリージョンで最新のデータを保持することができます。
  • AWS Lambda関数を使用して、プライマリリージョンで障害が発生した場合にレプリカを昇格させてデータベースをプライマリに切り替えることができます。これにより、15分以内のRTOを達成でき、セカンダリリージョンがプライマリリージョンに昇格することでサービスを迅速に復旧できます。

B. プライマリリージョンで、データベースのヘルスチェックを作成し、Lambda関数でデータベースを再作成

  • プライマリリージョンでヘルスチェックを行い、障害を検出した際にAWS Lambda関数を呼び出す仕組みです。この関数がセカンダリリージョンで最新のバックアップからデータベースを再作成し、Route 53のDNSレコードを更新することで、トラフィックがセカンダリリージョンに切り替わります。
  • これにより、RPOは2時間に保たれ、フェイルオーバーも自動化されるため、15分以内のRTOを達成できます。

C. 最新の自動バックアップをセカンダリリージョンに2時間ごとにコピー

  • この選択肢では、バックアップのコピーをセカンダリリージョンに定期的に転送することが提案されていますが、セカンダリリージョンでのバックアップ復元までの時間が確保されないため、RTOやRPOの要件に完全に適合しません。データベースの復旧が手動で行われる場合、RTOの目標は達成できません。

D. Route 53でフェイルオーバールーティングポリシーを作成

  • Route 53のフェイルオーバールーティングポリシーを使用すると、プライマリとセカンダリのエンドポイントを設定し、障害が発生した際に自動的にセカンダリリージョンにトラフィックをルーティングできます。これにより、障害発生時にルーティングが迅速に切り替わるため、RTOの目標を達成できます。
  • ただし、データベースのレプリケーションやバックアップの管理が別途必要です。このオプションだけではデータベースの可用性を確保するための完全な解決策とは言えません。

E. セカンダリリージョンにホットスタンバイデータベースを作成

  • セカンダリリージョンにホットスタンバイデータベースを作成し、AWS Lambda関数を使用して最新のバックアップから復元する方法です。この方法は、RTOやRPOの要件を満たすことができますが、ホットスタンバイであれば、データベースの同期が常に行われている必要があり、これが効果的に機能するためにはレプリケーションの設定が重要です。

結論

RTOとRPOの要件を満たし、マルチリージョンの高可用性を確保するために必要な選択肢は A と D です。
  • A は、セカンダリリージョンでのクロスリージョンレプリケーションと、Lambdaによるフェイルオーバーを使用して、迅速にサービスを復旧させる方法です。
  • D は、Route 53を使用して自動的にトラフィックを切り替え、障害発生時の高可用性を提供します。
これらの組み合わせにより、両方の要件（RTO 15分、RPO 2時間）を満たす高可用性アーキテクチャを実現できます。
 
 

473-AWS SAP AWS 「理論・実践・一問道場」RDSプロキシ

 

理論

1. データベース接続の最適化

  • Amazon RDS Proxy:
      • Lambda関数の高頻度呼び出し時に発生するデータベース接続の過負荷を防ぐために、RDS Proxyを使用します。
    • 接続プールを利用して接続の作成・破棄のオーバーヘッドを削減。
    • 高い同時実行性を維持可能。
  • コネクションの再利用:
      • Lambda関数内でデータベース接続を再利用することで、不要な接続の作成を減らします。ただし、スケーラビリティの課題が残る場合があります。

2. キャッシュの導入

  • Amazon ElastiCache (RedisまたはMemcached): 頻繁にアクセスされるデータをキャッシュに保存することで、データベースへのクエリ頻度を削減し、レスポンス時間を短縮。
    • キャッシュヒット率を向上させることで、データベース負荷を大幅に軽減可能。
    • 特に読み取りリクエストが多いワークロードに有効。

3. スケーラブルなサーバーレスアーキテクチャの設計

  • Lambda関数のメモリとタイムアウト設定:
      • 処理内容に応じてメモリとタイムアウトを適切に設定し、処理速度を最適化。
  • バックプレッシャー管理:
      • 高負荷時にAPI Gatewayのスロットリングやキューを利用して、リクエストの調整を行う。

4. パフォーマンス監視

  • Amazon CloudWatch:
      • メトリクス（Lambdaの呼び出し回数、データベース接続数、CPU使用率など）を監視し、パフォーマンスのボトルネックを特定。
  • アラーム設定:
      • しきい値を超える負荷やエラーを検知した際にアラートを発生させる。

5. 結論

高負荷時のアプリケーションの最適化には、以下が有効：
  1. データベース接続管理の効率化（RDS Proxy）。
  1. キャッシュの導入（ElastiCache）。
  1. クラウドネイティブツール（CloudWatchなど）でのパフォーマンス監視と調整。
これらを組み合わせることで、スケーラブルかつ高効率なサーバーレスアーキテクチャを実現できます。

実践

略

一問道場

質問 #473
あるeコマース会社がAWS上でアプリケーションを運用しています。このアプリケーションには、Amazon API Gateway APIがあり、それがAWS Lambda関数を呼び出しています。
データはAmazon RDS for PostgreSQL DBインスタンスに保存されています。
同社が最近実施したフラッシュセール中に、急激なAPIコールの増加がアプリケーションのパフォーマンスに悪影響を及ぼしました。
ソリューションアーキテクトがその期間中のAmazon CloudWatchメトリクスを確認したところ、Lambda関数の呼び出し回数とデータベース接続の大幅な増加が確認されました。また、DBインスタンスのCPU使用率も高くなっていました。
ソリューションアーキテクトは、アプリケーションのパフォーマンスを最適化するために何を推奨すべきでしょうか？
A. Lambda関数のメモリを増やします。データを取得した後、Lambda関数がデータベース接続を閉じるように修正します。
B. Amazon ElastiCache for Redisクラスターを追加して、RDSデータベースから頻繁にアクセスされるデータを保存します。
C. Lambdaコンソールを使用してRDSプロキシを作成します。Lambda関数を修正して、プロキシエンドポイントを使用するようにします。
D. Lambda関数を修正して、関数のハンドラー外でデータベースに接続するようにします。新しい接続を作成する前に、既存のデータベース接続を確認します。

解説

このシナリオでは、APIコールの急増に伴うパフォーマンス問題に対処するため、データベース接続やLambda関数の最適化が必要です。以下に各選択肢を解説し、最適な解決策を説明します。

A. Lambda関数のメモリを増やし、接続を閉じる

  • 解説: メモリを増やすことでLambda関数の処理能力は向上しますが、データベース接続の問題（接続数の急増）は根本的に解決できません。また、関数内で接続を開閉するのは非効率で、頻繁な接続の作成と終了がオーバーヘッドを生みます。
  • 評価: 部分的な改善のみで、データベースへの負荷を十分に軽減できません。

B. Amazon ElastiCache for Redisを追加

  • 解説: Redisクラスターを導入することで、頻繁にアクセスされるデータをキャッシュに保存し、データベースへのクエリ頻度を大幅に削減できます。これにより、データベースの負荷が軽減され、アプリケーション全体のレスポンスが改善されます。
  • 評価: 良い選択肢。特に読み取り負荷が高い場合に効果的ですが、アプリケーション全体でキャッシュを正しく管理する必要があります。

C. RDSプロキシを使用

  • 解説: Amazon RDS Proxyは、Lambda関数とRDSデータベースの間にプロキシを挟むことで、データベース接続の管理を効率化します。プロキシは接続プールを活用して、頻繁な接続の作成と破棄を最小限に抑えます。また、高負荷時の接続オーバーヘッドを軽減します。
  • 評価: 最適な選択肢。データベース接続数の増加を直接管理でき、LambdaとRDSのスケーリングに適しています。

D. データベース接続をハンドラー外に移動

  • 解説: Lambda関数で接続をハンドラー外に移動すると、関数の実行中に同じ接続を再利用できます。ただし、同時実行性が高い場合には、接続数の増加を防ぐ根本的な解決にはならず、複雑な接続管理が必要です。
  • 評価: 一部の改善は見込めますが、スケールしにくい方法です。
C
 
 

474-AWS SAP AWS 「理論・実践・一問道場」OLAP

 

理論

1. OLAPとは

  • OLAP (Online Analytical Processing) は、大量のデータを分析してビジネス上の意思決定を支援するための技術です。
    • 主にデータ分析やレポート生成に使用されます。
    • データを多次元的に分析し、トレンド、パターン、相関関係を発見するのに役立ちます。

OLAPの特徴

  • 用途: データマートやデータウェアハウスでの分析。
  • ワークロード: 読み取り専用の複雑なクエリが中心。
  • データベース例: Amazon Redshift、Google BigQuery、Snowflake。

OLTP (Online Transaction Processing)との違い

特徴
OLTP
OLAP
主な目的
トランザクション処理
データ分析
データ量
少量、頻繁に更新される
大量、基本的に読み取り専用
クエリの種類
簡単なクエリ
複雑な集計クエリ
例
MySQL、PostgreSQL、Aurora MySQL
Redshift、Snowflake

2. イベント駆動型アーキテクチャ

イベント駆動型アーキテクチャでは、システム内の変更（イベント）をリアルタイムで検知し、それに応じた処理をトリガーします。

主な特徴

  • リアルタイム性: イベントが発生するたびに処理を実行。
  • 疎結合: 各コンポーネントが独立して動作可能。
  • スケーラビリティ: 必要な処理だけをスケールアップ/ダウン可能。

主なコンポーネント

  • イベント発生元: データ変更やユーザー操作がイベントを発生させる（例: IoTデバイス、API）。
  • イベントルーター: Amazon EventBridgeやSNSを使用してイベントを適切なコンシューマにルーティング。
  • イベントコンシューマ: イベントを処理するアプリケーションやサービス（例: AWS Lambda、Kinesis）。

3. この問題に関連する設計パターン

データベースの選択

  • OLAP分析: Amazon Redshift Serverless
    • 高速なクエリ性能とスケーラビリティを提供。
  • OLTPトランザクション: Amazon Aurora Serverless MySQL
    • 自動スケーリングにより効率的なトランザクション処理を実現。

イベントルーティング

  • Amazon EventBridge:
    • イベントのルーティングとスケジュール管理が可能。複数のターゲットにデータを配信。

リアルタイム処理

  • サーバーレス技術（AWS Lambda、Fargate）を活用して高スケーラビリティを実現。

4. 結論

  • OLAP分析はデータウェアハウスを使用してトレンドやインサイトを取得するのに適しています。
  • イベント駆動型アーキテクチャを採用することで、リアルタイム処理と柔軟なスケーラビリティを提供できます。
  • AWSでは、Amazon Aurora Serverless、Amazon Redshift Serverless、Amazon EventBridgeなどのサービスを組み合わせて、効果的なソリューションを構築可能です。

実践

略

一問道場

質問 #474
小売業の会社がアプリケーションアーキテクチャの改善を検討しています。
同社のアプリケーションは、新規注文の登録、商品の返品処理、分析を行っています。アプリケーションはMySQLデータベースとOracle OLAP分析データベースに小売データを保存しています。すべてのアプリケーションとデータベースはAmazon EC2インスタンス上でホストされています。
各アプリケーションは注文処理の異なる部分を処理する複数のコンポーネントで構成されており、これらのコンポーネントは異なるソースからのデータを使用します。また、別のETLジョブが毎週実行され、各アプリケーションから分析データベースにデータをコピーしています。
ソリューションアーキテクトは、このアーキテクチャをイベント駆動型のソリューションに再設計し、サーバーレスサービスを使用する必要があります。このソリューションは、リアルタイムに近い形で更新された分析情報を提供しなければなりません。
次のどのソリューションがこれらの要件を満たしますか？
A. 各アプリケーションをマイクロサービスとしてAmazon Elastic Container Service（Amazon ECS）のAWS Fargateを使用するコンテナに移行します。
小売MySQLデータベースはAmazon EC2上に維持し、分析データベースをAmazon Neptuneに移行します。
Amazon Simple Queue Service（Amazon SQS）を使用して、すべての受信データをマイクロサービスと分析データベースに送信します。
B. 各アプリケーションのためにAuto Scalingグループを作成します。
各Auto Scalingグループに必要な数のEC2インスタンスを指定します。
小売MySQLデータベースと分析データベースをAmazon Aurora MySQLに移行します。
Amazon Simple Notification Service（Amazon SNS）を使用して、すべての受信データを正しいEC2インスタンスと分析データベースに送信します。
C. 各アプリケーションをマイクロサービスとしてAmazon Elastic Kubernetes Service（Amazon EKS）のAWS Fargateを使用するコンテナに移行します。
小売MySQLデータベースをAmazon Aurora Serverless MySQLに移行し、分析データベースをAmazon Redshift Serverlessに移行します。
Amazon EventBridgeを使用して、すべての受信データをマイクロサービスと分析データベースに送信します。
D. 各アプリケーションをマイクロサービスとしてAmazon AppStream 2.0に移行します。
小売MySQLデータベースをAmazon Aurora MySQLに移行し、分析データベースをAmazon Redshift Serverlessに移行します。
AWS IoT Coreを使用して、すべての受信データをマイクロサービスと分析データベースに送信します。
 
 

475-AWS SAP AWS 「理論・実践・一問道場」AWS CloudTrail マルチアカウント管理

 

理論

AWS CloudTrailとマルチアカウント管理

1. AWS CloudTrailとは

AWS CloudTrailは、AWSアカウント内の操作（APIコールや管理イベント）を記録し、コンプライアンス監査やセキュリティ分析に利用できるサービスです。

主な特徴

  • イベントの記録: すべてのAWSサービスのAPIコールや操作ログを記録。管理イベントやデータイベントに対応。
  • 保存先: ログはAmazon S3に保存し、必要に応じてAmazon CloudWatch Logsに送信可能。
  • 監査と可視性: 不審な操作や誤設定を迅速に検知。コンプライアンス要件を満たすために有効。

用途

  • セキュリティ分析
  • コンプライアンス監査
  • 問題解決（トラブルシューティング）

2. マルチアカウント環境でのCloudTrailの設計

AWS Organizationsを活用することで、複数アカウント環境でCloudTrailを効率的に管理できます。

推奨パターン

  • 管理アカウントに統一的なトレイルを作成:
    • 管理アカウントで1つの組織全体のトレイルを作成し、すべてのメンバーアカウントの操作を記録します。
    • 利点: 中央集約型で運用負荷が低い。新しいアカウントの追加にも自動対応。
    • 設定手順:
        1. AWS Organizationsで「組織全体のイベント」を有効化。
        1. 管理アカウントからCloudTrailトレイルを作成し、「すべての組織メンバーアカウントを含める」を選択。

SCP（サービスコントロールポリシー）の活用

  • CloudTrailの削除や変更を防止するため、以下のようなSCPを適用:

    3. ベストプラクティス

    1. ログの暗号化: CloudTrailログはAWS KMS（Key Management Service）で暗号化し、データの安全性を確保。
    1. 監視の強化: Amazon CloudWatch Logsと統合し、特定の操作（例: IAMユーザーの作成やS3バケットの削除）をアラートで通知。
    1. ストレージコスト管理: Amazon S3バケットのライフサイクルポリシーを使用して、古いログをアーカイブまたは削除。

    4. イベント管理にEventBridgeの活用

    AWS EventBridgeを使用して、CloudTrailイベントをリアルタイムで処理可能。
    • 例: 不審な操作を検知して自動的にアクションを実行（例: セキュリティグループをリセット）。

    結論

    AWS CloudTrailとAWS Organizationsを組み合わせた設計は、マルチアカウント環境での運用負荷を大幅に軽減します。特に、組織全体のトレイルを管理アカウントで集中管理する方法が効率的です。

    実践

    略

    一問道場

    質問 #475
    ある企業がオンプレミスのデータセンターからAWSクラウドへの移行を計画しています。この企業は、AWS Organizationsで管理される複数のAWSアカウントを使用する予定です。最初は少数のアカウントを作成し、必要に応じてアカウントを追加していきます。
    ソリューションアーキテクトは、すべてのAWSアカウントでAWS CloudTrailを有効にするソリューションを設計する必要があります。
    最も運用効率が高く、要件を満たすソリューションはどれですか？
    A.
    AWS Lambda関数を作成し、組織内のすべてのAWSアカウントで新しいCloudTrailトレイルを作成します。
    Amazon EventBridgeでスケジュールアクションを使用してLambda関数を毎日呼び出します。
    B.
    組織の管理アカウントで新しいCloudTrailトレイルを作成します。
    このトレイルを、組織内のすべてのAWSアカウントのすべてのイベントをログに記録するように設定します。
    C.
    組織内のすべてのAWSアカウントで新しいCloudTrailトレイルを作成します。
    新しいアカウントが作成されるたびに新しいトレイルを作成します。
    トレイルの削除や変更を防止するSCP（サービスコントロールポリシー）を定義します。
    このSCPをルートOUに適用します。
    D.
    AWS Systems Manager Automationランブックを作成し、組織内のすべてのAWSアカウントでCloudTrailトレイルを作成します。
    Systems Manager State Managerを使用してAutomationを呼び出します。

    解説

    この問題では、複数のAWSアカウントに対して効率的にAWS CloudTrailを有効にするソリューションを設計する必要があります。それぞれの選択肢について解説し、最適な解決策を示します。

    A. Lambda + EventBridgeでCloudTrailを毎日設定

    • 解説:
      • Lambda関数を使用してすべてのアカウントにCloudTrailトレイルを作成する方法。EventBridgeで毎日関数を実行してトレイルが有効か確認します。
      • 欠点: 新しいアカウントが作成されるたびに手動で設定を更新する必要があります。また、毎日Lambdaを実行するのは効率が悪いです。
    • 評価: 運用効率が低いため、適切ではありません。

    B. 管理アカウントに統一的なCloudTrailを作成

    • 解説:
      • AWS Organizationsの管理アカウントで1つのCloudTrailトレイルを作成し、すべてのメンバーアカウントのイベントをログに記録します。
      • 利点:
        • 中央集約型の管理が可能で、複数アカウントのトレイルを一元化。
        • 運用効率が高く、新しいアカウントが自動的にログ記録対象になります。
      • 欠点: 組織全体のトレイルを管理アカウントで管理するため、すべてのログを1箇所に保存する必要があります（ストレージコストが増加する可能性）。
    • 評価: 最も効率的で簡単な解決策です。

    C. 各アカウントに個別のCloudTrailトレイルを作成

    • 解説:
      • 組織内のすべてのアカウントに個別のトレイルを作成し、新しいアカウントが作成されるたびにトレイルを追加します。SCP（サービスコントロールポリシー）でトレイルの変更や削除を防ぎます。
      • 欠点:
        • 各アカウントごとに設定が必要で、管理の負荷が増大します。
        • 新しいアカウントを追加するたびに手動の介入が必要です。
    • 評価: 運用効率が低く、適切ではありません。

    D. Systems Manager Automationを使用

    • 解説:
      • Automationランブックを作成し、組織内のすべてのアカウントでトレイルを作成します。State Managerを使ってランブックを定期的に実行します。
      • 欠点:
        • 定期的なAutomation実行の設定が必要で、構成が複雑になります。
        • 新しいアカウントの追加対応が手動になる可能性があります。
    • 評価: Bと比べて効率が劣り、適切ではありません。

    結論

    最適なソリューションはB. 管理アカウントに統一的なCloudTrailを作成です。
    • 理由:
        1. CloudTrailを一元管理でき、複数アカウントのログを効率的に収集可能。
        1. 新しいアカウントが作成されても自動的にログ収集が適用され、運用負荷を削減。
        1. AWS Organizationsと統合されており、構成が簡単でコストパフォーマンスにも優れています。
    この設計により、運用効率が高く、全アカウントのログを確実に記録できます。
     
     

    476-AWS SAP AWS 「理論・実践・一問道場」AD Connector

     

    理論

    この問題に関連する汎用的な知識を簡潔にまとめます。

    1. AWS Client VPN

    AWS Client VPN は、ユーザーがインターネット経由で AWS の仮想プライベートクラウド（VPC）内のリソースにセキュアにアクセスできるようにする、フルマネージドなリモートアクセス VPN サービスです。これにより、リモートワークのユーザーが安全に企業のネットワークにアクセスすることができます。
    • 特徴：
      • 多要素認証（MFA）：AWS Client VPN は MFA をサポートしており、追加のセキュリティ層を提供します。
      • AD DSとの統合：Active Directory Domain Services（AD DS）と統合することで、ユーザーの認証と権限管理を一元化できます。
      • スケーラビリティ：必要に応じて自動的にスケールするため、大規模なリモートアクセス環境でも問題なく利用可能です。

    2. AD Connector

    AD Connector は、AWS のサービスと企業の Active Directory（AD DS） を接続するためのディレクトリサービスです。これにより、AWS リソース（例えば、AWS Client VPN、Amazon WorkSpaces など）で AD DS の認証情報を利用することができます。
    • 特徴：
      • 本番環境向け：オンプレミスの AD DS をそのまま利用することができ、完全に移行せずにクラウド環境と統合できます。
      • スムーズな統合：AWS 内のリソース（EC2、RDS、WorkSpaces など）と既存の AD DS を簡単に統合できます。

    3. AWS VPN

    • Site-to-Site VPN：AWS とオンプレミスのネットワーク間で直接接続するための VPN 接続です。主に、AWS の VPC と企業のデータセンターなどとの間でセキュアな通信を確立する際に使用します。
    • Client VPN：リモートユーザーがインターネットを通じて AWS リソースにアクセスするための VPN です。AWS クラウドへのリモートアクセス用に最適化されています。

    4. 多要素認証（MFA）

    MFA は、ユーザーが VPN などのサービスにアクセスする際に、2つ以上の認証要素を要求するセキュリティ手法です。例えば、パスワードに加えて、モバイルデバイスやハードウェアトークンから生成されるワンタイムパスワード（OTP）などを使用します。
    • 利点：
      • セキュリティ向上：MFA は単純なパスワードだけではアクセスできないようにするため、セキュリティが強化されます。
      • AWSサポート：AWSではMFAを複数のサービスに対応させることができ、特にAWS Client VPNやAWS Management Consoleでのアクセス制御に利用されます。

    まとめ

    • AWS Client VPN を使うことで、リモートワーカーがインターネット経由で AWS の VPC 内のサービスに安全にアクセスできます。
    • AD Connector は、AWS 上のリソースとオンプレミスの Active Directory を統合し、ユーザー認証を一元化するために使われます。
    • MFA を使うことで、VPN へのアクセスを多層的に保護できます。

    実践

    略

    一問道場

    質問 #476
    あるソフトウェア開発会社には、リモートで作業している複数のエンジニアがいます。会社はAmazon EC2インスタンス上でActive Directory Domain Services（AD DS）を実行しています。会社のセキュリティポリシーでは、VPC内にデプロイされるすべての内部・非公開サービスはVPNを介してアクセス可能でなければならず、VPNへのアクセスには多要素認証（MFA）を使用する必要があります。
    これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？
    A.
    AWS Site-to-Site VPN接続を作成し、VPNとAD DSの統合を設定します。MFAサポートが有効なAmazon WorkSpacesクライアントを使用してVPN接続を確立します。
    B.
    AWS Client VPNエンドポイントを作成し、AD DSと統合するためにAD Connectorディレクトリを作成します。AD ConnectorにMFAを有効にし、AWS Client VPNを使用してVPN接続を確立します。
    C.
    複数のAWS Site-to-Site VPN接続を作成し、AWS VPN CloudHubを使用して統合を設定します。AWS VPN CloudHubとAD DSの統合を構成し、AWS Copilotを使用してVPN接続を確立します。
    D.
    Amazon WorkLinkエンドポイントを作成し、Amazon WorkLinkとAD DSの統合を設定します。Amazon WorkLinkでMFAを有効にし、AWS Client VPNを使用してVPN接続を確立します。

    解説

    この問題では、リモートワークのエンジニアが安全にAWS上の内部サービスにアクセスできるように、VPN接続を確立し、その接続には多要素認証（MFA）を使用する必要があります。解決策として最も適切な方法を選ぶ問題です。

    問題の背景

    • 会社にはリモートワークをしている複数のエンジニアがいます。
    • 会社はAWSで Active Directory Domain Services (AD DS) を運用しており、そのサービスを使って内部の認証を行っています。
    • すべての内部サービスに対するアクセスはVPN経由で行う必要があります。
    • VPN接続に対して 多要素認証（MFA） を有効にする必要があります。

    解答選択肢の分析

    A. AWS Site-to-Site VPN 接続を作成し、VPNとAD DSを統合します。

    • Amazon WorkSpaces クライアントを使用してMFAを有効にし、VPN接続を確立する方法です。
    • Site-to-Site VPN は通常、オンプレミスとAWS間で使用されるもので、リモートワークには向いていません。
    • WorkSpacesクライアント はデスクトップ仮想化サービスですが、リモートVPN接続には適していません。

    B. AWS Client VPN エンドポイントを作成し、AD DSと統合します。

    • AWS Client VPN はリモートアクセスVPNを提供するAWSのサービスで、ユーザーがインターネット経由でAWS VPC内のリソースにアクセスできるようにします。
    • AD Connector を使って、AWS Client VPNとAD DSを統合する方法です。
    • MFAを有効化でき、セキュリティ要件に合致しています。
    • 最も適切な選択肢です。

    C. 複数のAWS Site-to-Site VPN接続を作成し、AWS VPN CloudHubを使って統合します。

    • これはSite-to-Site VPN を複数作成し、VPN CloudHub を使って接続する方法です。
    • Site-to-Site VPNはリモートアクセス向けではなく、企業間接続に使用されることが多いため、リモートワークのエンジニアに対する接続方法としては不適切です。

    D. Amazon WorkLink エンドポイントを作成し、AD DSとの統合を設定します。

    • Amazon WorkLink はモバイルデバイス向けのサービスで、ウェブアプリケーションにセキュアにアクセスするためのもので、VPNの代替にはなりません。
    • この選択肢もリモートワークのVPN接続には適していません。

    最適な解決策

    B. AWS Client VPN エンドポイントを作成し、AD DSと統合します。
    • AWS Client VPN はリモートアクセス向けであり、AD DSとの統合を簡単に実現できます。
    • MFAを有効化することも可能で、セキュリティ要件を満たします。
    • 最も効率的かつセキュアな解決策です。

    結論

    選択肢 B は、リモートワークエンジニアのアクセス要件を満たし、MFAとAD DS統合を適切にサポートするため、最も適切な解決策です。
     
     

    477-AWS SAP AWS 「理論・実践・一問道場」3層アーキテクチャ

     

    理論

    1. 3層アーキテクチャ

    • フロントエンド：ユーザーインターフェース（UI）や静的コンテンツ（HTML, CSS, JS）を提供。
    • ミドルティア：ビジネスロジックやAPI、アプリケーションサーバーなど。
    • ストレージ層：データベース、ファイルストレージ、キャッシュシステム。

    2. AWSでのスケーラビリティの向上方法

    • Amazon EC2のAuto Scaling：トラフィックに応じて自動的にインスタンス数を増減。アプリケーションの負荷に合わせてスケールする。
    • Amazon Elastic Load Balancer (ELB)：複数のインスタンスにトラフィックを分散し、高可用性を提供。
    • Amazon CloudFront：CDN（コンテンツ配信ネットワーク）を利用して静的コンテンツをキャッシュし、ユーザーに迅速に配信。

    3. コンテナとサーバーレス

    • AWS Fargate：サーバーレスでコンテナを管理でき、インフラの管理から解放される。スケーラブルで高可用性を提供。
    • Elastic Beanstalk：アプリケーションのデプロイや管理を簡素化するマネージドサービス。オートスケーリング機能を内蔵。

    4. データベースのスケーラビリティ

    • Amazon Aurora：高性能なリレーショナルデータベース。Auto Scaling機能を使って、読み取りリクエストに応じてリードレプリカを自動でスケール。
    • AWS Database Migration Service (DMS)：データベースの移行や再プラットフォームに使用。オンプレミスからAWSへのデータ移行をサポート。

    5. 運用負荷の軽減

    • マネージドサービスの活用：Amazon AuroraやElastic Beanstalkなど、インフラ管理の負担を軽減するマネージドサービスを活用する。
    • オートスケーリング：アプリケーションやデータベースの負荷に合わせて自動的にリソースを調整する機能。

    6. データベースのパフォーマンス向上

    • リードレプリカ：読み取り負荷を分散させ、パフォーマンスを向上させる。
    • キャッシュの活用：頻繁にアクセスされるデータをキャッシュすることで、データベースへの負荷を軽減。
    これらの知識を組み合わせることで、アプリケーションのスケーラビリティとパフォーマンスを最適化できます。

    実践

    略

    一問道場

    質問 #477
    ある企業は、オンプレミスのデータセンターで3層ウェブアプリケーションを運用しています。フロントエンドはApacheウェブサーバーで提供され、ミドルティアはモノリシックなJavaアプリケーション、ストレージ層はPostgreSQLデータベースです。
    最近のマーケティングプロモーション中に、顧客はアプリケーションを通じて注文を行うことができませんでした。原因の分析の結果、すべての層が過負荷となり、アプリケーションが応答しなくなり、データベースは読み取り操作のために容量制限に達していたことが分かりました。この企業には、今後も似たようなプロモーションが予定されています。
    ソリューションアーキテクトは、AWSへの移行計画を立て、この問題を解決する必要があります。このソリューションは、スケーラビリティを最大化し、運用負荷を最小化する必要があります。
    どの組み合わせのステップがこの要件を満たしますか？（3つ選択してください。）
    A. フロントエンドをリファクタリングして、静的アセットをAmazon S3にホストします。Amazon CloudFrontを使用して、フロントエンドを顧客に提供します。フロントエンドをJavaアプリケーションに接続します。
    B. フロントエンドのApacheウェブサーバーをAmazon EC2インスタンスにリホストし、Auto Scalingグループに配置します。Auto Scalingグループの前にロードバランサーを使用します。Amazon Elastic File System（Amazon EFS）を使用して、Apacheウェブサーバーが必要とする静的アセットをホストします。
    C. JavaアプリケーションをAWS Elastic Beanstalk環境にリホストし、オートスケーリングを含めます。
    D. Javaアプリケーションをリファクタリングし、Dockerコンテナを開発してJavaアプリケーションを実行します。AWS Fargateを使用してコンテナをホストします。
    E. AWS Database Migration Service（AWS DMS）を使用して、PostgreSQLデータベースをAmazon Aurora PostgreSQLデータベースに再プラットフォームし、Aurora Auto Scalingを使用してリードレプリカを作成します。
    F. PostgreSQLデータベースをAmazon EC2インスタンスにリホストし、オンプレミスのサーバーの2倍のメモリを搭載します。

    解説

    この問題では、企業のウェブアプリケーションのパフォーマンスの問題を解決するために、AWS への移行を計画する方法を選択することが求められています。アプリケーションが過負荷によりクラッシュし、データベースの読み取り操作が容量制限に達していることがわかっており、これらの問題を解決するためにスケーラビリティを最大化し、運用負荷を最小化する必要があります。

    解決策のステップごとに解説します：

    A. フロントエンドをリファクタリングして、静的アセットをAmazon S3にホストします。Amazon CloudFrontを使用して、フロントエンドを顧客に提供します。フロントエンドをJavaアプリケーションに接続します。

    • 解説：
      • スケーラビリティの向上：静的コンテンツ（画像、CSS、JavaScriptなど）を Amazon S3 にホストし、Amazon CloudFront を使用してコンテンツをキャッシュすることで、アプリケーションの負荷を軽減できます。
      • 運用負荷の最小化：S3 と CloudFront はフルマネージドサービスであり、これによりインフラストラクチャの管理負担が減少します。

    B. フロントエンドのApacheウェブサーバーをAmazon EC2インスタンスにリホストし、Auto Scalingグループに配置します。Auto Scalingグループの前にロードバランサーを使用します。Amazon Elastic File System（Amazon EFS）を使用して、Apacheウェブサーバーが必要とする静的アセットをホストします。

    • 解説：
      • EC2によるリホスティング：既存のApacheウェブサーバーを Amazon EC2 上にリホストし、Auto Scaling を使用してトラフィックに応じて自動でインスタンス数をスケーリングします。
      • Elastic File System (EFS)：静的アセットを EFS にホストすることで、複数の EC2 インスタンスから共有可能にし、可用性とパフォーマンスを向上させます。
      • 負荷分散：Elastic Load Balancer (ELB) を使うことで、トラフィックの分散と高可用性を実現できます。

    C. JavaアプリケーションをAWS Elastic Beanstalk環境にリホストし、オートスケーリングを含めます。

    • 解説：
      • Elastic Beanstalk は、Javaアプリケーションを簡単にデプロイし、スケーリング、監視、管理を自動化するフルマネージドサービスです。
      • オートスケーリング：トラフィックの増加に応じて、自動でアプリケーションインスタンスをスケーリングします。
      • 運用負荷の最小化：Elastic Beanstalk ではアプリケーションのデプロイと管理が簡素化され、インフラストラクチャの管理が不要になります。

    D. Javaアプリケーションをリファクタリングし、Dockerコンテナを開発してJavaアプリケーションを実行します。AWS Fargateを使用してコンテナをホストします。

    • 解説：
      • コンテナ化：アプリケーションを Docker コンテナとしてデプロイすることで、移植性が向上し、さまざまな環境で簡単に実行できます。
      • AWS Fargate：Fargate は、サーバーレスコンテナサービスで、インフラ管理なしでコンテナを実行できます。これにより、スケーラビリティと運用負荷が大幅に軽減されます。
      • リファクタリングの必要性：Java アプリケーションをコンテナ化するためには、アプリケーションのコードや構成を変更する必要があるため、この選択肢はやや高コストな場合があります。

    E. AWS Database Migration Service（AWS DMS）を使用して、PostgreSQLデータベースをAmazon Aurora PostgreSQLデータベースに再プラットフォームし、Aurora Auto Scalingを使用してリードレプリカを作成します。

    • 解説：
      • Aurora PostgreSQL は高可用性と高スケーラビリティを提供するデータベースサービスです。これを使うことで、データベースのパフォーマンスを向上させ、スケーラビリティを確保できます。
      • Aurora Auto Scaling：読み取りリクエストの増加に応じて、自動でリードレプリカをスケーリングすることができ、データベースのパフォーマンスを最適化できます。
      • AWS DMS を使用して、オンプレミスの PostgreSQL データベースを Aurora に移行することが可能です。

    F. PostgreSQLデータベースをAmazon EC2インスタンスにリホストし、オンプレミスのサーバーの2倍のメモリを搭載します。

    • 解説：
      • EC2によるリホスティング：データベースを EC2 インスタンスにリホストして、メモリを増やすことでパフォーマンスを向上させる方法です。しかし、この方法ではスケーラビリティが限られており、長期的な解決策としては不十分です。
      • 運用負荷の増加：EC2 インスタンス上でのデータベース管理が必要であり、スケーリングの柔軟性が低く、運用負荷が高くなります。

    最適な選択肢

    • A, C, E が最も適切な解決策です。
      • A と C はフロントエンドとアプリケーション層のスケーリングに対応し、負荷分散とオートスケーリングを提供します。
      • E はデータベースのスケーリングとパフォーマンス向上に貢献し、Aurora と Auto Scaling を使用して読み取りのスケーラビリティを確保します。

    まとめ

    • A: 静的アセットのホスティングとCDNの利用
    • C: アプリケーションのリホスティングとオートスケーリング
    • E: 高性能なデータベースに移行し、スケーラビリティを確保
    これにより、スケーラビリティが向上し、運用負荷が最小化され、プロモーション中のパフォーマンス問題を解決できます。
     
     

    478-AWS SAP AWS 「理論・実践・一問道場」Amazon Inspector

     

    理論

    AWSにおけるセキュリティ脆弱性スキャンの基本

    AWS上でアプリケーションやインフラのセキュリティを強化するためには、リソースの継続的な脆弱性スキャンが必要です。以下のサービスとアプローチが有効です：
    1. Amazon Inspector
        2. Amazon Inspectorは、EC2インスタンスやコンテナ、EKSノードなどの脆弱性を自動でスキャンするサービスです。セキュリティ設定やソフトウェアの脆弱性を特定し、修正すべき点をレポートとして提供します。これにより、セキュリティリスクを迅速に特定できます。
    1. Amazon ECRのスキャン機能
        2. Amazon Elastic Container Registry (ECR)は、コンテナイメージを保存するサービスで、プッシュ時に自動的に基本的な脆弱性スキャンを実行できます。これにより、ECRに保存されているイメージがセキュリティの観点から適切かどうかを簡単に確認できます。
    1. Security Hubの役割
        2. AWS Security Hubは、AWSアカウント全体のセキュリティ状況を統合的に管理するサービスですが、脆弱性スキャンの直接的な機能は提供していません。Security Hubは、InspectorやGuardDutyなどの他のセキュリティサービスと統合して、全体のセキュリティ状況を一元管理できます。
    1. 運用オーバーヘッドの最小化
        2. 脆弱性スキャンは自動化することで、人的リソースを最小限に抑えることが可能です。Amazon InspectorやECRのスキャン機能など、AWSのサービスを組み合わせて使うことで、セキュリティチェックを自動化し、継続的に監視できます。
    これらのサービスを適切に組み合わせて使うことが、AWS上でのセキュリティを強化し、運用負荷を最小化する鍵となります。

    実践

    略

    一問道場

    質問 #478
    ある会社が新しいアプリケーションをAWSにデプロイしようとしています。アプリケーションは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターと、Amazon Elastic Container Registry (Amazon ECR) リポジトリで構成されています。EKS クラスターには、AWS 管理のノードグループがあります。
    会社のセキュリティガイドラインでは、すべてのリソースがAWS上で継続的にセキュリティ脆弱性をスキャンする必要があるとしています。
    最小の運用オーバーヘッドでこの要件を満たすソリューションはどれですか？
    A. AWS Security Hub を有効にし、Security Hub を構成して EKS ノードと ECR リポジトリをスキャンします。
    B. Amazon Inspector を有効にし、EKS ノードと ECR リポジトリをスキャンします。
    C. 新しい Amazon EC2 インスタンスを起動し、AWS Marketplace から脆弱性スキャンツールをインストールします。EC2 インスタンスを構成して EKS ノードをスキャンし、Amazon ECR を構成してプッシュ時に基本的なスキャンを実行します。
    D. EKS ノードに Amazon CloudWatch エージェントをインストールし、CloudWatch エージェントを構成して継続的にスキャンします。Amazon ECR を構成してプッシュ時に基本的なスキャンを実行します。

    解説

    この質問では、AWS上でのセキュリティ脆弱性スキャンの要件を満たすために、最小の運用オーバーヘッドで実行できるソリューションを選ぶことが求められています。それぞれの選択肢を解説します。

    A. AWS Security Hub を有効にし、Security Hub を構成して EKS ノードと ECR リポジトリをスキャンします。

    解説: AWS Security Hubは、AWS環境全体のセキュリティ状況を集中的に監視するサービスですが、EKS ノードや ECR リポジトリ自体のセキュリティ脆弱性をスキャンする機能は提供していません。EKS のノードのスキャンやコンテナイメージの脆弱性チェックは、他のサービス (例：Amazon Inspector) によって実行されます。そのため、Security Hubだけで脆弱性スキャンを実行することはできません。
    不正解。

    B. Amazon Inspector を有効にし、EKS ノードと ECR リポジトリをスキャンします。

    解説: Amazon Inspectorは、AWS環境で脆弱性スキャンを実行するためのサービスです。Amazon Inspectorは、EKS ノードやECR リポジトリに対するセキュリティスキャンを自動的に実行できます。これにより、ECR内のコンテナイメージやEKSノードの脆弱性をスキャンし、セキュリティの問題を特定できます。また、Amazon Inspectorは、他のAWSの管理サービスと統合されており、比較的少ない運用オーバーヘッドで管理できます。
    正解。

    C. 新しい Amazon EC2 インスタンスを起動し、AWS Marketplace から脆弱性スキャンツールをインストールします。EC2 インスタンスを構成して EKS ノードをスキャンし、Amazon ECR を構成してプッシュ時に基本的なスキャンを実行します。

    解説: この選択肢では、EC2 インスタンスを使ってスキャンツールをインストールし、脆弱性スキャンを手動で実行する方法を提案しています。これは確かに脆弱性スキャンを実行する方法ではありますが、手動での管理やツールの維持、運用負荷が高くなります。また、ECR の基本的なスキャンはプッシュ時に実行できますが、EKS ノードのスキャンを自動化するために EC2 インスタンスを管理するのはオーバーヘッドが大きくなります。
    不正解。

    D. EKS ノードに Amazon CloudWatch エージェントをインストールし、CloudWatch エージェントを構成して継続的にスキャンします。Amazon ECR を構成してプッシュ時に基本的なスキャンを実行します。

    解説: Amazon CloudWatchエージェントは、システムのメトリクスやログを監視するためのツールであり、脆弱性スキャンを実行するものではありません。CloudWatch エージェントを使用して脆弱性スキャンを実行することはできないため、この選択肢は不適切です。
    不正解。

    結論:

    最も適切な選択肢は B の「Amazon Inspector を有効にし、EKS ノードと ECR リポジトリをスキャンする」です。Amazon Inspectorは、脆弱性スキャンを自動化し、運用オーバーヘッドを最小限に抑えつつ、要件を満たすことができます。
     
     

    479-AWS SAP AWS 「理論・実践・一問道場」CloudFront 関数の活用

     

    理論

    高負荷時のアプリケーション信頼性向上のためのアプローチ

    アプリケーションが高負荷に直面している場合、特定のモジュールに対する負荷を分散し、信頼性を高めるための効果的なアプローチは次の通りです。
    1. サービスの分割とスケーリング:
        • アプリケーション内の異なるコンポーネント（例：チケット販売と待機室）を別のサービスとして分け、各サービスに異なるスケーリング構成を適用します。これにより、特定のサービスに過剰な負荷がかかっても、他のサービスに影響を与えることなく、システム全体のパフォーマンスを保つことができます。
    1. CloudFront 関数の活用:
        • CloudFront 関数を使用して、リクエストをエッジロケーションで高速に処理し、ユーザーがチケット購入可能かどうかを判断することで、バックエンドにかかる負荷を減らします。これにより、リクエストが到達する前に効率的にリダイレクト処理が可能になります。
    1. JWT 情報の使用:
        • ユーザーを識別するために JWT（JSON Web Token）を使用し、リクエストのフローを制御します。JWT 情報をもとに、特定のユーザーをチケット購入サービスまたは待機室サービスに振り分けることができます。
    1. 高可用性とスケーラビリティ:
        • 高可用性とスケーラビリティを実現するために、ECS や EKS を活用し、異なるサービスを適切にスケールアウトさせます。ECS クラスターや EKS クラスター内でのリソースの効率的な管理は、負荷分散やサービス間通信を最適化します。
    これらの手法を組み合わせることで、アプリケーションは高負荷時でも安定性を保ちながら、リソースを効果的に利用できるようになります。

    実践

    略

    一問道場

    質問 #479
    ある会社は、チケット購入アプリケーションの信頼性を向上させる必要があります。アプリケーションは、Amazon Elastic Container Service (Amazon ECS) クラスターで実行されています。会社は、Amazon CloudFront を使用してアプリケーションを提供しています。ECS クラスターの単一の ECS サービスが CloudFront ディストリビューションのオリジンです。
    アプリケーションは、特定の数のアクティブユーザーのみがチケット購入フローに入ることを許可します。これらのユーザーは、その JSON Web Token (JWT) に格納された暗号化された属性で識別されます。それ以外のユーザーは、購入のための空き容量が出るまで待機室モジュールにリダイレクトされます。
    アプリケーションは高負荷に直面しており、待機室モジュールは設計通りに機能していますが、待機室への負荷がアプリケーションの可用性に影響を与えています。この影響により、アプリケーションのチケット販売取引に悪影響を及ぼしています。
    高負荷時にチケット販売取引の信頼性を最も高める解決策はどれですか？
    A. 待機室用に ECS クラスター内に別のサービスを作成し、別のスケーリング構成を使用します。チケットサービスが JWT 情報を使用し、リクエストを適切に待機室サービスに転送することを確認します。
    B. アプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移行し、待機室モジュールをチケットポッドと分けて別のポッドにします。チケットポッドを StatefulSet の一部にします。チケットポッドが JWT 情報を使用し、リクエストを適切に待機室ポッドに転送することを確認します。
    C. 待機室用に ECS クラスター内に別のサービスを作成し、別のスケーリング構成を使用します。CloudFront 関数を作成し、JWT 情報を検査してリクエストをチケットサービスまたは待機室サービスに適切に転送します。
    D. アプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移行し、待機室モジュールをチケットポッドと分けて別のポッドにします。AWS App Mesh を使用して、Kubernetes 用の App Mesh コントローラーをプロビジョニングします。mTLS 認証およびサービス間認証を有効にして、チケットポッドと待機室ポッド間の通信を保護します。チケットポッドが JWT 情報を使用し、リクエストを適切に待機室ポッドに転送することを確認します。

    解説

    C. 待機室用に ECS クラスター内に別のサービスを作成し、別のスケーリング構成を使用します。CloudFront 関数を作成し、JWT 情報を検査してリクエストをチケットサービスまたは待機室サービスに適切に転送します。

    解説:

    このアプローチは、主に以下の理由で適切とされます：
    1. ECS クラスター内でのサービス分割:
        • 待機室とチケット販売サービスを別の ECS サービスとして分け、それぞれに独自のスケーリング構成を適用します。これにより、待機室の負荷が高くてもチケット販売サービスへの影響を最小化できます。待機室のトラフィックが増えても、チケットサービスはスケールアウトを効率的に管理できます。
    1. CloudFront 関数を使ったリクエストの適切な転送:
        • CloudFront 関数は、CloudFront のエッジロケーションでリクエストを処理し、パフォーマンス向上に寄与する軽量な関数です。この関数を使って、JWT 情報を検査し、ユーザーがチケット購入可能か、待機室に転送すべきかを判断するロジックを組み込みます。
        • CloudFront 関数は非常に低レベルで高速に動作するため、リクエストが届いた時点で迅速に判断してリダイレクトすることができます。これにより、アプリケーションのバックエンドに不必要な負荷をかけることなく、最適なサービス（チケットサービスまたは待機室）にリクエストを振り分けることができます。
    1. スケーリングとリソース管理の分離:
        • 待機室サービスのトラフィックとチケットサービスのトラフィックは異なるため、それぞれに別々のスケーリング設定を適用することで、リソースの最適化を図ります。これにより、高負荷時でもシステム全体のパフォーマンスを保つことができます。
    1. 運用のシンプルさ:
        • ECS 内でサービスを分割し、CloudFront 関数でリクエストを適切に処理する方法は、比較的シンプルで管理がしやすいです。特に、AWS サービス（ECS、CloudFront）を活用することで、他の技術やインフラストラクチャを複雑にすることなく、スケーラビリティと信頼性を高めることができます。

    他の選択肢との違い:

    • A の選択肢も似たような構成ですが、CloudFront 関数を使用することは含まれていません。CloudFront 関数を使うことで、リクエストの処理がさらに軽量で効率的になります。
    • B と D は、EKS や AWS App Mesh などの新しいテクノロジーを導入するため、運用のオーバーヘッドが大きくなります。ECS のままで解決できる問題をわざわざ EKS に移行して、さらに複雑化する必要はありません。

    結論:

    C の選択肢は、ECS クラスター内でのサービス分割と CloudFront 関数を使った効率的なリクエスト処理により、シンプルで高パフォーマンスな方法です。このアプローチは、待機室サービスとチケットサービスの負荷分散と効率的なリソース管理を実現し、アプリケーションの可用性と信頼性を最も高めることができます。
     
     

    480-AWS SAP AWS 「理論・実践・一問道場」親アカウント のロール

     

    理論

    AWS IAM ロールと信頼ポリシーの理解

    IAM ロール（Identity and Access Management Role）は、AWS リソースやユーザーに権限を付与するためのものです。特定のロールを他の AWS アカウントのユーザーやサービスが「引き受ける」（assume）ことができるように、信頼ポリシーを設定する必要があります。

    信頼ポリシー（Trust Policy）の役割

    • 信頼ポリシーは、ロールを引き受けることができるエンティティ（ユーザー、サービス、アカウントなど）を定義します。
    • ロールが引き受けられるためには、信頼ポリシーでそのエンティティに対して sts:AssumeRole アクションを許可する必要があります。

    親アカウントと子アカウント間でのロールの引き受け

    • クロスアカウントアクセスの場合、子アカウントのリソース（例：EC2 インスタンス）が親アカウントのロールを引き受けるには、親アカウントのロールの信頼ポリシーで 子アカウントのリソースに対する sts:AssumeRole 許可が必要です。
    • 信頼ポリシーには、子アカウントの AWS アカウント ID もしくは IAM ユーザーやロール を指定し、アクセスを許可します。

    ロール引き受けのための設定

    • 親アカウントでロールを作成する際、子アカウントの EC2 インスタンスやリソースがそのロールを引き受けられるように設定することが重要です。
    • もし、EC2 インスタンスが特定のロールを引き受ける権限がない場合、信頼ポリシーの設定ミスが原因です。

    解決策：

    • 信頼ポリシーの修正: 親アカウントのロールに対して、子アカウントの EC2 インスタンスが引き受けられるように sts:AssumeRole 権限を追加します。
    • 必要な権限の明示的指定: 子アカウントに対する権限を明示的に許可することが重要です。

    結論

    クロスアカウントのロール引き受けを正しく設定するには、信頼ポリシーで対象のリソースに対して sts:AssumeRole を許可する設定を行う必要があります。この設定が適切でない場合、権限不足のエラーが発生します。

    実践

    略

    一問道場

    質問 #480
    ソリューションアーキテクトは、既存の手動で作成された非本番環境からAWS CloudFormationテンプレートを作成しています。このCloudFormationテンプレートは必要に応じて削除および再作成できます。環境にはAmazon EC2インスタンスが含まれています。EC2インスタンスには、親アカウントでロールを引き受けるために使用されるインスタンスプロファイルがあります。
    ソリューションアーキテクトはCloudFormationテンプレートでロールを再作成し、同じロール名を使用します。CloudFormationテンプレートが子アカウントで起動されると、EC2インスタンスは親アカウントでロールを引き受けることができなくなり、権限が不十分だというエラーが発生します。
    この問題を解決するためにソリューションアーキテクトは何をすべきですか？
    A. 親アカウントで、EC2インスタンスが引き受ける必要のあるロールの信頼ポリシーを編集します。sts:AssumeRole アクションを許可する既存のステートメントでターゲットロールARNが正しいことを確認し、信頼ポリシーを保存します。
    B. 親アカウントで、EC2インスタンスが引き受ける必要のあるロールの信頼ポリシーを編集します。子アカウントのルートプリンシパルに対して sts:AssumeRole アクションを許可するステートメントを追加し、信頼ポリシーを保存します。
    C. CloudFormationスタックを再度更新します。CAPABILITY_NAMED_IAM 機能のみを指定します。
    D. CloudFormationスタックを再度更新します。CAPABILITY_IAM 機能と CAPABILITY_NAMED_IAM 機能の両方を指定します。

    解説

    背景：

    • AWS CloudFormation を使って、既存の手動で作成した非本番環境を再現しようとしています。
    • この環境には Amazon EC2 インスタンス があり、インスタンスには インスタンスプロファイル が設定されており、これを使って 親アカウント のロール（役割）を引き受ける（assume）ことができます。
    • その後、CloudFormation テンプレートでこのロールを再作成し、同じロール名を使用しています。
    • しかし、CloudFormation テンプレートを 子アカウント で起動すると、EC2 インスタンスは親アカウントのロールを引き受けられなくなり、「権限不足」 というエラーが表示されます。

    問題の本質：

    親アカウントのロールに設定されている 信頼ポリシー（trust policy）が、子アカウントの EC2 インスタンスがそのロールを引き受けることを許可していないため、権限エラーが発生しています。

    解決方法：

    この問題を解決するには、親アカウントのロールの 信頼ポリシー を修正して、子アカウントの EC2 インスタンスがそのロールを引き受けられるようにする必要があります。

    各選択肢の説明：

    1. A. 親アカウントで、EC2 インスタンスが引き受ける必要のあるロールの信頼ポリシーを編集する
        • 正しい設定を確認して、ロールが正常に引き受けられるようにする方法です。ターゲットロール ARN（役割の識別子）が正しいことを確認し、設定を保存します。ターゲットロール ARN が正しいかを確認するだけでは、子アカウントからのアクセスを許可する設定にはなりません。
    1. B. 親アカウントで、EC2 インスタンスが引き受ける必要のあるロールの信頼ポリシーを編集し、子アカウントのルートプリンシパルに対して sts:AssumeRole アクションを許可する
        • これは 正解 です。親アカウントのロールの信頼ポリシーを修正し、子アカウント全体（または子アカウントのルートユーザー）がそのロールを引き受けられるようにする方法です。
    1. C. CloudFormationスタックを再度更新し、CAPABILITY_NAMED_IAM 機能のみを指定する
        • これは 解決策ではありません。CAPABILITY_NAMED_IAM は IAM リソースに関連する変更を許可するオプションですが、権限不足の問題の解決には関係ありません。
    1. D. CloudFormationスタックを再度更新し、CAPABILITY_IAM と CAPABILITY_NAMED_IAM の両方を指定する
        • これも 解決策ではありません。CAPABILITY_IAM と CAPABILITY_NAMED_IAM を指定することで IAM リソースの変更が許可されますが、根本的な権限不足の問題には関係しません。

    正しい解決策：

    • B の選択肢が正解です。親アカウントのロールの信頼ポリシーを編集して、子アカウントの EC2 インスタンスがロールを引き受けられるように設定を変更することで、問題を解決できます。

    まとめ：

    • 親アカウントのロールの信頼ポリシーに 子アカウントの EC2 インスタンスがロールを引き受けることを許可する設定を追加することが、最も効果的な解決方法です。
     
    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
    46-AWS SAP「理論・実践・10問道場」48-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%