このページは Cloud Translation API によって翻訳されました。

Google API 用の Private Service Connect

1. はじめに

Private Service Connect を使用すると、VPC ネットワーク内のグローバル内部 IP アドレスを使用してプライベートエンドポイントを作成し、Google API にアクセスできます。これらの内部 IP アドレスには、storage-pscendpoint.p.googleapis.com や bigtable-adsteam.p.googleapis.com などの意味のある名前で DNS 名を割り当てることができます。storage.googleapis.com などのパブリックサービスエンドポイントに API リクエストを送信する代わりに、VPC ネットワーク内部の限定公開である Private Service Connect エンドポイントにリクエストを送信できます。

これらの名前と IP アドレスは、VPC ネットワークと、Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）を使用して接続されているオンプレミスネットワークに対して内部的なものです。

エンドポイントに配信されるトラフィックを制御し、トラフィックを Google Cloud 内にとどめることができます。

学習内容

Private Service Connect のユースケース
ネットワークの要件
サポートされている API
Private Service Connect エンドポイントを作成する
Cloud Storage バケットを作成する
Cloud DNS 限定公開ゾーンの作成と更新
NAT GW を作成してパブリック Apigee にアクセスする
BOTO 構成ファイルの作成と更新
PSC サービスエンドポイントに対して解決された VM1 で gsutil list を実行する
VM2 で、公開 googleapis.com に対して解決された gsutil list を実行
tcpdump を使用して DNS の解決を検証する

必要なもの

DNS、nano または vi エディタに関する知識

2. Private Service Connect のユースケース

同じ VPC ネットワーク内に複数の Private Service Connect エンドポイントを作成できます。特定のエンドポイントへの帯域幅に制限はありません。Private Service Connect エンドポイントはグローバル内部 IP アドレスを使用するため、VPC ネットワーク内の任意のリソースで使用できます。

複数のエンドポイントがある場合は、Cloud Router とファイアウォールルールを使用して異なるネットワークパスを指定できます。

ファイアウォールルールを作成して、一部の VM には Private Service Connect エンドポイントを介した Google API へのアクセスを禁止し、他の VM にはアクセスを許可できます。
VM インスタンスに、インターネットへのすべてのトラフィックを禁止するファイアウォールルールを設定できます。Private Service Connect エンドポイントに送信されたトラフィックは、引き続き Google に到達します。
Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）を使用して VPC に接続しているオンプレミスホストがある場合、一部のリクエストをトンネルまたは VLAN 経由で送信し、他のリクエストを公共のインターネット経由で送信できます。この構成を使用すると、限定公開の Google アクセスでサポートされていない Google ブックスなどのサービスに対して、トンネルや VLAN をバイパスできます。この構成を作成するには、Private Service Connect エンドポイントを作成し、Cloud Router のカスタムルートアドバタイズを使用して Private Service Connect エンドポイントの IP アドレスをアドバタイズして、Cloud DNS インバウンド転送ポリシーを有効にします。アプリケーションは、Private Service Connect エンドポイントの名前を使用して Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）経由でリクエストを送信し、その他のリクエストはデフォルトの DNS 名を使用してインターネット経由で送信できます。
複数の Cloud Interconnect アタッチメント（VLAN）を使用してオンプレミスネットワークを VPC ネットワークに接続する場合、図 2 に示すように、オンプレミスからの一部のトラフィックを VLAN 経由で送信し、残りのトラフィックを VLAN 経由で送信できます。これにより、Google ではなく独自の広域ネットワーキングを使用し、地理的要件に合わせてデータの移動を制御できます。この構成を作成するには、2 つの Private Service Connect エンドポイントを作成します。1 つ目の VLAN を管理する Cloud Router の BGP セッションで、1 つ目のエンドポイントにカスタムルートアドバタイズを作成し、2 つ目の VLAN を管理する Cloud Router の BGP セッションで、2 つ目のエンドポイントに別のカスタムルートアドバタイズを作成する。Private Service Connect エンドポイント名を使用するように構成されているオンプレミスホストは、対応する Cloud Interconnect アタッチメント（VLAN）経由でトラフィックを送信します。
アクティブ/アクティブトポロジで複数の Cloud Interconnect アタッチメント（VLAN）を使用することもできます。VLAN を管理する Cloud Router の BGP セッションで、カスタムルートアドバタイズを使用して同じ Private Service Connect エンドポイント IP アドレスをアドバタイズすると、オンプレミスシステムからエンドポイントに送信されるパケットは、ECMP を使用して VLAN 間でルーティングされます。

