Jayendra’s Blog

この記事は自己学習用に「AWS High Availability & Fault Tolerance Architecture(Jayendra’s Blogより)」を日本語に訳した記事です。


AWSの高可用性と耐障害性アーキテクチャ

  • Amazon Web Servicesは、クラウド内に信頼性の高い耐障害で可用性の高いシステムを構築するためのサービスとインフラストラクチャを提供します。
  • 耐障害機能は、システムの構築に使用されたコンポーネントの一部に障害が発生しても、システムが動作し続ける能力を定義します。
  • S3、SimpleDB、SQS、ELBなどの上位サービスのほとんどは、耐障害と高可用性を念頭に置いて構築されています。
  • EC2やEBSなどの基本的なインフラストラクチャを提供するサービスは、耐障害で高可用性のシステムが正しく利用して使用する必要がある、可用性ゾーン、柔軟なIPアドレス、スナップショットなどの特定の機能を提供します。

リージョン&AZ

  • Amazon Web Servicesは、リージョン内で利用でき、リージョン内に複数のAvailability Zone(AZ)があり、冗長な配置場所に簡単にアクセスできます。
  • AZは、他のAZの障害から隔離されるように設計された別個の地理的な場所です。
  • リージョンとAZは、地理的にアプリケーションを配布し、マルチサイトソリューションの構築を支援することにより、より大きな耐障害性を実現します。
  • AZは、同じリージョンの他の可用性ゾーンへの安価で低遅延のネットワーク接続を提供します。
  • EC2インスタンスを複数のAZに配置することで、アプリケーションを1つのデータセンターで障害から保護することができます。
  • 同一リージョンまたは別のリージョンの複数のAZで独立したアプリケーションスタックを実行することが重要です。そのため、あるゾーンに障害が発生した場合でも、他のゾーンのアプリケーションは引き続き実行できます。

Amazonマシンイメージ(AMI)

  • EC2は、Amazon Web Services内のコンピューティング・リソースを提供するWebサービスです。
  • Amazon Machine Image(AMI)は、サービスインスタンスを定義するために使用できるテンプレートを提供します。
  • テンプレートは、基本的にソフトウェア構成(OS、アプリケーションサーバー、アプリケーション)を含み、インスタンスタイプに適用されます。
  • AMIには、すべてのソフトウェア、アプリケーション、バンドルされたコードが含まれているか、起動時にインストールするためのブートストラップスクリプトを持つように設定できます。
  • 単一のAMIを使用して、異なるインスタンス・タイプのサーバー・リソースを作成し、新しいインスタンスの作成または失敗したインスタンスの置換を開始できます。

オートスケーリング

  • オートスケーリングは、定義されたルールに基づいてEC2の容量を自動的に拡大または縮小します。
  • オートスケーリングでは、増加する負荷に対応してさらに多くのインスタンスを追加することもできます。 それらのインスタンスがもはや必要でなくなると、自動的に終了します。
  • オートスケーリングを使用すると、置換インスタンスが自動的に起動されることを認識して、サーバーインスタンスを任意で終了できます。
  • オートスケーリングは、AWSリージョン内の複数のAZで機能します。

Elastic Load Balancing – ELB

  • ELBは、システムの可用性を向上させる効果的な方法であり、着信トラフィックを複数のEC2インスタンスにわたってアプリケーションに分散します。
  • ELBでは、DNSホスト名が作成され、このホスト名に送信された要求はすべてEC2インスタンスのプールに委任されます。
  • ELBは、ホストのヘルスチェック、複数のアベイラビリティゾーンにわたるEC2インスタンスへのトラフィックの分散、およびロードバランシングローテーションからのEC2ホストの動的追加および削除をサポートしています。
  • ELBは、EC2インスタンスのプール内の不健全なインスタンスを検出し、Auto Scalingを使用して不健全なインスタンスがシームレスに復元されるまで、トラフィックを正常なインスタンスに自動的に再ルーティングします。
  • オートスケーリングとELBは理想的な組み合わせです。ELBはアドレッシングに単一のDNS名を指定しますが、自動スケーリングでは、正常な数の正常なEC2インスタンスが要求を受け入れることができます。
  • ELBを使用すると、地域の複数のAZのインスタンス間でバランスをとることができます。

