このチュートリアルでは、安全で可用性の高い仮想プライベートクラウドアーキテクチャをセットアップし、CloudFormationを使用してセットアップを自動化する方法について説明します。
このVPC内で基本的な高可用性アプリケーションをホストします。
また、コストも考慮に入れます。つまり、重要でないリソースを高可用性にすることはありません。

AWSでの高可用性

AWSでは、リソースをデプロイして、eu-west-1（EUアイルランド）、us-east-1（US N. Virgina）などのさまざまなリージョンでサービスを使用できます。すべてのAWSリージョンは、複数のアベイラビリティーゾーンで構成されています。アベイラビリティーゾーン（AZ）は、厳重に保護された1つ以上のデータセンターで構成されます。アベイラビリティーゾーンは、互いに数十マイル/数百マイル離れて構築されています。AZ間の距離のため、地震、津波、攻撃などの災害のために両方のゾーンが同時にダウンすることはほぼ不可能です。
AWSの世界では、「高可用性」という用語は、1つのAZがダウンしてもインフラストラクチャが引き続き利用可能であることを意味します。

VPCのアーキテクチャ

アーキテクチャを見て、すべてのコンポーネントについて説明しましょう。

インフラ側

• VPC：Amazon Virtual Private Cloudを使用すると、AWSリソースを起動できるAmazon Web Services（AWS）クラウドの論理的に分離されたセクションをプロビジョニングできます。VPCのIPv4アドレスの範囲をCIDRブロック（10.0.0.0/16など）の形式で指定する必要があります。VPCは、リージョン内のすべてのアベイラビリティーゾーンにまたがっています。
  →セットアップには1つのVPCが必要です。
• サブネット：VPCには複数のサブネットが含まれています。サブネットはパブリックまたはプライベートにすることができ、1つのアベイラビリティーゾーンにまたがっています。Therenは、VPCCIDRのサブセットであるサブネットのCIDRブロックでもあります。
  →セットアップには4つのサブネットが必要です。それぞれ異なるアベイラビリティーゾーンにある2つのパブリックサブネットと2つのプライベートサブネットを使用します。1つのゾーンがダウンした場合でも、パブリックサブネットとプライベートサブネットを使用できます。
• IGW：インターネットゲートウェイは、VPCのインターネットへのアクセスを可能にするリソースです。IGWを介してインターネット（0.0.0.0/0）へのルートを持つすべてのサブネットはパブリックサブネットです。このサブネット内のリソースはインターネットと通信できます。
  →IGWはそれ自体で可用性が高く、帯域幅の制約がないため、1つのIGWのみをデプロイする必要があります。
• NATゲートウェイ：パブリックVPCサブネットのNATゲートウェイを使用して、プライベートサブネットのインスタンスからのアウトバウンドインターネットトラフィックを有効にします。プライベートサブネットには、NATゲートウェイを介してインターネットへのルートが必要です。
  →コストの観点から、NATゲートウェイを1つだけ展開します。その結果、NATが展開されているアベイラビリティーゾーンがダウンすると、プライベートサブネット内のインスタンスがインターネットアクセスを失います。
  これはアプリケーションにとって重要ではなく、アプリは引き続き機能します。これが、新しいNATゲートウェイを高可用性にするのではなく手動で起動することを好む理由ですが、もちろん、すべてのアベイラビリティーゾーンにNATゲートウェイを展開することは可能です。
• 要塞ホスト：要塞ホストは、SSHゲートウェイとして機能する安全なパブリックインスタンスです。このパブリックインスタンスにSSHで接続し、このインスタンス内からプライベートIPを使用してプライベートインスタンスにSSHで接続できます。
  要塞ホストは、インスタンスへのSSHアクセスを制限できるセキュリティグループによって保護されています。
  →要塞ホストを1つ配備します。この場合も、実行中のアベイラビリティーゾーンがダウンすると、このインスタンスはダウンします。ただし、NATゲートウェイと同様に、アプリケーションは影響を受けないため、要塞ホストの可用性を高くしないことにします。アベイラビリティーゾーンが停止した場合は、動作中のAZのパブリックサブネット内でEC2を起動できます。
  自動スケーリングを使用して、要塞ホストの高可用性を実現できます。
• ルートテーブル：ルートテーブルには、ネットワークトラフィックの送信先を決定するために使用される、ルートと呼ばれる一連のルールが含まれています。VPCの各サブネットは、ルートテーブルに関連付けられている必要があります。このテーブルは、サブネットのルーティングを制御します。サブネットは一度に1つのルートテーブルにのみ関連付けることができますが、複数のサブネットを同じルートテーブルに関連付けることができます。
  →ルートテーブルは、ルーターに代わるAWSが提供する高可用性サービスです。それらを構成する必要がありますが、高可用性にする必要はありません。
• セキュリティグループ：セキュリティグループには、セキュリティグループが属するリソースに誰がアクセスできるかを許可するルールが含まれています。この場合、ALB（誰もがポート80でアクセスできます）、要塞ホスト（誰もがポート22でSSHできます）、およびEC2インスタンス（ALBのみがポート80でインスタンスにアクセスできます）のセキュリティグループがあります。
  →セキュリティグループは高可用性リソースです。私たちの環境でそれらを高可用性にすることを考える必要はありません。

• EC2：私たちのアプリケーションである基本的なApacheWebサーバーはEC2インスタンスでホストされています。
  →EC2がデプロイされているAZ（およびその結果としてサブネット）がダウンするとEC2が使用できなくなるため、異なるサブネットに2つのEC2インスタンスをデプロイします。
• アプリケーションロードバランサー：ALBは、2つのEC2インスタンスへのトラフィックを負荷分散します。それらの1つがダウンしている場合、ALBはすべてのトラフィックを正常なインスタンスにルーティングします。インスタンスに自動スケーリングを実装することでこれをより高度にすることができますが、これはこのチュートリアルの範囲外です。
  →ALBを1つだけデプロイする必要があります。内部的には、ALBは複数のサブネット内の複数のEC2とAZで構成されています。1つのAZがダウンしても、ALBは影響を受けません。AWSのスマートな実装により、このサービスは高可用性です。

この環境全体をセットアップするためのCloudFormationテンプレートは、私のGitHubで入手できます。テンプレートをフォーク/スター付けしてください。

テンプレートは、前の章で説明したリソースを作成します。ここでは、ルートテーブルの構成がどのように実装されているかも確認できます。GitHubのReadmeにはまた、リソースがAmazonアカウントに作成されるの完全なリストが含まれています。

1. AWSCLIをインストールします
2. AWSCLIを設定する
3. AWSKeyPairを作成する
4. リポジトリのフォーク/クローン作成
5. parameters.jsonを個人の値で更新します
6. スタックをデプロイします。

$ aws cloudformation create-stack --stack-name vpc-demo --template-body file://template.yaml --parameters file://parameters.json

結論

AWSの世界で高可用性が何を意味するかを学びました。
その後、アプリケーションロードバランサーとWebアプリケーションをホストする2つのEC2を含むコスト最適化された高可用性AWS環境を確認しました。このチュートリアルを楽しんでいただけたでしょうか。