VPC でのスタックの実行 - AWS OpsWorks
VPC の基本AWS OpsWorks スタックスタック用の VPC を作成する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

VPC でのスタックの実行

重要

この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、 AWS re:Post またはAWS プレミアムサポートを通じて AWS サポート チームにお問い合わせください。

仮想プライベートクラウド (VPC) でスタックを作成することにより、スタックのインスタンスへのユーザーアクセスを制御できます。たとえば、スタックのアプリケーションサーバーまたはデータベースにユーザーが直接アクセスできるようにしたくない場合、代わりに、すべてのパブリックトラフィックが Elastic Load Balancing を経由するようにします。

VPC でスタックを実行するための基本的な手順は次のとおりです。

  1. Amazon VPC コンソールか API、または AWS CloudFormation テンプレートを使用することにより、適切に設定された VPC を作成します。

  2. スタックを作成する際に VPC ID を指定します。

  3. 適切なサブネットでスタックのインスタンスを起動します。

AWS OpsWorks スタックでの VPC の動作について、以下に簡単に説明します。

重要

VPC エンドポイント機能を使用する場合、スタックの各インスタンスは、Amazon Simple Storage Service (Amazon S3) から次のアクションを実行できる必要があることに注意してください。

  • インスタンスエージェントをインストールする。

  • Ruby などの資産をインストールする。

  • Chef の実行ログをアップロードする。

  • スタックコマンドを取得する。

これらのアクションを有効にするには、スタックのインスタンスが、スタックのリージョンと一致する、以下のバケットにアクセスできる必要があります。それ以外の場合、前述のオペレーションは失敗します。

Chef 12 Linux および Chef 12.2 Windows の場合、バケットは以下のとおりです。

エージェントバケット 資産バケット ログバケット DNA バケット

  • opsworks-instance-agent-sa-east-1

  • opsworks-instance-agent-ap-south-1

  • opsworks-instance-agent-ap-northeast-1

  • opsworks-instance-agent-ap-northeast-2

  • opsworks-instance-agent-ap-southeast-1

  • opsworks-instance-agent-ap-southeast-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-west-1

  • opsworks-instance-agent-eu-west-2

  • opsworks-instance-agent-eu-west-3

  • opsworks-instance-agent-us-east-1

  • opsworks-instance-agent-us-east-2

  • opsworks-instance-agent-us-west-1

  • opsworks-instance-agent-us-west-2

  • opsworks-instance-assets-us-east-2

  • opsworks-instance-assets-us-east-1

  • opsworks-instance-assets-ap-south-1

  • opsworks-instance-assets-ap-northeast-1

  • opsworks-instance-assets-ap-northeast-2

  • opsworks-instance-assets-ap-southeast-1

  • opsworks-instance-assets-ap-southeast-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-west-1

  • opsworks-instance-assets-eu-west-2

  • opsworks-instance-assets-eu-west-3

  • opsworks-instance-assets-sa-east-1

  • opsworks-instance-assets-us-west-1

  • opsworks-instance-assets-us-west-2

  • opsworks-us-east-2-log

  • opsworks-us-east-1-log

  • opsworks-ap-south-1-log

  • opsworks-ap-northeast-1-log

  • opsworks-ap-northeast-2-log

  • opsworks-ap-southeast-1-log

  • opsworks-ap-southeast-2-log

  • opsworks-ca-central-1-log

  • opsworks-eu-central-1-log

  • opsworks-eu-west-1-log

  • opsworks-eu-west-2-log

  • opsworks-eu-west-3-log

  • opsworks-sa-east-1-log

  • opsworks-us-west-1-log

  • opsworks-us-west-2-log

  • opsworks-us-east-2-dna

  • opsworks-us-east-1-dna

  • opsworks-ap-south-1-dna

  • opsworks-ap-northeast-1-dna

  • opsworks-ap-northeast-2-dna

  • opsworks-ap-southeast-1-dna

  • opsworks-ap-southeast-2-dna

  • opsworks-ca-central-1-dna

  • opsworks-eu-central-1-dna

  • opsworks-eu-west-1-dna

  • opsworks-eu-west-2-dna

  • opsworks-eu-west-3-dna

  • opsworks-sa-east-1-dna

  • opsworks-us-west-1-dna

  • opsworks-us-west-2-dna