図 1. Private Service Connect、Cloud Router、オンプレミスホストを構成することで、Google API へのトラフィックの送信に使用する Cloud Interconnect アタッチメント（VLAN）を制御できます。

3. ネットワークの要件

Private Service Connect を使用するには、外部 IP アドレスを持たない仮想マシン（VM）インスタンスのプライマリインターフェースが、限定公開の Google アクセスが有効になっているサブネット内に必要です。

外部 IP アドレスを持つ VM は、そのサブネットで限定公開の Google アクセスが有効になっているかどうかにかかわらず、Private Service Connect エンドポイントを使用して Google API とサービスにアクセスできます。Private Service Connect エンドポイントへの接続は、Google のネットワーク内にとどまります。

Private Service Connect エンドポイントは、ピアリングされた VPC ネットワークからアクセスできません。

サポートされている API

Private Service Connect エンドポイントを作成するときに、アクセスする必要がある API のバンドル（all-apis または vpc-sc）を選択します。

API バンドルを使用すると、限定公開の Google アクセス VIP で利用できる API にアクセスできます。

all-apis バンドルを使用すると、private.googleapis.com と同じ API にアクセスできます。
vpc-sc バンドルは、restricted.googleapis.com と同じ API へのアクセスを提供します。

4. Codelab のトポロジとユースケース

図 1 - Codelab のトポロジ

Codelab のユースケース -

お客様は、Cloud Storage のデータ転送にプライベート（相互接続）アクセスとパブリック googleapis アクセスを組み合わせて使用する必要があります。お客様の要件を満たすために、一意の /32 アドレス、BOTO 構成、DNS レコードの更新で構成される Private Service Connect をデプロイします。仮想マシン 1 は Cloud Storage バケットへのアクセスに PSC を使用します。一方、VM2 は NAT GW 経由でパブリック googleapis.com の IP 範囲を使用します。

このラボのすべての側面が Google Cloud Platform 内にデプロイされますが、トラフィックの分離を必要とするハイブリッドクラウドデプロイにも同じユースケースを適用できます。

5. 設定と要件

セルフペース型の環境設定

Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト ID を忘れないようにしてください。プロジェクト ID はすべての Google Cloud プロジェクトを通じて一意の名前にする必要があります（上記の名前はすでに使用されているので使用できません）。以降、このコードラボでは PROJECT_ID と呼びます。

次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。

このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、$300 USD 分の無料トライアルプログラムをご利用いただけます。

Cloud Shell の起動

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホームディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。

6. 始める前に

API を有効にする

Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

必要なサービスをすべて有効にする

gcloud services enable compute.googleapis.com
gcloud services enable servicedirectory.googleapis.com
gcloud services enable dns.googleapis.com

7. VPC ネットワークを作成

VPC ネットワーク

Cloud Shell から

gcloud compute networks create psc-lab --subnet-mode custom

サブネットの作成

Cloud Shell から

gcloud compute networks subnets create psclab-subnet \
--network psc-lab --range 10.0.0.0/24 --region us-central1 --enable-private-ip-google-access

ファイアウォールルールを作成する

IAP に VM インスタンスへの接続を許可するには、次のファイアウォールルールを作成します。

IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。

Cloud Shell から

gcloud compute firewall-rules create psclab-ssh \
    --network psc-lab --allow tcp:22 --source-ranges=35.235.240.0/20

Cloud NAT インスタンスを作成する

Cloud Router の作成

Cloud Shell から

gcloud compute routers create crnat \
    --network psc-lab \
    --asn 65000 \
    --region us-central1

Cloud NAT を作成する

Cloud Shell から

gcloud compute routers nats create cloudnat \
    --router=crnat \
    --auto-allocate-nat-external-ips \
    --nat-all-subnet-ip-ranges \
    --enable-logging \
    --region us-central1

8. Private Service Connect エンドポイントを作成する

