限定公開の Google アクセスでは、プライベート IP アドレスのみを持つ VM が有効化され、Google API とサービスの IP アドレスにアクセスします。このシナリオには、Google Distributed Cloud クラスタのノードにプライベート IP アドレスしかない場合も含まれます。限定公開の Google アクセスは、サブネット レベルで有効にします。
限定公開の Google アクセスでは、オンプレミス データセンターから Google サービスへのリクエストは、公共のインターネットではなく、Cloud Interconnect または Cloud VPN 接続を経由します。
次のような状況では、限定公開の Google アクセスを使用します。
パブリック IP アドレスのないオンプレミス VM が、BigQuery、Pub/Sub、Container Registry などの Google サービスに接続する必要がある。
プライベート IP アドレスのみを持つ VM からサービスにアクセスするのに、限定公開の Google アクセスが不要な場合もあります。例:
パブリック IP アドレスとプライベート IP アドレスの両方を持つ Cloud SQL インスタンスを作成します。これにより、オンプレミス コンポーネントはプライベート IP アドレスを使用して Cloud SQL インスタンスにアクセスできます。この場合、Google サービスのパブリック IP アドレスにアクセスする必要がないため、限定公開の Google アクセスは必要ありません。このアプローチは、Cloud Router が Cloud SQL インスタンスのプライベート IP アドレスをオンプレミス ネットワークにアドバタイズする場合にのみ機能します。
Google Cloudに Google Distributed Cloud クラスタがあり、クラスタノードにはプライベート IP アドレスがあります。オンプレミス コンポーネントは、クラウドの Google Distributed Cloud クラスタの NodePort Service または内部ロードバランサ Service にアクセスできます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-01 UTC。"],[],[],null,["There are various ways that you can connect Google Distributed Cloud\nclusters, running in your on-premises data center, to the Google Cloud\nnetwork. Possibilities include:\n\n- Regular internet connection\n- [HA VPN](/network-connectivity/docs/vpn/concepts/overview)\n- [Partner Interconnect](/network-connectivity/docs/interconnect/concepts/partner-overview)\n- [Dedicated Interconnect](/network-connectivity/docs/interconnect/concepts/dedicated-overview)\n\nRegular internet connection\n\nIn certain scenarios, you can use the internet as the connection between Google\nand your on-premises data center. For example:\n\n- Your Google Distributed Cloud deployment is self-contained on your premises, and\n your on-premises components seldom communicate with the Google Cloud\n network. You use the connection primarily for cluster management. The speed,\n reliability, and security of the connection are not critical.\n\n- Your on-premises cluster is self-contained, except for access to a Google\n service like Cloud SQL. Traffic between your on-premises cluster and the\n Google service uses public IP addresses. You configure firewall rules to\n provide security.\n\nHA VPN\n\nWith [HA VPN](/vpn/docs/concepts/overview) and\n[Cloud Router](/network-connectivity/docs/router), traffic between Google\nand your on-premises data center traverses the public internet, but is\nencrypted. on-premises components can communicate with cloud components using\nprivate IP addresses. Cloud Router dynamically exchanges routes between your\nGoogle Cloud networks and your on-premises network. Dynamic routing is\nespecially beneficial as your network expands and changes, because it ensures\nthat the correct routing state is propagated to your on-premises data center.\n\nOne way to set up an HA VPN between Google Cloud and\nan on-premises GKE Enterprise cluster is to configure\n[Network Connectivity Gateway](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/network-connectivity-gateway)\n\nin the cluster. Network Connectivity Gateway is available for\n[Preview](/products#product-launch-stages).\n\nPartner Interconnect\n\n[Partner Interconnect](/network-connectivity/docs/interconnect/concepts/partner-overview)\nprovides connectivity between your on-premises network and the\nGoogle Cloud network through a supported service provider. Traffic\nbetween Google and your on-premises data center does not traverse the public\ninternet. On-premises components can communicate with cloud components using\nprivate IP addresses. Your connection to Google is fast, secure, and reliable.\n\nDedicated Interconnect\n\n[Dedicated Interconnect](/network-connectivity/docs/interconnect/concepts/dedicated-overview)\nprovides a direct physical connection between your on-premises network and the\nGoogle Cloud network. This type of connection can be cost-effective if\nyou need high bandwidth. Traffic between Google and your on-premises data\ncenter does not traverse the public internet. On-premises components can\ncommunicate with cloud components using private IP addresses. Your connection to\nGoogle is secure and reliable, and is even faster than a connection using\nPartner Interconnect.\n\nImpact of a temporary disconnection\n\nFor information on what happens if you're disconnected, see\n[Impact of temporary disconnection from Google Cloud](/anthos/docs/concepts/anthos-connectivity).\n\nChoosing a connection type\n\nFor additional guidance on choosing a connection type, see:\n\n- [Choosing a VPN Routing Option](/network-connectivity/docs/how-to/choose-product#cloud-vpn)\n- [Choose an Interconnect Type](/network-connectivity/docs/how-to/choose-product#cloud-interconnect)\n\nNetwork monitoring\n\nRegardless of how you establish a fundamental connection to Google, you can\nbenefit from insights provided by network logging and monitoring. For more\ninformation, see\n[Logging and monitoring](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/log-monitoring)\n\nfor Google Distributed Cloud.\n\nEnhancing your fundamental connection\n\nAfter your fundamental connection is in place, you can add features that enhance\naccess, security, and visibility. For example, you could enable\n[Private Google Access](/vpc/docs/configure-private-google-access),\n[Connect](/anthos/multicluster-management/connect/overview), or\n[VPC Service Controls](/vpc-service-controls/docs).\n\nThe remainder of the guidance in this topic assumes you're using one of the\nfollowing options for your fundamental connection to Google:\n\n- [HA VPN](/network-connectivity/docs/vpn/concepts/overview)\n- [Partner Interconnect](/network-connectivity/docs/interconnect/concepts/partner-overview)\n- [Dedicated Interconnect](/network-connectivity/docs/interconnect/concepts/dedicated-overview)\n\nPrivate Google Access\n\n[Private Google Access](/vpc/docs/configure-private-google-access) enables VMs\nthat have only private IP addresses to reach the IP addresses of [Google APIs\nand services](https://developers.google.com/apis-explorer/). This scenario\nincludes the case where your Google Distributed Cloud cluster nodes have only\nprivate IP addresses. You enable Private Google Access at the subnet level.\n\nWith Private Google Access, requests from your on-premises data center\nto Google services traverse your Cloud Interconnect or\nCloud VPN connection instead of traversing the public internet.\n\nUse Private Google Access in these situations:\n\n- Your on-premises VMs without public IP addresses must connect to Google\n services like BigQuery, Pub/Sub, or Container Registry.\n\n- You want to connect to Google services without traversing the public internet.\n\nFor a list of services that support Google Private Access from on-premises VMs, see\n[Supported services](/vpc/docs/private-google-access-hybrid#supported-services-onprem).\nFor information about using Private Google Access from on-premises VMs, see\n[Configuring Private Google Access for on-premises hosts](/vpc/docs/configure-private-google-access-hybrid).\n\nServices that don't require Google Private Access\n\nSometimes, you don't need Private Google Access to reach a service from a\nVM that has only a private IP address. For example:\n\n- You create a Cloud SQL instance that has both a public IP address and a\n private IP address. Then your on-premises components can access the\n Cloud SQL instance using its private IP address. You don't need\n Private Google Access in this case, because you don't need to reach the\n public IP address of a Google service. This approach works only if\n Cloud Router advertises the private IP address of the\n Cloud SQL instance to your on-premises network.\n\n- You have an Google Distributed Cloud cluster in Google Cloud, and the\n cluster nodes have private IP addresses. Your on-premises components can\n access a NodePort Service or an internal load balancer Service in the cloud\n Google Distributed Cloud cluster.\n\nVPC Service Controls\n\nIf you want added protection against exfiltration, you can use\n[VPC Service Controls](/vpc-service-controls/docs/overview).\nWith VPC Service Controls, you can configure security perimeters around the\nresources of your Google-managed services and control the movement of data\nacross the perimeter boundary. For more information, see\n[Use VPC Service Controls with Cloud Interconnect or Cloud VPN](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/hardening-your-cluster#vpc-sc).\n\n\nConnect\n\n[Connect](/anthos/multicluster-management/connect/overview) enables you\nto view and manage your on-premises user clusters from Google Cloud console.\n| **Note:** Connect is not the fundamental connection between your on-premises data center and Google. Your fundamental connection is formed with [Cloud Interconnect](/network-connectivity/docs/interconnect) or [Cloud VPN](/network-connectivity/docs/vpn/concepts/overview). To provide a view of your on-premises clusters from Google Cloud console, Connect runs on top of your fundamental connection.\n\nWhat's next\n\n- [Logging and monitoring](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/log-monitoring)\n- [Cloud VPN](/network-connectivity/docs/vpn/concepts/overview)\n- [Partner Interconnect](/network-connectivity/docs/interconnect/concepts/partner-overview)\n- [Dedicated Interconnect](/network-connectivity/docs/interconnect/concepts/dedicated-overview)"]]