Elastic IP – EIPs

  • ElasticIPアドレスは、静的なIPアドレスです。リージョン内のインスタンス間でプログラム的にマップできます。
  • EIPはAWSアカウントに関連付けられており、特定のインスタンスまたはインスタンスの存続期間ではありません。
  • ElasticIPアドレスは、マスタデータベース、中央ファイルサーバー、EC2ホストロードバランサなど、一貫したエンドポイントが必要なインスタンスやサービスに使用できます。
  • ElasticIPアドレスは、実行中の別のインスタンスまたは直前に置換されたインスタンスにアドレスをすぐに再マッピングすることにより、ホストまたは可用性ゾーンの障害を回避するために使用できます。

リザーブドインスタンス

  • 予約されたインスタンスは、常に低いコストでコンピューティング容量を確保し保証するのに役立ちます。

Elastic Block Store – EBS

  • Elastic Block Store(EBS)は、永続的なオフインスタンスストレージボリュームを提供し、インスタンスの存続期間から独立して存続し、インスタンス上のストレージよりも耐久性があります。
  • EBSボリュームはデータを重複して保存し、単一のAZ内で自動的に複製されます。
  • EBSは、EC2インスタンスに障害が発生して交換が必要な場合、EBSボリュームを新しいEC2インスタンスに接続できるフェールオーバーシナリオで役立ちます。
  • 重要なデータは、適切なバックアップ、レプリケーション、またはデータの再作成機能がないインスタンス(一時的な)ストレージにのみ格納することはできません。

EBSスナップショット

  • EBSボリュームは高い信頼性を備えていますが、障害の可能性をさらに緩和し、耐久性を向上させるために、S3のボリュームにデータを格納するためのポイントインタイムスナップショットを作成し、複数のAZにレプリケートします。
  • スナップショットを使用して、新しいEBSボリュームを作成できます。新しいEBSボリュームは、スナップショットが作成された時点の元のボリュームの正確なレプリカです。
  • スナップショットは、ディスク障害やその他のホストレベルの問題、およびAZに影響を与える問題に対処する効果的な方法を提供します。
  • スナップショットは増分バックアップであり、以前のスナップショット以降の変更のみをバックアップするため、最新のスナップショットを保持することをお勧めします。
  • スナップショットはリージョンに関連付けられ、EBSボリュームは単一のAZに関連付けられます。

リレーショナルデータベースサービス – RDS

  • RDSを使用すると、クラウド内のリレーショナルデータベースを簡単に実行できます。
  • データベースの同期スタンバイレプリカを異なるAZにプロビジョニングするRDS Multi-AZデプロイメントにより、データベースの可用性が向上し、計画外の停止からデータベースが保護されます。
  • フェイルオーバーのシナリオの場合、スタンバイはシームレスにメインに昇格され、データベース操作を処理します。
  • デフォルトで有効になっているデータベースの自動バックアップでは、データベースインスタンスのポイントインタイムリカバリが提供されます。
  • RDSは、データベースとトランザクションログをバックアップし、ユーザー指定の保持期間の両方を格納します。
  • 自動バックアップに加えて、明示的に削除されるまで保持される手動RDSバックアップを実行することもできます。
  • バックアップは、誤ったデータ変更などのより高いレベルの障害から、オペレータエラーまたはアプリケーションのバグによって回復します。
  • RDSリードレプリカは、データベースの読み取り専用レプリカを提供し、単一のデータベース配備の容量を超えてスケ​​ールアウトして、読み取り負荷の高いデータベース作業負荷を実現します。
  • RDSリードレプリカはスケーラビリティであり、高可用性ソリューションではありません。