Private Service Connect エンドポイント IP <pscendpointip> を構成する場合は、VPC で定義されていない一意の IP アドレスを指定する必要があります。

Cloud Shell から

gcloud compute addresses create psc-ip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=192.168.255.250 \
    --network=psc-lab

「pscendpointip」を保存使用しないでください。

pscendpointip=$(gcloud compute addresses list --filter=name:psc-ip --format="value(address)")

echo $pscendpointip

エンドポイントを Google API およびサービスに接続する転送ルールを作成します。

Cloud Shell から

gcloud compute forwarding-rules create pscendpoint \
    --global \
    --network=psc-lab \
    --address=psc-ip \
    --target-google-apis-bundle=all-apis

構成済みの Private Service Connect エンドポイントを一覧表示する

Cloud Shell から

gcloud compute forwarding-rules list  \
--filter target="(all-apis OR vpc-sc)" --global

構成した Private Service Connect エンドポイントの説明を取得する

Cloud Shell から

gcloud compute forwarding-rules describe \
    pscendpoint --global

9. バケットを作成する

Cloud Storage バケットを作成し、BUCKET_NAME を任意のグローバルに一意の名前に置き換えます。

Cloud Shell から

gsutil mb  -l us-central1 -b on gs://BUCKET_NAME

'BUCKET_NAME' を保存使用しないでください。

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME

10. DNS 構成

Private Service Connect エンドポイントを作成すると、そのエンドポイントを使用して利用可能な API とサービスの DNS レコードが Service Directory によって生成されます。

DNS レコードは Private Service Connect エンドポイントの IP アドレスを指し、形式は SERVICE-ENDPOINT.p.googleapis.com です。

API リクエストでこれらの DNS 名を使用して、リクエストを Private Service Connect エンドポイントに転送できます。これらの DNS 名はリクエストの Host ヘッダーでも使用できます。

Google API とサービスにアクセスするクライアントまたはアプリケーションで Private Service Connect エンドポイントを使用する場合は、p.googleapis.com の DNS 名を使用するようにクライアントまたはアプリケーションを更新します。

詳しくは、クライアントまたはクライアントライブラリのドキュメントをご覧ください。例:

Python: api_endpoint は google-api-core パッケージのクライアントオプションクラスで構成できます。
Go: API パッケージのクライアントオプションパッケージで WithEndpoint を構成できます。
gcloud: 次のコマンドを使用して api_endpoint_overrides を構成できます。gcloud config set api_endpoint_overrides/SERVICE ENDPOINT_URL

例: gcloud config set api_endpoint_overrides/storage https://storage-xyz.p.googleapis.com/storage/v1/

別のエンドポイントを使用するようにクライアントまたはアプリケーションを構成できない場合は、デフォルトの DNS 名と一致する DNS レコードを作成します。（例: storage.googleapis.com）。デフォルトの DNS 名を使用して DNS レコードを作成するをご覧ください。

DNS レコードを検証する

Cloud コンソールで、[ネットワークサービス] → [Cloud DNS] で生成された DNS エントリを確認します。生成された DNS 名「p.googleapis.com」をメモします。

11. 仮想マシンの作成

Private Service Connect の検証に使用する仮想マシン（psc-instance-1）を作成する

Cloud Shell から

  gcloud compute instances create psc-instance-1 \
    --subnet psclab-subnet \
    --zone us-central1-a \
    --image=centos-7-v20210122 \
    --image-project=centos-cloud \
    --no-address \
    --metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y

VM インスタンス（psc-instance-1）にログインします。

Cloud Shell を使用して VM に SSH 接続する

gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"

+（以下のスクリーンショット）を 3 回クリックして、追加の Cloud Shell ターミナルを作成します。

公開されている Google API の検証に使用する仮想マシン（psc-instance-2）を作成する

タブ 2 から

  gcloud compute instances create psc-instance-2 \
    --subnet psclab-subnet \
    --zone us-central1-a \
    --image=centos-7-v20210122 \
    --image-project=centos-cloud \
    --no-address \
    --metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y

タブ 2 から、Cloud Shell を介して VM に SSH 接続します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname


gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"

タブ 3 から、Cloud Shell 経由で psc-instance-1 に SSH 接続

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname


gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"

タブ 4 から、Cloud Shell を使用して psc-instance-2 に SSH で接続します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname


gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"

12. 既存の gsutil の動作を確認する

タブ 4（psc-instance-2）から tcpdump を開始し、DNS トラフィックを監視します。

sudo tcpdump -vv -i eth0 port 53

タブ 2（psc-instance-2）からのストレージバケットの DNS ルックアップを調査

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME
gsutil -D ls gs://$BUCKET_NAME

gsutil のデバッグを調べる。HOST storage.googleapis.com は DNS の解決に使用されている。

<snip>
send: 'GET /storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\nHost: storage.googleapis.com\r\ncontent-length: 0\r\nauthorization: Bearer ya29.c.KpkB7wfaMjfc_WXEKCeNF4Md0fEHnfDU7tqBf3cd0u43yEmYXqj8fX_X5wWdNdDVH6k1EkjeAeIJDzKGvyjPOkf1Io2kVeUqYX69sDv53huW1NslffjAHKchbZ0CP3Cg83TS3Pa55jLcuE0TLbYycVrgSbD3H90LaapUGbWD3kj4IsJLf9J8R98Bqobu8HZwwqk92hlZ4zVzRqOM\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
<snip>

タブ 4（psc-instance-2）から、ストレージバケットへのアクセス時に GoogleAPI.com パブリック DNS A レコードが使用されていることを確認します。

metadata.google.internal.domain > psc-instance-2.c.yourprojectname.internal.33973: [udp sum ok] 36442 q: A? storage.googleapis.com. 11/0/0 storage.googleapis.com. A 108.177.111.128, storage.googleapis.com. A 142.250.128.128, storage.googleapis.com. A 74.125.70.128, storage.googleapis.com. A 74.125.201.128, storage.googleapis.com. A 64.233.183.128, storage.googleapis.com. A 173.194.198.128, storage.googleapis.com. A 172.217.219.128, storage.googleapis.com. A 142.250.136.128, storage.googleapis.com. A 209.85.234.128, storage.googleapis.com. A 172.217.212.128, storage.googleapis.com. A 172.217.214.128

13. gsutil の動作を変更する

前のステップで、PSC エンドポイントの IP アドレスにマッピングされた限定公開 DNS ゾーンと A レコードを作成したことを思い出してください。次のステップでは、psc-instance-1 の VM BOTO ファイルを更新して、gsutil の動作を制御します。

タブ 1（psc-instance-1）の VM インスタンスターミナルで BOTO のデフォルト構成を表示する

[psc-instance ~]$ more  /etc/boto.cfg

出力（project_id は異なります）

[GSUtil]
default_project_id  = [your project number]
default_api_version = 2

[GoogleCompute]
service_account = default

nano エディタまたは VI エディタを使用して BOTO の構成を更新し、すべてのエントリをコピーして貼り付けます。

例: sudo nano /etc/boto.cfg

または

例: sudo vi /etc/boto.cfg

VM インスタンスのターミナルタブ 1（psc-instance-1）から

[Credentials]
gs_host = storage-pscendpoint.p.googleapis.com
gs_host_header = storage.googleapis.com
gs_json_host = storage-pscendpoint.p.googleapis.com
gs_json_host_header = www.googleapis.com

構成を検証する。DNS ルックアップには [認証情報] の順序が重要

more /etc/boto.cfg
[Credentials]
gs_host = storage-pscendpoint.p.googleapis.com
gs_host_header = storage.googleapis.com
gs_json_host = storage-pscendpoint.p.googleapis.com
gs_json_host_header = www.googleapis.com

[GSUtil]
default_project_id  = [your project number
default_api_version = 2

[GoogleCompute]
service_account = default

14. 更新された gsutil ルックアップ動作を確認する

タブ 3（psc-instance-1）から tcpdump を開始し、DNS トラフィックを監視します。

sudo tcpdump -vv -i eth0 port 53

タブ 1（psc-instance-1）でのストレージバケット gsutil ルックアップの調査

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME

gsutil -D ls gs://$BUCKET_NAME

デバッグログで、Private Service Connect エンドポイント「pscendpoint」を介してストレージバケットに到達可能であることを確認する

出力:

<snip>
INFO 0131 22:14:18.795986 base_api.py] Making http GET to https://storage-pscendpoint.p.googleapis.com/storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000
INFO 0131 22:14:18.796415 base_api.py] Headers: {u'Host': 'www.googleapis.com',
 'accept': 'application/json',
 'accept-encoding': 'gzip, deflate',
 'content-length': '0',
 'user-agent': 'apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0'}