Linux 用 Chef 11.10 以前のバージョンの場合、バケットは次のとおりです。Chef 11.4 スタックは、米国東部 (バージニア北部) リージョン 以外のリージョンエンドポイントではサポートされていません。

エージェントバケット 資産バケット ログバケット DNA バケット

  • opsworks-instance-agent-us-east-2

  • opsworks-instance-agent-us-east-1

  • opsworks-instance-agent-ap-south-1

  • opsworks-instance-agent-ap-northeast-1

  • opsworks-instance-agent-ap-northeast-2

  • opsworks-instance-agent-ap-southeast-1

  • opsworks-instance-agent-ap-southeast-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-west-1

  • opsworks-instance-agent-eu-west-2

  • opsworks-instance-agent-eu-west-3

  • opsworks-instance-agent-us-east-1

  • opsworks-instance-agent-us-west-1

  • opsworks-instance-agent-us-west-2

  • opsworks-instance-assets-us-east-2

  • opsworks-instance-assets-us-east-1

  • opsworks-instance-assets-ap-south-1

  • opsworks-instance-assets-ap-northeast-1

  • opsworks-instance-assets-ap-northeast-2

  • opsworks-instance-assets-ap-southeast-1

  • opsworks-instance-assets-ap-southeast-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-west-1

  • opsworks-instance-assets-eu-west-2

  • opsworks-instance-assets-eu-west-3

  • opsworks-instance-assets-sa-east-1

  • opsworks-instance-assets-us-west-1

  • opsworks-instance-assets-us-west-2

  • prod_stage-log

  • prod_stage-dna

詳細については、「VPC エンドポイント」を参照してください。

注記

AWS OpsWorks スタックを有効にした VPC エンドポイントに接続するには、 スタックエージェントは引き続きパブリックエンドポイントにアクセスする必要があるため、NAT またはパブリック IP AWS OpsWorks のルーティングも設定する必要があります。

VPC の基本

VPC の詳細については、「Amazon Virtual Private Cloud ユーザーガイド」を参照してください。端的に言えば、VPC は 1 つ以上のサブネットで構成され、各サブネットには 1 つ以上のインスタンスが含まれています。また、各サブネットには、送信先 IP アドレスに基づいてアウトバウンドトラフィックを送信する、関連付けられたルーティングテーブルがあります。

  • VPC にあるインスタンスはサブネットに関係なくデフォルトで相互に通信できます。ただし、ネットワークアクセスコントロールリスト (ACL) やセキュリティグループポリシーを変更したり静的 IP アドレスを使用すると、この通信を遮断してしまう可能性があります。

  • サブネットのインスタンスがインターネットと通信できる場合、このサブネットはパブリックサブネットと呼ばれます。

  • サブネットのインスタンスが VPC 内の他のインスタンスとのみ通信でき、インターネットとは直接通信できない場合、このサブネットはプライベートサブネットと呼ばれます。

AWS OpsWorks スタックでは、プライベートサブネットのインスタンスを含むスタック内のすべてのインスタンスが次のエンドポイントにアクセスできるように VPC を設定する必要があります。

  • 「」の「リージョンサポート」セクションに記載されている AWS OpsWorks スタックサービスエンドポイントの 1 つAWS OpsWorks スタックの開始方法。

  • AWS OpsWorks スタックエージェントで使用される、次のいずれかのインスタンスサービスエンドポイント。エージェントは、マネージドカスタマーインスタンスで実行され、サービスとデータを交換します。

    • opsworks-instance-service.us-east-2.amazonaws.com

    • opsworks-instance-service.us-east-1.amazonaws.com

    • opsworks-instance-service.us-west-1.amazonaws.com

    • opsworks-instance-service.us-west-2.amazonaws.com

    • opsworks-instance-service.ap-south-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-2.amazonaws.com

    • opsworks-instance-service.ap-southeast-1.amazonaws.com

    • opsworks-instance-service.ap-southeast-2.amazonaws.com

    • opsworks-instance-service.ca-central-1.amazonaws.com

    • opsworks-instance-service.eu-central-1.amazonaws.com

    • opsworks-instance-service.eu-west-1.amazonaws.com

    • opsworks-instance-service.eu-west-2.amazonaws.com

    • opsworks-instance-service.eu-west-3.amazonaws.com

  • Amazon S3

  • オペレーティングシステムに応じたパッケージリポジトリ (Amazon Linux や Ubuntu Linux のリポジトリなど)。

  • 使用するアプリケーションとカスタムクックブックのリポジトリ

