プライベート VM のインターネット接続の構築

Last reviewed 2024-05-10 UTC

このドキュメントでは、プライベート IP アドレスを持つ Compute Engine リソースを使用してインターネットに接続するための選択肢について説明します。このドキュメントは、Google Cloud サービスを作成するデベロッパーと、Google Cloud 環境のネットワーク管理者にとって有用です。

このチュートリアルは、VPC のデプロイ、Compute Engine、基本的な TCP/IP ネットワークについて十分に理解していることを前提としています。

目標

VPC の外部にあるプライベート VM 間の接続に使用できる選択肢を理解する。
SSH などの対話型サービスに適した TCP トンネル用に Identity-Aware Proxy（IAP）のインスタンスを作成する。
Cloud NAT インスタンスを作成して、VM からインターネットへの送信接続を可能にする。
インターネットから VM への受信接続をサポートするように HTTP ロードバランサを構成する。

費用

このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。このチュートリアルの合計費用は 1 日 US$5 未満と計算しています。

準備

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

はじめに

パブリック（外部）IP アドレスに比べて、プライベート IP アドレスには次のような利点があります。

攻撃対象領域が縮小。VM から外部 IP アドレスを削除すると、攻撃者が VM に到達して潜在的な脆弱性を悪用することが困難になります。
柔軟性が向上。ロードバランサや NAT サービスなどの抽象化レイヤを導入すると、静的な外部 IP アドレスと比べて、信頼性の高い柔軟なサービス配信が可能になります。

このソリューションでは、次の表にある 3 つのシナリオについて説明します。

インタラクティブ	取得	処理中
リモートホストが TCP の IAP を使用して VM への SSH 接続を開始します。例: SSH または RDP を使用したリモート管理	VM が Cloud NAT を使用して、インターネット上の外部ホストへの接続を開始します。例: OS のアップデート、外部 API	リモートホストが Google Cloud のグローバルロードバランサを介して VM への接続を開始します。例: アプリケーションのフロントエンド、WordPress

上のシナリオの 1 つのみに該当する環境もありますが、多くの環境ではこれらのシナリオがすべて必要であり、Google Cloud では完全にサポートされています。

以下のセクションでは、2 つのリージョンの 2 つの VM による HTTP 負荷分散サービスを備えたマルチリージョン環境について説明します。これらの VM は、送信通信に Cloud NAT を使用します。管理を行う場合は、IAP でトンネル化された SSH 経由で VM にアクセスできます。

次の図に、上の 3 つのユースケースとそれらに関連するコンポーネントの概要を示します。

ロードバランサを介したクライアントから VM インスタンスへのフロー、インスタンスからインターネットへアクセスするための Cloud NAT、クライアントからインスタンスへの直接 SSH アクセスを可能にする IAP を表すソリューションのアーキテクチャ。

VM インスタンスの作成

まず、合計で 4 つの仮想マシン（VM）インスタンスを作成します（リージョンごとに 2 つのインスタンスを作成します）。すべてのインスタンスに同じタグを付けます。このタグは、受信トラフィックがインスタンスに到達できるようにファイアウォールルールで使用されます。

下図に示すとおり、作成した VM インスタンスとインスタンスグループが 2 つのゾーンに分散しています。

2 つのゾーンにある 4 つの VM インスタンスをハイライト表示したソリューションのアーキテクチャ。

各インスタンスに追加した起動スクリプトによって Apache がインストールされ、各インスタンスに一意のホームページが作成されます。

ここでは、Google Cloud コンソールと gcloud コマンドの両方を使用する場合の手順をそれぞれ説明します。gcloud コマンドを使用する最も簡単な方法は、Cloud Shell を使用することです。

コンソール

Google Cloud コンソールで [VM インスタンス] ページに移動します。

[VM インスタンス] ページに移動
[インスタンスを作成] をクリックします。
[名前] を www-1 に設定します。
[ゾーン] を us-central1-b に設定します。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
[ネットワーキング] をクリックして、次の設定を行います。
- HTTP トラフィックの場合は、[ネットワークタグ] ボックスに「http-tag」と入力します。
- [ネットワークインターフェース] で [] をクリックします。
- [外部 IP] で [なし] を選択します。
注: HTTP または HTTPS トラフィックを許可するファイアウォールボックスを選択しないでください。選択すると、不要なファイアウォールルールが作成されます。

[管理] をクリックし、[起動スクリプト] を次のように設定します。

sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo service apache2 restart
echo '<!doctype html><html><body><h1>server 1</h1></body></html>' | sudo tee /var/www/html/index.html

[作成] をクリックします。

同じ設定で www-2 を作成します。ただし、[起動スクリプト] は次のように設定します。

sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo service apache2 restart
echo '<!doctype html><html><body><h1>server 2<h1></body></html>' | sudo tee /var/www/html/index.html

同じ設定で www-3 を作成します。ただし、[ゾーン] は europe-west1-b に設定し、[起動スクリプト] を次のように設定します。

sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo service apache2 restart
echo '<!doctype html><html><body><h1>server 3</h1></body></html>' | sudo tee /var/www/html/index.html

同じ設定で www-4 を作成します。ただし、[ゾーン] は europe-west1-b に設定し、[起動スクリプト] を次のように設定します。

sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo service apache2 restart
echo '<!doctype html><html><body><h1>server 4</h1></body></html>' | sudo tee /var/www/html/index.html

gcloud

Cloud Shell を開きます。

Cloud Shell を開く

基本的な起動スクリプトを使用して、us-central1-b に www-1 という名前のインスタンスを作成します。

gcloud compute instances create www-1 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --zone us-central1-b \
    --tags http-tag \
    --network-interface=no-address \
    --metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www-1</h1></body></html>' | tee /var/www/html/index.html
EOF"

us-central1-b に www-2 という名前のインスタンスを作成します。

gcloud compute instances create www-2 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --zone us-central1-b \
    --tags http-tag \
    --network-interface=no-address \
    --metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www-2</h1></body></html>' | tee /var/www/html/index.html
EOF"

今回は europe-west1-b に www-3 という名前のインスタンスを作成します。

gcloud compute instances create www-3 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --zone europe-west1-b \
    --tags http-tag \
    --network-interface=no-address \
    --metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www-3</h1></body></html>' | tee /var/www/html/index.html
EOF"

再度 europe-west1-b に www-4 という名前のインスタンスを作成します。

gcloud compute instances create www-4 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --zone europe-west1-b \
    --tags http-tag \
    --network-interface=no-address \
    --metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www-4</h1></body></html>' | tee /var/www/html/index.html
EOF"

Terraform

Cloud Shell を開きます。

Cloud Shell を開く
GitHub からリポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/gce-public-connectivity-terraform
作業ディレクトリをリポジトリディレクトリに変更します。

cd iap
Terraform をインストールします。
scripts/set_env_vars.sh ファイルの [YOUR-ORGANIZATION-NAME] は、Google Cloud の組織名に置き換えます。
環境変数を設定します。

source scripts/set_env_vars.sh
Terraform 構成を適用します。

terraform apply
注: エラーが発生した場合は、しばらく待ってから terraform apply コマンドをもう一度実行してください。

インスタンスを処理する IAP トンネルの構成

VM インスタンスにログインするには、SSH や RDP などのツールを使用してインスタンスに接続します。このチュートリアルで作成する構成では、インスタンスに直接接続することはできません。ただし、IAP で TCP 転送を使用すると、こうした対話形式でリモートアクセスが可能になります。

このチュートリアルでは SSH を使用します。

このセクションでは、次の操作を行います。

IAP トンネルを使用して Compute Engine インスタンスに接続する。
IAM で IAP トンネリング権限を持つ 2 番目のユーザーを追加する。

次の図は、このセクションで構築するアーキテクチャを示しています。灰色の領域は、このチュートリアルの他のパートで説明します。

IAP によってクライアントとインスタンス間で SSH アクセスするためのアクセス権が与えられることを示すソリューションのアーキテクチャ。

IAP の制限事項

帯域幅: IAP の TCP 転送機能は、データの一括転送を想定したものではありません。IAP は、このサービスを悪用していると考えられるユーザーに対してレート制限を設定できる権限を有しています。
接続の長さ: IAP は、メンテナンスに必要な場合を除き、アクティブなセッションを切断することはありません。
プロトコル: TCP 用 IAP は、UDP をサポートしていません。

トンネリングを許可するファイアウォールルールを作成する

SSH を使用してインスタンスに接続するには、ファイアウォールの適切なポートを開く必要があります。IAP 接続では、特定の IP アドレスのセット（35.235.240.0/20）が使用されます。したがって、ルールをこの CIDR 範囲に制限できます。

コンソール

Google Cloud コンソールで [ファイアウォールポリシー] ページに移動します。