Simple Storage Service – S3

  • S3は、耐久性の高い耐障害性で冗長なオブジェクトストアを提供します。
  • S3は、S3 Regionの複数の施設にまたがって複数のデバイスに重複してオブジェクトを格納します。
  • S3は、画像、動画、その他の静的メディアなど、静的でもゆっくり変化するオブジェクトでも、優れたストレージソリューションです。
  • S3は、Amazon CloudFrontサービスと相互作用することによって、これらのアセットのエッジキャッシングおよびストリーミングもサポートします。

シンプルキューサービス – SQS

  • シンプルキューサービス(SQS)は、耐障害性アプリケーションのバックボーンとして機能する、信頼性の高い分散型メッセージングシステムです。
  • SQSは、すべてのメッセージを少なくとも1回配信するように設計されています。
  • メッセージがキューに送信されることが保証されているメッセージは、最大4日間、またはアプリケーションによって読み取られて削除されるまで保持されます。
  • メッセージは複数のワーカーによってポーリングされ、処理されますが、SQSでは、可視性のタイムアウトと呼ばれる設定可能な時間間隔を使用して、一度に1人のワーカーのみが要求を処理するよう注意します。
  • キュー内のメッセージ数が増加し始めたり、メッセージの平均処理時間が長くなりすぎると、追加のEC2インスタンスを追加するだけで作業者を拡大することができます。

Route53

  • Amazon Route53は、高可用性と拡張性を備えたDNS Webサービスです。
  • ドメインのクエリは自動的に最寄りのDNSサーバーにルーティングされるため、可能な限り最高のパフォーマンスで応答されます。
  • Route53では、ドメイン名(例:www.example.com)のElastic Load Balancerへのリクエストと zone apex レコード(example.com)が解決されます。

CloudFront

  • CloudFrontは、エッジロケーションのグローバルネットワークを使用して、動的コンテンツ、静的コンテンツ、ストリーミングコンテンツなどのウェブサイトを配信するために使用できます。
  • コンテンツのリクエストは自動的に最寄りのエッジロケーションにルーティングされるため、コンテンツは可能な限り最高のパフォーマンスで配信されます。
  • CloudFrontは、S3やEC2などの他のAmazon Webサービスと連携するように最適化されています。
  • CloudFrontは、AWS以外のオリジナルのサーバーとシームレスに連携し、オリジナルの最終バージョンのファイルを保存します。