この接続が可能になるように VPC を設定する方法はさまざまです。以下は、 スタックアプリケーションサーバースタックの VPC AWS OpsWorks を設定する方法の簡単な例です。

VPC diagram showing public and private subnets, NAT, load balancing, and connections to external services.

この VPC には複数のコンポーネントがあります。

サブネット

この VPC には 2 つのサブネットがあります。1 つはパブリック、もう 1 つはプライベートです。

  • パブリックサブネットには、ロードバランサーとネットワークアドレス変換 (NAT) デバイスがあり、外部アドレスおよびプライベートサブネットのインスタンスと通信できます。

  • プライベートサブネットにはアプリケーションサーバーがあり、パブリックサブネットの NAT およびロードバランサーと通信できますが、外部アドレスとは直接通信できません。

インターネットゲートウェイ

インターネットゲートウェイがある場合は、パブリック IP アドレスを使用するインスタンス (ロードバランサーなど) が VPC 外のアドレスと通信できます。

ロードバランサー

Elastic Load Balancing ロードバランサーは、ユーザーからの着信トラフィックを処理し、プライベートサブネットのアプリケーションサーバーに配信して、ユーザーにレスポンスを返します。

NAT

NAT デバイスは、アプリケーションサーバーが制限付きでインターネットにアクセスできるようにします。通常は、外部リポジトリからソフトウェア更新をダウンロードするなどの目的で使用されます。すべての AWS OpsWorks スタックインスタンスは、 AWS OpsWorks スタックおよび適切な Linux リポジトリと通信できる必要があります。この問題に対処する方法の 1 つは、関連付けられた Elastic IP アドレスを使用する NAT デバイスをパブリックサブネット内に配置することです。そうすれば、プライベートサブネット内のインスタンスからのアウトバウンドトラフィックを NAT を介してルーティングすることができます。

注記

NAT インスタンスが 1 つあれば、プライベートサブネットのアウトバウンドトラフィックに単一障害点が生まれます。一方に障害が発生した場合に互いにその機能を引き継ぐ NAT インスタンスのペアを使用して VPC を設定することで、信頼性を向上させることができます。詳細については、「Amazon VPC NAT インスタンスの高可用性」を参照してください。NAT ゲートウェイを使用することもできます。詳細については、「Amazon VPC User Guide」(Amazon VPC ユーザーガイド) の「NAT」を参照してください。

最適な VPC 設定は AWS OpsWorks 、 スタックスタックによって異なります。特定の VPC 設定を使用する場合のいくつかの例を次に示します。その他の VPC のシナリオの例については、「Amazon VPC のシナリオ」を参照してください。

パブリックサブネットで 1 つのインスタンスを使用する

パブリックアクセスすべきでない Amazon RDS インスタンスのように、関連するプライベートリソースのないシングルインスタンスのスタックがある場合、1 つのパブリックサブネットを持つ VPC を作成し、そのサブネットにインスタンスを配置できます。デフォルトの VPC を使用しない場合、このインスタンスのレイヤーでは Elastic IP アドレスをこのインスタンスに割り当てる必要があります。詳細については、「OpsWorks レイヤーの基本」を参照してください。

プライベートリソースを使用する

パブリックにアクセス可能にしてはならないリソースがある場合は、パブリックサブネット 1 つとプライベートサブネット 1 つを持つ VPC を作成できます。例えば、自動スケーリングを使用する負荷分散環境では、プライベートサブネットにすべての Amazon EC2 インスタンスを配置し、パブリックサブネットにロードバランサーを配置することができます。こうすると、インターネットから Amazon EC2 インスタンスに直接アクセスすることはできませんが、すべての受信トラフィックはロードバランサー経由でルーティングされます。

プライベートサブネットでは、インスタンスを Amazon EC2 の直接ユーザーアクセスから隔離しますが、AWS および Linux パッケージリポジトリへのアウトバウンドリクエストは送信する必要があります。このようなリクエストを許可するために、たとえば、固有の Elastic IP アドレスを持つネットワークアドレス変換 (NAT) デバイスを使用し、NAT 経由でインスタンスのアウトバウンドトラフィックをルーティングすることができます。前の例に示すように、NAT はロードバランサーと同じパブリックサブネットに配置できます。

  • Amazon RDS インスタンスなどのバックエンドデータベースを使用している場合は、それらのインスタンスをプライベートサブネットに配置することができます。Amazon RDS インスタンスの場合、異なるアベイラビリティーゾーンに異なるサブネットを、少なくとも 2 つ指定する必要があります。

  • プライベートサブネットのインスタンスに直接アクセスする必要がある場合 (例えば、SSH を使用してインスタンスにログインする場合)、インターネットからリクエストをプロキシする bastion ホストをパブリックサブネットに配置できます。