[ファイアウォールポリシー] ページに移動
[ファイアウォールルールを作成] をクリックします。
[名前] を allow-ssh-from-iap に設定します。
[VPC ネットワーク] は [default] のままにします。
[ターゲット] で [指定されたターゲットタグ] を選択します。
[ターゲットタグ] を http-tag に設定します。
[ソースフィルタ] は [IP 範囲] のままにしておきます。
[ソース IP の範囲] を 35.235.240.0/20 に設定します。
[許可対象プロトコル / ポート] を tcp:22 に設定します。
[作成] をクリックします。

新しいファイアウォールルールがコンソールに表示されるまで少し時間がかかる場合があります。

gcloud

allow-ssh-from-iap という名前のファイアウォールルールを作成します。

gcloud compute firewall-rules create allow-ssh-from-iap \
    --source-ranges 35.235.240.0/20 \
    --target-tags http-tag \
    --allow tcp:22

Terraform

ファイアウォールルールの Terraform ファイルを現在のディレクトリにコピーします。

cp iap/vpc_firewall_rules.tf .
Terraform 構成を適用します。

terraform apply
注: エラーが発生した場合は、しばらく待ってから terraform apply コマンドをもう一度実行してください。

トンネリングをテストする

Cloud Shell で、IAP を使用してインスタンス www-1 に接続します。
```
gcloud compute ssh www-1 \
    --zone us-central1-b \
    --tunnel-through-iap
```

接続に成功すると、IAP を介してプライベート VM に直接トンネリングされる SSH セッションができます。

追加のユーザーにアクセスを許可する

IAP は、VM インスタンスに接続するときに既存のプロジェクトのロールと権限を使用します。デフォルトでは、インスタンスのオーナーが IAP で保護されたトンネルユーザーのロールを持つ唯一のユーザーになります。他のユーザーが IAP トンネリングを使用して VM にアクセスできるようにするには、これらのユーザーにこのロールを付与する必要があります。

Google Cloud コンソールで、[セキュリティ] > [Identity-Aware Proxy] に移動します。

OAuth 同意画面を構成する必要があることを示すメッセージが表示された場合は、メッセージを無視してください。TCP 用 IAP とは関係ありません。
[SSH と TCP のリソース] タブを選択します。
作成した VM を選択します。
右側にある [プリンシパルを追加] をクリックします。
権限を付与するユーザーを追加し、IAP で保護されたトンネルユーザーロールを選択して、[保存] をクリックします。

まとめ

これで、SSH を使用してインスタンスに接続し、インスタンスを管理またはトラブルシューティングできるようになりました。

多くのアプリケーションは、パッチのダウンロード、パートナーとの接続、リソースのダウンロードで送信接続を行う必要があります。次のセクションでは、VM がこれらのリソースに到達できるように Cloud NAT を構成します。

取得用の Cloud NAT のデプロイ

Cloud NAT サービスを使用すると、外部 IP アドレスを持たない Google Cloud VM インスタンスをインターネットに接続できます。Cloud NAT は、インスタンスがインターネットに到達できるように、デフォルトルートとアウトバウンド NAT を実装します。インバウンド NAT は実装しません。VPC ネットワークの外部にあるホストは、インスタンスによって開始された接続にのみ応答できます。Cloud NAT を使用して、インスタンスと独自の接続を開始することはできません。NAT は、Google Cloud 内のトラフィックには使用されません。

Cloud NAT はリージョンリソースです。リージョン内のサブネットのすべてのプライマリ IP アドレス範囲とセカンダリ IP アドレス範囲から送信されるトラフィックを許可するような構成も、いくつかの範囲にのみ許可を適用するような構成も可能です。

このセクションでは、以前に使用した各リージョンで Cloud NAT ゲートウェイを構成します。次の図は、このセクションで構築するアーキテクチャを示しています。灰色の領域は、このチュートリアルの他のパートで説明します。

インスタンスとインターネット間に Cloud NAT インスタンスがあることを示すソリューションのアーキテクチャ。

Cloud Router を使用して NAT 構成を作成する

Cloud NAT を使用するインスタンスと同じリージョンに Cloud Router インスタンスを作成する必要があります。Cloud NAT は、NAT 情報を VM に配置するためにのみ使用されます。実際の Cloud NAT ゲートウェイの一部としては使用されません。