AWS認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます(これはあなたと異なる場合があります)。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
  • さらなるフィードバック、ディスカッション、修正を可能にします。
  1. 既存の従来のシステムをAWSに移行すると、移行中に単一障害点であるマスターサーバーが存在することがわかります。マスターサーバーの実装を調べたところ、マイグレーション中に高可用性になるように再設計するための時間が不足していますが、ローカルのMySQLデータベースに状態が保存されていることがわかります。ローカルデータベースを置き換えるためにRDSを選択し、マスターがそれを使用するように構成するための休止時間を最小限に抑えるには、自己修復アーキテクチャを作成するための最善の手順を教えてください。[PROFESSIONAL]
    1. ローカルデータベースをマルチAWS RDSデータベースに移行します。ヘルスチェックを使用して、マスターノードをオートスケーリング・マルチAZに最小1つ、最大1つ配置します(最小1つ、最大1つ)。
    2. ローカルデータベースをRDSリードレプリカにレプリケートします。ヘルスチェックを使用して、マスターノードを最小1個、最大1個のクロスゾーンELBに配置します。 (リード・レプリカはHAおよび書き込み機能を提供せず、ELBはMinおよびMax1の機能を持たず、クロス・ゾーンはインスタンス間のロードの均等な分配を可能にします)
    3. ローカルデータベースをマルチAWS RDSデータベースに移行します。ヘルスチェックを使用して、マスターノードを最小1個、最大1個のクロスゾーンELBに配置します。 (ELBにはMinとMax1の機能はなく、クロスゾーンではインスタンス間のロードの均等な分配が可能です)
    4. ローカルデータベースをRDSリードレプリカにレプリケートします。ヘルスチェックを使用して、マスターノードをマルチAZ・オートスケーリンググループに配置します(最小1つ、最大1つ)。 (リード・レプリカはHAおよび書き込み機能を提供しません)
  2. VPCのインターネット接続を設計しています。 Webサーバーはインターネット上で利用できる必要があります。 アプリケーションには高可用性アーキテクチャが必要です。 あなたはどのような選択肢を検討すべきですか? (2つの回答を選択)
    1. VPCでNATインスタンスを設定します。 NATインスタンス経由でデフォルトルートを作成し、すべてのサブネットに関連付けます。 NATインスタンスのパブリックIPアドレスを指すDNS Aレコードを設定します。 (NATは、プライベートサブネット内のインスタンスのインターネット接続用です)
    2. CloudFrontディストリビューションを構成し、WebサーバーのプライベートIPアドレスを指すように起点を構成します。 Route53 CNAMEレコードをCloudFrontディストリビューションに設定します。
    3. すべてのWebサーバーをELBの背後に置きます。 ELB DNS名を指すようにRoute53 CNAMEを設定します。
    4. すべてのWebサーバーにEIPを割り当てます。 すべてのEIPでRoute53レコードセットを設定します。 ヘルスチェックとDNSフェールオーバー
  3. 高可用性の2層WebアプリケーションをAWSに配備する場合、どのAWSサービスの組み合わせが要件を満たしていますか? 1. AWS Direct Connect / 2. Amazon Route 53 / 3. AWS Storage Gateway / 4.Elastic Load Balancing / 4. Amazon EC2 / 5.自動スケーリング / 6. Amazon VPC / 7. AWS Cloud Trail [PROFESSIONAL]
    1. 2,4,5および6
    2. 3,4,5および8
    3. 1〜8
    4. 1,3,5および7
    5. 1,2,5および6
  4. A社は、登録ユーザーが地元のレストランを評価できるインタラクティブなWebサイトの移行を支援するためにあなたを雇いました。レーティングの更新はホームページに表示され、レーティングはリアルタイムで更新されます。今日のウェブサイトはあまり人気がありませんが、今後数週間で急速に成長すると予想しています。彼らは、サイトの可用性を高くしたいと考えています。現在のアーキテクチャは、単一のWindows Server 2008 R2 WebサーバーとLinux上で動作するMySQLデータベースで構成されています。両方ともオン・ハイ・ハイパーバイザーの内部に存在します。 AWSにアプリケーションを転送し、パフォーマンスと高可用性を保証する最も効率的な方法は何でしょうか? [PROFESSIONAL]
    1. us-west-1のAmazon S3バケットにWebファイルをエクスポートします。 Amazon S3から直接Webサイトを実行します。 us-west-1aで複数のAZのMySQL Amazon RDSインスタンスを起動します。最新のMySQLバックアップからAmazon RDSにデータをインポートします。Route53を使用し、ELBを指すエイリアスレコードを作成します。 (インタラクティブなウェブサイトはS3でJavascript SDKを使用してホストすることができます)
    2. us-west-1bでは2つのWindows Server 2008 R2インスタンスを、us-west-1aでは2つのインスタンスを起動します。 Amazon S3をリポジトリとして使用して、オンデマンドWebサーバーから各Amazon EC2 WebサーバーにWebファイルをコピーします。 us-west-2aでマルチAZのMySQL Amazon RDSインスタンスを起動します。最新のMySQLバックアップからAmazon RDSにデータをインポートします。 Webサーバーの前にELBを作成します。Route53を使用し、ELBを指すエイリアスレコードを作成します。 (RDSインスタンスはパフォーマンスに影響を与える別のリージョンにあります)
    3. AWS VM Import / Exportを使用して、WebサーバーのAmazon Elastic Compute Cloud(EC2)Amazon Machine Image(AMI)を作成します。 us-west-1aとus-west-1bの2つのWebサーバを起動するように自動スケーリングを設定します。 us-west-1bにマルチAZ MySQL Amazon Relational Database Service(RDS)インスタンスを起動します。最新のMySQLバックアップからAmazon RDSにデータをインポートします。 AmazonRoute53を使用して、ホストされたゾーンを作成し、Aレコードをエラスティックロードバランサに向けます。 (ロードバランサを作成しません)
    4. AWS VMのインポート/エクスポートを使用して、WebサーバーのAmazon EC2 AMIを作成します。 us-west-1aとus-west-1bの2つのWebサーバを起動するように自動スケーリングを設定します。 us-west-1aでマルチAZのMySQL Amazon RDSインスタンスを起動します。最新のMySQLバックアップからAmazon RDSにデータをインポートします。 Webサーバーの前にELBを作成します。 Amazon Route 53を使用して、ELBを指すAレコードを作成します。 (別名レコードを作成する必要があります)
  5. あなたの会社はイベント登録サイトに直面している顧客を運営しています。このサイトは、Webおよびアプリケーション層サーバーとMySQLデータベースを備えた3層アーキテクチャで構築されています。アプリケーションには、通常の操作では6つのWeb層サーバーと6つのアプリケーション層サーバーが必要ですが、サーバー容量と1つのMySQLデータベースで最低65%の稼働率が得られます。3つの可用性ゾーン(AZ)を持つリージョンにこのアプリケーションを配備する場合、どのアーキテクチャが高可用性を提供しますか?[PROFESSIONAL]
    1. ELB(エラスティックロードバランサ)の背後にある自動スケーリンググループ内の各AZに3つのEC2(Elastic Compute Cloud)インスタンスを持つ2つのAZに展開されたWeb層、および各AZに3つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBの背後にある自動スケーリンググループ。 1つのRDS(Relational Database Service)インスタンスが、他のAZにリードレプリカとともに配置されています。
    2. ELB(エラスティックロードバランサ)の背後にある自動スケーリンググループ内の各AZに2つのEC2(Elastic Compute Cloud)インスタンスを持つ3つのAZに展開されたWeb層と、Auto内の各AZに2つのEC2インスタンスを持つ3つのAZに展開されたアプリケーション層ELBと1つのRDS(Relational Database Service)インスタンスの背後にあるScaling Groupは、2つの他のAZでリードレプリカを展開しています。
    3. ELB(エラスティックロードバランサ)の背後にあるAuto Scaling Group内の各AZに3つのEC2(Elastic Compute Cloud)インスタンスを持つ2つのAZに展開されたWeb層と、Auto内に3つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBと複数AZ RDS(リレーショナルデータベースサービス)展開の背後にあるスケーリンググループ
    4. ELB(エラスティックロードバランサ)の背後にある自動スケーリンググループ内の各AZに2つのEC2(Elastic Compute Cloud)インスタンスを持つ3つのAZに展開されたWeb層。 ELBの背後にある自動スケーリンググループ内の各AZに2つのEC2インスタンスを持つ3つのAZに展開されたアプリケーション層。また、マルチAZ RDS(リレーショナルデータベースサービス)展開。
  6. 2つのAZを持つリージョンで動作するMySQLデータベースを利用する3層の顧客向けの悪天候のサイトでは、アーキテクチャ内で耐障害性を提供するアプリケーションでは、6つのWeb層サーバーと6つのアプリケーション層サーバーが必要ですWebおよびアプリケーション層と1つのMySQLデータベース[PROFESSIONAL]
    1. ELB(エラスティックロードバランサ)の背後にあるAuto Scaling Group内の各AZに6つのEC2(Elastic Compute Cloud)インスタンスを持つ2つのAZに展開されたWeb層、および各AZに6つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBの背後にある自動スケーリンググループ。およびMulti-AZ RDS(Relational Database Service)デプロイメントをサポートしています。
    2. ELB(エラスティックロードバランサ)の背後にあるAuto Scaling Group内の各AZに3つのEC2(Elastic Compute Cloud)インスタンスを持つ2つのAZに展開されたWeb層と、Auto内の各AZに3つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBとマルチAZ RDS(リレーショナルデータベースサービス)展開の背後にあるスケーリンググループ
    3. ELB(エラスティックロードバランサ)の背後にあるAuto Scaling Group内の各AZに3つのEC2(Elastic Compute Cloud)インスタンスを持つ2つのAZに展開されたWeb層と、Auto内の各AZに6つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBと1つのRDS(リレーショナルデータベースサービス)インスタンスの背後にあるスケーリンググループは、他のAZのリードレプリカで展開されます。
    4. ELB(エラスティックロードバランサ)の背後にある自動スケーリンググループ内の各AZに6つのEC2(Elastic Compute Cloud)インスタンスを持つ1つのAZに展開されたWeb層。また、6つの停止したWeb層EC2インスタンスと6つの停止したアプリケーション層EC2インスタンスを含む、ELBとMulti-AZ RDS(リレーショナルデータベースサービス)配備の背後にある自動スケーリンググループ内の6つのEC2インスタンスを持つ同じAZに、第1のAZ内の実行中のインスタンスのいずれかが失敗した場合、他のAZは起動準備が整う。
  7. トラフィックを処理するために最低8 m4の大きなインスタンスを必要とするシステムを設計しています。 6つのAZを持つus-east-1地域で高可用性を実現するシステムを設計する場合、企業はフルアベイラビリティゾーンの死を処理できる必要があります。すべてのEC2ノードがELBに適切にリンクされていると仮定して、できるだけ多くのコストを節約するために、サーバーをどのように配布する必要がありますか?あなたのVPCアカウントはus-east-1のAZのa〜fを利用することができます。
    1. 各AZのa〜dの3つのサーバー
    2. 各AZのaとbの8つのサーバー
    3. 各AZのa〜eに2つのサーバー
    4. 各AZのa〜cに4つのサーバー
  8. リージョナルAWSの全面的な失敗時にオンライン状態を維持するには、DynamoDBに裏付けされたAPIが必要です。大規模な障害イベント中に数分の遅延や低速を許容することはできますが、システムは数分後に通常の操作で復旧する必要があります。良いアプローチは何ですか? [PROFESSIONAL]
    1. 別のリージョンに1つのスタンバイを持つマスタースタンバイ構成で、DynamoDBクロスリージョンレプリケーションを設定します。 DynamoDBが実行されている2つのリージョンのELBの背後に自動スケーリンググループを作成します。2つのリージョンのELBをリソースレコードとして使用して、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードを追加します。 (2つのELBとRoute53のフェールオーバーと遅延DNSを持つASGを持つDynamoDBクロスリージョンレプリケーションバージョンを使用してください)
    2. DynamoDBマルチリージョンテーブルを設定します。 DynamoDBが実行されている2つのリージョンのELBの背後に自動スケーリンググループを作成します。2つのリージョンのELBをリソースレコードとして使用して、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードを追加します。 (DynamoDBマルチリージョンテーブルのようなものはありません)
    3. DynamoDBマルチリージョンテーブルを設定します。クロスリージョン自動スケーリンググループを指すクロスリージョンELBを作成し、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードをクロスリージョンELBに転送します。 (クロスリージョンELBまたはクロスリージョンASGのようなものはありません)
    4. 別のリージョンに1つのスタンバイを持つマスタースタンバイ構成で、DynamoDBクロスリージョンレプリケーションを設定します。クロスリージョン自動スケーリンググループを指すクロスリージョンELBを作成し、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードをクロスリージョンELBに転送します。 (DynamoDBのクロス・リージョン・テーブルまたはクロスリージョンELBのようなものはありません)
  9. あなたは地元の慈善団体のためにWordPressサイトを構築しており、Route53、Elastic Load Balancer、EC2&RDSの組み合わせを使用しています。 EC2インスタンスを起動し、WordPressをダウンロードして設定ファイルの接続文字列をセットアップして、RDSと通信できるようにします。 ただし、URLを参照すると何も起こりません。 次のうちどれがこの原因ではない可能性がありますか。
    1. EC2インスタンスが配置されているセキュリティグループでポート80/443を開くのを忘れてしまった。
    2. ELBにはヘルスチェックがあり、存在しないWebページをチェックしています。 したがって、EC2インスタンスは稼動していません。
    3. AレコードがELBを指すようにALIASを設定していません。
    4. ポート22を特定のIPアドレスに固定すると、ユーザーはHTTP / HTTPSを使用してサイトにアクセスできなくなります。
  10. 現在開発中の開発チームは、夜間に6時間のビルドを行っており、大規模でほとんど利用されていないサーバーを使用して、社内で時間をかけて長くなっていますが、同じ日に起動される複数のビルドをAWS上で継続的に展開する統合モデル。ただし、コスト、セキュリティ、およびオフサイトでは移動できないLDAPや電子メールサーバーなどの既存のオンプレミスアプリケーションとの統合方法については懸念されています。開発環境にはソースコードリポジトリが必要です。ビルドを実行するためのMySQLデータベースリソースと、QAがビルドをピックアップするための格納場所を持つプロジェクト管理システム。開発チームの要件を満たすためにAWSのどのサービスの組み合わせをお勧めしますか? [PROFESSIONAL]
    1. BastionホストオンプレミスからアクセスするためのVPNサーバーを実行するAmazon EC2インスタンス、接続されたAmazon EBSボリュームを持つAmazon EC2、Amazon EC2およびAmazon RDS、プロジェクト管理システム用のMySQL、ソースコードリポジトリおよびプロジェクト用のEIPビルドキューのためのAmazon SQL、ビルドを実行するためのAmazon EC2インスタンスのAmazon Auto Scalingグループ、ビルド出力を送信するためのAmazon Simple Email Serviceが含まれます。 (BastionはVPN接続用ではない。SESは使用しないでください)
    2. オンプレミスのソフトウェアアプリケーションとクラウドベースのストレージを安全に接続するAWS Storage Gateway、Amazon EBSボリュームを伴うリソースコードリポジトリ用のAmazon EC2、プロジェクト管理システム用のAmazon EC2とAmazon RDS MySQL、ソースコードリポジトリ用のEIP、プロジェクト管理システム、通知開始ビルド用のAmazon Simple Notification Service、ビルドを実行するAmazon EC2インスタンスのAuto Scalingグループ、ビルド出力用のAmazon S3が含まれます。 (Storage Gatewayは安全な接続性を提供せず、VPNはまだ必要です。SNSだけではビルドを処理できません)
    3. オンプレミスのソフトウェアアプリケーションとクラウドベースのストレージを安全に接続するAWS Storage Gateway、Amazon EBSボリュームを伴うリソースコードリポジトリ用のAmazon EC2、プロジェクト管理システム用のAmazon EC2とAmazon RDS MySQL、ソースコードリポジトリ用のEIP、プロジェクト管理システム、ビルドキューのAmazon SQS、ビルドを実行するためのAmazon EC2インスタンスのAmazon Elastic Map Reduce(EMR)クラスタ、ビルド出力のためのAmazon CloudFrontが含まれます。 (Storage Gatewayは安全な接続性を提供せず、VPNを必要とします.EMRは通常のEC2インスタンスが必要なため、ビルドを実行するのには理想的ではありません)
    4. オンプレミスサーバーに戻るVPNゲートウェイを備えたVPC、添付されたAmazon EBSボリュームを持つソースコードリポジトリ用のAmazon EC2、プロジェクト管理システム用のAmazon EC2およびAmazon RDS MySQL、ソースコードリポジトリおよびプロジェクト管理システム用のEIP 、ビルドキューのSQS、ビルドを実行するEC2インスタンスの自動スケーリンググループ、ビルド出力のS3があります。 (安全な接続のためにはVPNゲートウェイが必要です。ビルドキューのSQSとビルドのEC2)

リファレンス