独自のネットワークを AWS に拡張する

独自のネットワークをクラウドに拡張し、VPC からインターネットへの直接アクセスを可能にする必要がある場合は、VPN ゲートウェイを作成できます。詳細については、「シナリオ 3: パブリックサブネットとプライベートサブネット、およびハードウェア VPN アクセスを持つ VPC」を参照してください。

AWS OpsWorks スタックスタック用の VPC を作成する

このセクションでは、サンプルの AWS CloudFormation テンプレートを使用して AWS OpsWorks スタックの VPC を作成する方法を示します。このテンプレートは、OpsWorksVPCtemplates.zip ファイルでダウンロードできます。このトピックで説明するような VPC を手動で作成する方法の詳細については、「シナリオ 2: パブリックサブネットとプライベートサブネットを持つ VPC」を参照してください。ルーティングテーブル、セキュリティグループなどを設定する方法の詳細については、サンプルテンプレートを参照してください。

注記

デフォルトでは、 AWS OpsWorks スタックは CIDR 範囲と などのアベイラビリティーゾーンを連結してサブネット名を表示します10.0.0.1/24 - us-east-1b。名前をより読みやすくするには、キーを に設定Nameし、値をサブネット名に設定して、サブネットごとにタグを作成します。 AWS OpsWorks スタックは、サブネット名をデフォルト名に追加します。たとえば、次のプライベートサブネットには [Name] が Private に設定されたタグがあり、OpsWorks では 10.0.0.1/24 us-east - 1b - Private のように表示されます。

VPC テンプレートは、わずか数ステップで AWS CloudFormation コンソールを使用して起動できます。以下の手順では、サンプルテンプレートを使用して、米国東部 (バージニア北部) リージョンに VPC を作成します。テンプレートを使用してその他のリージョンに VPC を作成する方法については、手順の後の注意を参照してください。

VPC を作成するには

  1. AWS CloudFormation コンソールを開き、[米国東部 (バージニア北部)] リージョンを選択し、[スタックの作成] を選びます。

  2. [Select Template] ページで、[Upload a template] を選択します。OpsWorksVPCtemplates.zip ファイル でダウンロードしたOpsWorksinVPC.templateファイルを閲覧し、続行を選択します。

    CloudFormation Select Template ページ

    このスタックを起動するには、AWS CloudFormation サンプルテンプレートを開き、 AWS OpsWorks スタック VPC テンプレートを見つけて、起動スタックを選択します。

  3. [Specify Parameters (パラメータを指定)] ページで、デフォルトの値をそのまま使用して、[Continue (続行)] を選択します。

  4. [Add Tags] (タグの追加) ページで、[Key] (キー) を Name に、[Value] (値) を VPC 名に設定してタグを作成します。このタグを使用すると、 スタックスタックの作成時に VPC AWS OpsWorks を識別しやすくなります。

  5. [Continue (続行)] を選択し、[Close (閉じる)] を選択して、スタックを起動します。

注意: 次のいずれかの方法で、その他のリージョンに VPC を作成できます。

  • 「異なるリージョンでテンプレートを使用する」に移動し、適切なリージョンを選択し、 AWS OpsWorks スタック VPC テンプレートを見つけて、 スタックを起動するを選択します。

  • テンプレートファイルをシステムにコピーし、AWS CloudFormation コンソールで適切なリージョンを選択し、[スタックの作成] ウィザードの [テンプレートを Amazon S3 へのアップロード] オプションを使用して、システムからテンプレートをアップロードします。

サンプルテンプレートには、 スタックスタックの作成に必要な VPC、サブネット、ロードバランサー IDs AWS OpsWorks を提供する出力が含まれています。コンソール AWS CloudFormation ウィンドウの下部にある出力タブを選択すると、それらを表示できます。

Stack outputs table showing VPC, subnet, and load balancer IDs for an OpsWorks-in-VPC stack.