この構成により、リージョン内のすべてのインスタンスが、すべてのプライマリとエイリアス IP の範囲に Cloud NAT を使用できるようになります。また、NAT ゲートウェイに外部 IP アドレスが自動的に割り振られます。その他の選択肢については、gcloud compute routers のドキュメントをご覧ください。

コンソール

[Cloud NAT] ページに移動します。

[Cloud NAT] ページに移動
[開始] または [NAT ゲートウェイを作成] をクリックします。
[ゲートウェイの名前] を nat-config に設定します。
[VPC ネットワーク] を default に設定します。
[リージョン] を us-central1 に設定します。
[Cloud Router] で [新しいルーターを作成します] を選択して、次の操作を行います。
- [名前] を nat-router-us-central1 に設定します。
- [作成] をクリックします。
[作成] をクリックします。
手順を繰り返します。ただし、次の値を使用します。
- 名前: nat-router-europe-west1
- リージョン: europe-west1

gcloud

各リージョンで Cloud Router インスタンスを作成します。

gcloud compute routers create nat-router-us-central1 \
    --network default \
    --region us-central1

gcloud compute routers create nat-router-europe-west1 \
    --network default \
    --region europe-west1

Cloud NAT のルーターを構成します。

gcloud compute routers nats create nat-config \
    --router-region us-central1 \
    --router nat-router-us-central1 \
    --nat-all-subnet-ip-ranges \
     --auto-allocate-nat-external-ips

gcloud compute routers nats create nat-config \
    --router-region europe-west1 \
    --router nat-router-europe-west1 \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

Terraform

Terraform NAT 構成ファイルを現在のディレクトリにコピーします。

cp nat/vpc_nat_gateways.tf .
Terraform 構成を適用します。

terraform apply
注: エラーが発生した場合は、しばらく待ってから terraform apply コマンドをもう一度実行してください。

Cloud NAT の構成をテストする

VM インスタンスからインターネットへの送信リクエストを作成できることをテストします。

NAT 構成が VM に伝達されるまで待ちます。最大で 3 分ほどかかります。
Cloud Shell で、作成したトンネルを使用してインスタンスに接続します。
```
gcloud compute ssh www-1 --tunnel-through-iap
```

インスタンスにログインしたら、curl コマンドを使用して送信リクエストを作成します。

curl example.com

次の出力が表示されます。

<html>
<head>
<title>Example Domain</title>
...
...
...
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is established to be used for illustrative examples in documents.
        You may use this domain in examples without prior coordination or asking for
        permission.
    </p>
    <p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

コマンドが成功した場合、Cloud NAT を使用して VM がインターネットに接続できます。

まとめ

インスタンスで、パッチのダウンロード、パートナーとの接続、リソースのダウンロードを行うときに送信接続が可能になりました。

次のセクションでは、デプロイに負荷分散を追加し、リモートクライアントからサーバーにリクエストを送信できるように構成します。

サービス用の HTTP ロードバランシングサービスの作成

アプリケーションで Cloud Load Balancing を使用すると、多くの利点があります。100 万件を超える秒間クエリ数に対して、シームレスかつスケーラブルにロードバランシングできます。また、VM から SSL オーバーヘッドをオフロードし、可用性とロケーションに基づいてクエリを最適なリージョンにルーティングできます。また、HTTP/2 や QUIC などの最新のプロトコルを利用できます。

このチュートリアルでは、別の重要な機能であるグローバルエニーキャスト IP 接続プロキシを利用します。この機能は、世界中に分散された Google のエッジで終端される単一のパブリック IP アドレスを提供します。これにより、クライアントは、Google Cloud のあらゆる場所にあるプライベート IP アドレスでホストされたリソースに接続できます。この構成は、DDoS 攻撃と直接攻撃からインスタンスを保護するうえで有用です。また、Google Cloud Armor などの機能を使用して、さらにセキュリティを強化することも可能です。

このセクションでは、次の操作を行います。

VM インスタンスをリセットして、Apache ウェブサーバーをインストールします。
ロードバランサからのアクセスを許可するファイアウォールルールを作成する。
ロードバランサに静的なグローバル IPv4 および IPv6 アドレスを割り当てる。
インスタンスにインスタンスグループを作成する。
インスタンスへのトラフィックの送信を開始する。

次の図は、このセクションで構築するアーキテクチャを示しています。灰色の領域は、このチュートリアルの他のパートで説明します。

2 つのインスタンスグループにある 4 つのインスタンスをハイライト表示したアーキテクチャ。