INFO 0131 22:14:18.796502 base_api.py] Body: (none)
connect: (storage-pscendpoint.p.googleapis.com, 443)
send: 'GET /storage/v1/b/psc-bucket/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\ncontent-length: 0\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\nhost: www.googleapis.com\r\nauthorization: Bearer ya29.c.KpkB7wd3XWiYeRyTuth5_HPlNV-hPwc2Nn7RSIeMpzrpa_j4EsMPl2m_mDGKAcGHvYIgiC5bT2UVQirAPpSbbpToa6G6lkaBbH5SZwHwgNXYfisp5Ww1UjXe4rTa69a_Wp0WesafcwPNnYzDo3xf5VGh3iGhySA04kTXuyT--MgOU8U-XLII2LJQxUWlV8KEdrvyCuqRb-jsDdk_\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
<snip>

タブ 3（psc-instance-1）で、PSC エンドポイント IP がストレージバケットへのアクセス時に使用された DNS A レコードであることを確認します。

@psc-instance-1 ~]$ sudo tcpdump -vv -i eth0 port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:02:33.936256 IP (tos 0x0, ttl 64, id 55416, offset 0, flags [DF], proto UDP (17), length 82)
    psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0xcceb!] 34796+ A? storage-pscendpoint.p.googleapis.com. (54)
05:02:33.936269 IP (tos 0x0, ttl 64, id 55417, offset 0, flags [DF], proto UDP (17), length 82)
    psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0x3ebd!] 5632+ AAAA? storage-pscendpoint.p.googleapis.com. (54)
05:02:33.944018 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 98)
    metadata.google.internal.domain > psc-instance-1.c.yourprojectname.42296: [udp sum ok] 34796 q: A? storage-pscendpoint.p.googleapis.com. 1/0/0 storage-pscendpoint.p.googleapis.com. A 10.10.110.10 (70)
05:02:33.946005 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 175)

Private Service Connect エンドポイント IP が DNS の解決に使用されるようになったことを確認する

tab1 から

nslookup storage-pscendpoint.p.googleapis.com

出力

@psc-instance ~]$ nslookup storage-pscendpoint.p.googleapis.com
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   storage-pscendpoint.p.googleapis.com
Address: <pscip>

15. クリーンアップ手順

VM インスタンスを終了（すべてのタブ）

exit

単一の Cloud Shell ターミナルからラボのコンポーネントを削除する

gcloud compute routers nats delete cloudnat --router=crnat --region=us-central1 --quiet

gcloud compute routers delete crnat --region=us-central1 --quiet

gcloud compute forwarding-rules delete pscendpoint --global --quiet

gcloud compute addresses delete psc-ip --global --quiet

gsutil rm -r gs://$BUCKET_NAME

gcloud compute instances delete psc-instance-1 --zone=us-central1-a --quiet

gcloud compute instances delete psc-instance-2 --zone=us-central1-a --quiet

gcloud compute firewall-rules delete psclab-ssh --quiet

gcloud compute networks subnets delete psclab-subnet --region us-central1 --quiet

gcloud compute networks delete psc-lab --quiet

コンソールで、正しいプロジェクトが表示されていることを確認し、[ネットワーキングサービス] → [Cloud DNS] を選択します。

16. 完了

以上で、この Codelab は完了です。

学習した内容

Private Service Connect のユースケース
ネットワークの要件
サポートされている API
Private Service Connect エンドポイントを作成しました
Cloud Storage バケットを作成している
BOTO 構成ファイルを更新しました
NAT GW の作成
VM1 で PSC サービスエンドポイントに対して解決される gsutil list を実行する
VM2 で gsutil list を実行し、公開中の googleapis.com に対して解決する
tcpdump を使用して DNS の解決を検証する