VM インスタンスをリセットする

このチュートリアルで、前に VM インスタンスを作成したときは、外部 IP アドレスが割り振られておらず、Cloud NAT が構成されていなかったため、インターネットにアクセスできませんでした。このため、Apache をインストールする起動スクリプトは正常に完了できませんでした。

起動スクリプトを再実行する最も簡単な方法は、Apache ウェブサーバーをインストールし、次のセクションで使用できるよう、これらのインスタンスをリセットすることです。

コンソール

Google Cloud コンソールで [VM インスタンス] ページに移動します。

[VM インスタンス] に移動
www-1、www-2、www-3、www-4 を選択します。
ページ上部にある [リセット] ボタンをクリックします。

[リセット] ボタンが表示されていない場合は、[その他の操作]（）をクリックして [リセット] を選択します。
ダイアログで [リセット] をクリックして、4 つのインスタンスがリセットされたことを確認します。

gcloud

4 つのインスタンスをリセットします。

gcloud compute instances reset www-1 \
    --zone us-central1-b

gcloud compute instances reset www-2 \
    --zone us-central1-b

gcloud compute instances reset www-3 \
    --zone europe-west1-b

gcloud compute instances reset www-4 \
    --zone europe-west1-b

ファイアウォールを開く

次に、ロードバランサから VM インスタンスへのトラフィックを許可するファイアウォールルールを作成します。このルールにより、ロードバランサとヘルスチェックの両方で使用される Google Cloud アドレス範囲からのトラフィックが許可されます。このファイアウォールルールでは、前に作成した http-tag タグを使用します。ファイアウォールルールによって、指定ポートへのトラフィックは、タグが設定されたインスタンスに到達することが許可されます。

コンソール

Google Cloud コンソールで [ファイアウォールポリシー] ページに移動します。

[ファイアウォールポリシー] ページに移動
[ファイアウォールルールを作成] をクリックします。
[名前] を allow-lb-and-healthcheck に設定します。
[VPC ネットワーク] は default のままにします。
[ターゲット] で [指定されたターゲットタグ] を選択します。
[ターゲットタグ] を http-tag に設定します。
[ソースフィルタ] は [IP 範囲] のままにしておきます。
[ソース IP の範囲] を 130.211.0.0/22 と 35.191.0.0/16 に設定します。
[許可対象プロトコル / ポート] を tcp:80 に設定します。
[作成] をクリックします。

新しいファイアウォールルールがコンソールに表示されるまで少し時間がかかる場合があります。

gcloud

allow-lb-and-healthcheck という名前のファイアウォールルールを作成します。

gcloud compute firewall-rules create allow-lb-and-healthcheck \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --target-tags http-tag \
     --allow tcp:80

Terraform

Terraform 負荷分散構成ファイルを現在のディレクトリにコピーします。

cp lb/* .
Terraform 構成を適用します。

terraform apply
注: エラーが発生した場合は、しばらく待ってから terraform apply コマンドをもう一度実行してください。

ロードバランサに外部 IP アドレスを割り振る

インターネットに送信するトラフィックを処理する場合は、ロードバランサに外部アドレスを割り当てる必要があります。IPv4 アドレス、IPv6 アドレス、またはその両方を割り当てることができます。このセクションでは、DNS の追加に適した静的 IPv4 アドレスと IPv6 アドレスを予約します。

パブリック IP アドレスはロードバランサで使用されるため、追加料金はかかりません。

コンソール

Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。

[外部 IP アドレス] ページに移動
[静的アドレスを予約] をクリックして、IPv4 アドレスを予約します。
[名前] を lb-ip-cr に設定します。
[タイプ] は [グローバル] のままにします。
[予約] をクリックします。
もう一度、[静的アドレスを予約] をクリックして、IPv6 アドレスを予約します。
[名前] を lb-ipv6-cr に設定します。
[IP バージョン] を IPv6 に設定します。
[タイプ] は [グローバル] のままにします。
[予約] をクリックします。

gcloud

IPv4 用に lb-ip-cr という名前の静的 IP アドレスを作成します。

gcloud compute addresses create lb-ip-cr \
    --ip-version=IPV4 \
    --global

IPv6 用に lb-ipv6-cr という名前の静的 IP アドレスを作成します。

gcloud compute addresses create lb-ipv6-cr \
    --ip-version=IPV6 \
    --global

インスタンスグループを作成してインスタンスを追加する

Google Cloud ロードバランサでは、トラフィックのバックエンドとして機能するインスタンスグループが必要です。説明を簡単にするため、このチュートリアルでは非マネージドインスタンスグループを使用します。ただし、マネージドインスタンスグループを使用して、自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイ、自動更新などの機能を利用することもできます。

このセクションでは、使用しているゾーンごとにインスタンスグループを作成します。

コンソール

Google Cloud コンソールで、[インスタンスグループ] ページに移動します。

[インスタンスグループ] ページに移動
[インスタンスグループを作成] をクリックします。
左側にある [新しい非マネージドインスタンスグループ] をクリックします。
[名前] を us-resources-w に設定します。
[リージョン] を us-central1 に設定します。
[ゾーン] を us-central1-b に設定します。
[ネットワーク]（デフォルト）と [サブネットワーク]（デフォルト）を選択します。
[VM インスタンス] で、次の操作を行います。
- [インスタンスを追加] をクリックして、www-1 を選択します。
- [インスタンスを追加] をもう一度クリックして、www-2 を選択します。
- [作成] をクリックします。
この手順を繰り返して 2 番目のインスタンスグループを作成します。ただし、次の値を使用します。
- 名前: europe-resources-w
- ゾーン: europe-west1-b
- インスタンス: www-3 と www-4
[インスタンスグループ] ページで、2 つのインスタンスグループがあり、それぞれに 2 つのインスタンスがあることを確認します。

gcloud

us-resources-w インスタンスグループを作成します。

gcloud compute instance-groups unmanaged create us-resources-w \
    --zone us-central1-b

www-1 インスタンスと www-2 インスタンスを追加します。

gcloud compute instance-groups unmanaged add-instances us-resources-w \
    --instances www-1,www-2 \
    --zone us-central1-b

europe-resources-w インスタンスグループを作成します。

gcloud compute instance-groups unmanaged create europe-resources-w \
    --zone europe-west1-b

www-3 インスタンスと www-4 インスタンスを追加します。

gcloud compute instance-groups unmanaged add-instances europe-resources-w \
    --instances www-3,www-4 \
    --zone europe-west1-b

負荷分散サービスを構成する

ロードバランサ機能には、連携する複数のサービスが含まれます。このセクションでは、サービスを設定して接続します。次のサービスを作成します。

名前付きポート。ロードバランサはこれを使用して、トラフィックをインスタンスグループに転送します。
ヘルスチェック。インスタンスが正常に機能しているかを確認します。ロードバランサは、正常なインスタンスにのみトラフィックを送信します。
バックエンドサービス。インスタンスの使用状況と正常性をモニタリングします。バックエンドサービスは、インスタンスグループ内のインスタンスがトラフィックを受信できるかどうかを確認します。インスタンスに十分な容量があるときに、インスタンスがトラフィックを受信できない場合、ロードバランサはトラフィックをリダイレクトします。バックエンドは、インスタンスグループの容量（最大 CPU 使用率または最大秒間クエリ数）を定義します。
URL マップ。リクエストの URL を解析し、リクエスト URL のホストとパスに基づいてリクエストを特定のバックエンドサービスに転送します。このチュートリアルでは、コンテンツベースの転送を使用していないため、URL マップにはデフォルトのマッピングのみが含まれています。
ターゲットプロキシ。ユーザーからのリクエストを受け取り、それを URL マップに転送します。
2 つのグローバル転送ルール（IPv4 と IPv6 にそれぞれ 1 つずつ）。グローバルな外部 IP アドレスリソースを保持します。グローバル転送ルールは、受信リクエストをターゲットプロキシに転送します。

ロードバランサを作成する

このセクションでは、ロードバランサを作成し、トラフィックを処理するデフォルトのバックエンドサービスを構成します。ヘルスチェックも作成します。

コンソール

構成を開始する

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[ロードバランサを作成] をクリックします。
[ロードバランサの種類] で [アプリケーションロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
[インターネット接続または内部] で [インターネット接続（外部）] を選択し、[次へ] をクリックします。
[グローバルまたはシングルリージョンのデプロイ] で [グローバルワークロードに最適] を選択し、[次へ] をクリックします。
[ロードバランサの世代] で [グローバル外部アプリケーションロードバランサ] を選択し、[次へ] をクリックします。
[構成] をクリックします。

基本構成

[ロードバランサの名前] を web-map に設定します。

ロードバランサを構成する

[Create global external Application Load Balancer] ページの左パネルで、[バックエンドの構成] をクリックします。
[バックエンドサービスとバックエンドバケットの作成または選択] リストで、[バックエンドサービス]、[バックエンドサービスを作成] の順に選択します。[バックエンドサービスの作成] ダイアログボックスが表示されます。
[名前] を web-map-backend-service に設定します。
[プロトコル] を設定します。HTTP プロトコルの場合は、デフォルト値のままにします。
[バックエンドタイプ] で、[インスタンスグループ] を選択します。
[バックエンド] で、[インスタンスグループ] を us-resources-w に設定します。
[バックエンドを追加] をクリックします。
europe-resources-w インスタンスグループを選択して、次の操作を行います。
- ロードバランサとインスタンス間の HTTP トラフィックの場合、[ポート番号] が 80 に設定されていることを確認します。
- 残りのフィールドはデフォルト値のままにします。
[完了] をクリックします。
[ヘルスチェック] で、[ヘルスチェックを作成] または [別のヘルスチェックを作成] を選択します。
次のヘルスチェックパラメータを設定します。
- 名前: http-basic-check
- プロトコル: HTTP
- ポート: 80
[作成] をクリックします。

gcloud

インスタンスグループごとに HTTP サービスを定義し、ポート名を該当するポートにマッピングします。

gcloud compute instance-groups unmanaged set-named-ports us-resources-w \
    --named-ports http:80 \
    --zone us-central1-b

gcloud compute instance-groups unmanaged set-named-ports europe-resources-w \
    --named-ports http:80 \
    --zone europe-west1-b

ヘルスチェックを作成します。

gcloud compute health-checks create http http-basic-check \
    --port 80

バックエンドサービスを作成します。
```
gcloud compute backend-services create web-map-backend-service \
    --protocol HTTP \
    --health-checks http-basic-check \
    --global
```
HTTP を使用してインスタンスに移動するため、--protocol フラグを HTTP に設定します。ヘルスチェックには、先ほど作成した http-basic-check ヘルスチェックを使用します。

インスタンスグループをバックエンドとしてバックエンドサービスに追加します。

gcloud compute backend-services add-backend web-map-backend-service \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8 \
    --capacity-scaler 1 \
    --instance-group us-resources-w \
    --instance-group-zone us-central1-b \
    --global

gcloud compute backend-services add-backend web-map-backend-service \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8 \
    --capacity-scaler 1 \
    --instance-group europe-resources-w \
    --instance-group-zone europe-west1-b \
    --global

ホストルールとパスルールを設定する

コンソール

[Create global external Application Load Balancer] ページの左パネルで、[ホストとパスのルール] をクリックします。

このチュートリアルでは、すべてのトラフィックがデフォルトルールに従うため、ホストルールまたはパスルールを設定する必要はありません。したがって、事前設定されたデフォルト値をそのまま使用します。

gcloud

あらゆるインスタンスへの受信リクエストをすべて振り向けるデフォルトの URL マップを作成します。
```
gcloud compute url-maps create web-map \
    --default-service web-map-backend-service
```
URL マップにリクエストをルーティングするターゲット HTTP プロキシを作成します。
```
gcloud compute target-http-proxies create http-lb-proxy \
    --url-map web-map
```

フロントエンドを設定してセットアップを完了する

コンソール

[Create global external Application Load Balancer] ページの左パネルで、[フロントエンドの構成] をクリックします。
[名前] を http-cr-rule に設定します。
[プロトコル] を HTTP に設定します。
[IP バージョン] を IPv4 に設定します。
[IP アドレス] リストで、先ほど作成したアドレスの [lb-ip-cr] を選択します。
[ポート] が 80 に設定されていることを確認します。
[完了] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
[名前] を http-cr-ipv6-rule に設定します。
[プロトコル] で [HTTP] を選択します。
[IP バージョン] を IPv6 に設定します。
[IP アドレス] リストで、先ほど作成したもう 1 つのアドレスの [lb-ipv6-cr] を選択します。
[ポート] が 80 に設定されていることを確認します。
[作成] をクリックします。
[完了] をクリックします。
[Create global external Application Load Balancer] ページの左パネルで、[確認と完了] をクリックします。
現在の設定と作成しようとしている内容を比較します。
設定が正しい場合は、[作成] をクリックします。

負荷分散ページに戻ります。ロードバランサの作成後、その横にある緑色のチェックマークは、ロードバランサが稼働中であることを示します。

gcloud

ロードバランサ用に作成した静的 IP アドレスを取得します。次の手順で使用するため、これらの値をメモしておきます。
```
gcloud compute addresses list
```
受信リクエストをプロキシにルーティングする 2 つのグローバル転送ルール（1 つは IPv4 用、もう 1 つは IPv6 用）を作成します。コマンド内の lb_ip_address は、作成した静的 IPv4 アドレスで置き換えます。lb_ipv6_address は、作成した IPv6 アドレスで置き換えます。
```
gcloud compute forwarding-rules create http-cr-rule \
    --address lb_ip_address \
    --global \
    --target-http-proxy http-lb-proxy \
    --ports 80

gcloud compute forwarding-rules create http-cr-ipv6-rule \
    --address lb_ipv6_address \
    --global \
    --target-http-proxy http-lb-proxy \
   --ports 80
```
グローバル転送ルールを作成した後、構成が伝播されるまでに数分かかることがあります。

構成のテスト

このセクションでは、HTTP リクエストをインスタンスに送信して、負荷分散構成が機能していることを確認します。

コンソール

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] ページに移動
web-map という名前のロードバランサを選択して、先ほど作成したロードバランサの詳細を表示します。
[バックエンド] セクションで、[正常] 列を表示して、インスタンスが正常であることを確認します。

インスタンスが正常であると示されるまでに少し時間がかかる場合があります。
インスタンスが正常と表示されたら、[フロントエンド] セクションから [IP: ポート] の値をコピーし、ブラウザに貼り付けます。

ブラウザにデフォルトのコンテンツページが表示されます。

gcloud

グローバル転送ルールの IP アドレスを取得し、メモしておきます。これは次のステップで使用します。
```
gcloud compute forwarding-rules list
```
curl コマンドを使用して、サービスのさまざまな URL に対するレスポンスをテストします。IPv4 と IPv6 の両方を試してください。IPv6 の場合は、http://[2001:DB8::]/ のようにアドレスを [] で囲む必要があります。
```
curl http://ipv4-address

curl -g -6 "http://[ipv6-address]/"
```

まとめ

VM がインターネットへのトラフィックを処理し、インターネットからデータを取得できるようになりました。管理タスクを実行するために、SSH 経由でアクセスすることもできます。この機能はすべてプライベート IP アドレスのみを使用して実現されます。これは、インターネットから到達可能な IP アドレスを公開しないことで、直接攻撃から保護するのに役立ちます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

Cloud Load Balancing の作成で、HTTPS および HTTP2 ロードバランサを作成する方法を確認する。
限定公開クラスタの設定で、限定公開の Google Kubernetes Engine クラスタの設定方法を確認する。
TCP 転送に IAP を使用するで、RDP やリモートコマンド実行など、TCP 用 IAP のその他の用途を確認する。
Cloud NAT の使用で、Google Kubernetes Engine の例とパラメータの変更方法を確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

プライベート VM のインターネット接続の構築

目標

費用

準備

はじめに

VM インスタンスの作成

コンソール

gcloud

Terraform

インスタンスを処理する IAP トンネルの構成

IAP の制限事項

トンネリングを許可するファイアウォール ルールを作成する

コンソール

gcloud

Terraform

トンネリングをテストする

追加のユーザーにアクセスを許可する

まとめ

取得用の Cloud NAT のデプロイ

Cloud Router を使用して NAT 構成を作成する

コンソール

gcloud

Terraform

Cloud NAT の構成をテストする

まとめ

サービス用の HTTP ロード バランシング サービスの作成

VM インスタンスをリセットする

コンソール

gcloud

ファイアウォールを開く

コンソール

gcloud

Terraform

ロードバランサに外部 IP アドレスを割り振る

コンソール

gcloud

インスタンス グループを作成してインスタンスを追加する

コンソール

gcloud

負荷分散サービスを構成する

ロードバランサを作成する

コンソール

構成を開始する

基本構成

ロードバランサを構成する

gcloud

ホストルールとパスルールを設定する

コンソール

gcloud

フロントエンドを設定してセットアップを完了する

コンソール

gcloud

構成のテスト

コンソール

gcloud

まとめ

クリーンアップ

プロジェクトの削除

次のステップ

トンネリングを許可するファイアウォールルールを作成する

サービス用の HTTP ロードバランシングサービスの作成

インスタンスグループを作成してインスタンスを追加する