라우터 어플라이언스는 Google Cloud에서 서드 파티 네트워크 가상 어플라이언스를 사용할 수 있게 해주는 Network Connectivity Center 기능입니다. 이 방법을 사용하면 어플라이언스는 경계 게이트웨이 프로토콜(BGP)을 사용하여 Cloud Router와 경로를 교환할 수 있습니다.
라우터 어플라이언스와 Network Connectivity Center를 사용하여 다음을 수행할 수 있습니다.
여러 VPC 네트워크를 서로 연결합니다. VPC 네트워크는 동일한 Google Cloud 조직 또는 다른 조직의 여러 프로젝트 전반에 위치할 수 있습니다.
여러 VPC 네트워크를 온프레미스 또는 다른 클라우드 제공업체 네트워크에 연결합니다.
이러한 외부 네트워크는 모든 유형의 하이브리드 스포크를 통해 연결할 수 있습니다.
이러한 방식을 사이트-클라우드 연결이라고 부릅니다.
라우터 어플라이언스 VM을 사용하여 VPC 네트워크 간의 연결을 관리합니다.
Google Cloud VPC 네트워크를 엔터프라이즈 광역 통신망(WAN)으로 사용해서 Google Cloud외부에 있는 네트워크를 연결합니다.
모든 유형의 하이브리드 스포크를 사용하여 외부 사이트 간에 연결을 설정할 수 있습니다. 이러한 방식을 사이트-사이트 연결이라고 부릅니다.
기능 소개
Compute Engine VM에 이미지를 설치하여 라우터 어플라이언스 인스턴스를 구성할 수 있습니다. 지원되는 Network Connectivity Center 파트너에서 제공하는 이미지를 사용할 수 있습니다. 사용자가 만든 이미지와 같은 커스텀 이미지를 사용할 수도 있습니다.
라우터 어플라이언스 인스턴스가 설치된 후 라우터 어플라이언스 인스턴스와 경계 게이트웨이 프로토콜(BGP) 피어링을 설정하도록 Cloud Router에서 인터페이스를 구성합니다. BGP는 Cloud Router와 라우터 어플라이언스 인스턴스 간에 경로를 동적으로 교환합니다. 그런 후 경로 교환은 라우터 어플라이언스 인스턴스를 통해 사이트에서 VPC 네트워크로의 연결을 허용합니다. 즉, 라우터 어플라이언스 인스턴스에서 전파한 경로는 동일한 VPC 네트워크에 IP 주소가 있는 VM 및 기타 리소스에서 사용될 수 있습니다.
Cloud Router는 RFC 1918 내부 IP 주소로 구성된 인터페이스를 사용하여 라우터 어플라이언스 인스턴스와의 BGP 피어링을 설정합니다.
라우터 어플라이언스에는 별도의 API 또는 Google Cloud 리소스 또는 권한이 없습니다. 라우터 어플라이언스로 작업하려면 Compute Engine 및 Cloud Router 리소스 및 권한을 사용합니다.
사용 사례: 온프레미스 사이트 간 데이터 전송
다음 토폴로지는 VPC 네트워크와 2개의 온프레미스 사이트를 보여줍니다. 각 온프레미스 사이트는 라우터 어플라이언스 스포크를 사용하여 Google Cloud 에 연결합니다. 두 온프레미스 사이트가 Google 네트워크를 사용해서 서로 데이터를 교환할 수 있습니다.
라우터 어플라이언스 토폴로지(확대하려면 클릭)
온프레미스 Customer network A 및 Customer network B는 각각 고객 온프레미스 장비(CPE)를 통해 라우터 어플라이언스 인스턴스에 연결됩니다.
CPE는 일반적으로 SD-WAN 오버레이 터널 또는 IPsec VPN 터널과 같은 연결 메커니즘을 사용하여 라우터 어플라이언스 인스턴스와의 연결을 설정합니다.
각 라우터 어플라이언스 인스턴스는 연결된 고객 네트워크와 가장 가까운Google Cloud 리전에 있습니다. 두 라우터 어플라이언스 인스턴스는 모두 단일 VPC 네트워크에 있습니다.
하지만 라우터 어플라이언스 인스턴스는 다른 리전에 있습니다. 이러한 이유로 VPC 네트워크의 동적 라우팅 모드가 global로 설정됩니다.
두 라우터 어플라이언스 인스턴스는 모두 Network Connectivity Center 허브에 스포크로 연결됩니다. Customer network A와 Customer network B가 서로 데이터를 전송해야 하므로 두 스포크 모두 사이트 간 데이터 전송 필드가 사용 설정됩니다.
사이트 간 데이터 전송은 지원되는 위치에서만 사용할 수 있습니다. 자세한 내용은 데이터 전송이 지원되는 위치를 참조하세요.
각 리전에서 라우터 어플라이언스 인스턴스는 적합한 Cloud Router와 함께 Border Gateway Protocol(BGP) 피어링을 설정합니다. 각 Cloud Router는 해당 온프레미스 위치에서 경로 프리픽스를 수신하고 공지합니다.
Cloud Router는 수신된 모든 경로를 서로 동적으로 교환합니다. 이 구성은 Customer network A와 Customer network B 간의 엔드 투 엔드 동적 경로 교환 및 데이터 영역 연결을 제공합니다.
여러 네트워크 인터페이스가 라우터 어플라이언스 인스턴스의 일부로 구성된 VM의 경우 VM 인터페이스와 동일한 서브넷에 있는 Cloud Router로 BGP 세션을 설정할 수 있습니다.
VM 인터페이스에 대한 자세한 내용은 다중 네트워크 인터페이스 개요 및 예시를 참조하세요.
가용성 권장사항
Compute Engine VM의 표준 서비스수준계약(SLA)도 라우터 어플라이언스 인스턴스의 가용성에 적용됩니다. 이 가용성 SLA는 단일 VM의 경우 99.5%, 여러 영역에 있는 VM의 경우 99.99%입니다. 자세한 내용은 Compute Engine SLA를 참조하세요.
서로 다른 온프레미스 위치마다 라우터 어플라이언스 인스턴스 쌍에 대해 서로 다른 영역에서 2개 이상의 VM을 실행합니다. 각 VM은 중복 Cloud Router 인터페이스 쌍과 피어링해야 합니다.
영역에 대한 자세한 내용은 리전 및 영역을 참조하세요.
고려사항
라우터 어플라이언스를 사용하려면 먼저 다음 섹션을 검토하세요.
일반적인 고려사항
라우터 어플라이언스를 사용하려면 Network Connectivity Center가 필요합니다. 즉, Cloud Router나 다른 피어 라우터와 피어링하는 독립형 라우터 어플라이언스 인스턴스를 구성할 수 없습니다. 라우터 어플라이언스 인스턴스를 Network Connectivity Center 스포크의 일부로 구성해야 합니다.
라우터 어플라이언스는 호스트 프로젝트에 배포된 경우에만 공유 VPC 모델에서 지원됩니다. 라우터 어플라이언스 인스턴스는 호스트 프로젝트 및 허브, 스포크, Cloud Router와 같은 다른 모든 관련 리소스에 배포되어야 합니다.
라우터 어플라이언스 VM이 서비스 프로젝트에 배포된 경우 라우터 어플라이언스는 공유 VPC를 지원하지 않습니다.
라우팅 고려사항
여러 라우터 어플라이언스 인스턴스가 동일한 MED로 동일한 라우팅 프리픽스를 공지하는 경우 Google Cloud 는 모든 라우터 어플라이언스 인스턴스에서 동일 비용 다중 경로(ECMP) 라우팅을 사용합니다.
혼합된 스포크 유형(라우터 어플라이언스 인스턴스, Cloud VPN 게이트웨이, VLAN 연결)을 통해 동일한 프리픽스를 공지하지 않는 것이 좋습니다. 혼합된 스포크 유형을 통해 동일한 프리픽스에 연결할 수 있는 경우, 혼합된 스포크 유형 전반에서 ECMP를 사용하면 각 링크 간에 트래픽이 불균형될 수 있습니다.
단일 Cloud Router가 여러 개의 다음 홉이 있는 프리픽스를 학습하는 경우 Cloud Router는 AS 경로 길이가 가장 짧은 다음 홉을 선택한 후 MED를 사용하여 연결을 끊습니다. 자세한 내용은 Cloud Router 문서의 AS 경로 길이를 참조하세요.
[[["이해하기 쉬움","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-05(UTC)"],[],[],null,["# Router appliance overview\n\nRouter appliance is a Network Connectivity Center feature that lets you use a\nthird-party network virtual appliance in Google Cloud. When you use this\napproach, the appliance can exchange routes with Cloud Router by\nusing Border Gateway Protocol (BGP).\n\nUsing Router appliance and Network Connectivity Center, you can do the following:\n\n- Connect multiple VPC networks to one another. The VPC networks can be located across different projects in the same Google Cloud organization or different organizations.\n- Connect multiple VPC networks to on-premise or other cloud provider networks. These external networks can be reachable through any type of hybrid spoke. This approach is known as *site-to-cloud connectivity.*\n- Use Router appliance VMs to manage connectivity between your VPC networks.\n- Use a Google Cloud VPC network as an enterprise wide area network (WAN) to connect networks that are outside of Google Cloud. You can establish connectivity between your external sites by using any type of hybrid spoke. This approach is known as *site-to-site\n connectivity*.\n\nHow it works\n------------\n\nYou can configure a router appliance instance by installing\nan image on a Compute Engine VM. You can use an image provided by a\n[supported Network Connectivity Center partner](/network-connectivity/docs/network-connectivity-center/partners). You can also use a custom image, such as an image that you\ncreated.\n\nAfter the router appliance instance is installed, you configure interfaces on\nthe Cloud Router to establish Border Gateway Protocol (BGP) peering\nwith the router appliance instance. BGP enables the dynamic exchange of routes\nbetween the Cloud Router and the router appliance instance. Route\nexchange, in turn, permits connectivity from the site through the router\nappliance instance to the VPC network. That is, the routes\npropagated by the router appliance instance can be used by VMs and other\nresources that have IP addresses in the same VPC network.\n\nCloud Router uses interfaces configured with RFC 1918 internal IP\naddresses to establish BGP peering with router appliance instances.\n\nThere are no separate APIs or Google Cloud resources or permissions for\nRouter appliance. To work with Router appliance, you use\nCompute Engine and Cloud Router resources and permissions.\n\nUse case: Data transfer between on-premises sites\n-------------------------------------------------\n\nThe following topology shows a VPC network and two on-premises\nsites. Each on-premises site connects to Google Cloud by using a\nRouter appliance spoke. The two on-premises sites can use Google's network\nto exchange data with each other.\n[](/static/network-connectivity/docs/network-connectivity-center/images/router-appliance-topology.svg) Router appliance topology (click to enlarge)\n\n1. On-premises `Customer network A` and `Customer network B` are each connected\n through *customer premises equipment (CPE)* to a router appliance instance.\n CPEs typically use a connectivity mechanism, such as an SD-WAN overlay tunnel\n or an IPsec VPN tunnel, to establish connectivity with the\n router appliance instance.\n\n Each router appliance instance is located in the\n Google Cloud region closest to its associated customer network. Both\n router appliance instances are in a single VPC network.\n However, the router appliance instances are in different regions. For this\n reason, the VPC network has its\n [dynamic routing mode](/vpc/docs/create-modify-vpc-networks#switch-dynamic-routing)\n set to `global`.\n2. Both router appliance instances are attached as spokes to the\n Network Connectivity Center hub. Because `Customer network A` and `Customer network B`\n need to send data to each other, both spokes have the site-to-site data\n transfer field enabled.\n\n *You can use site-to-site data transfer only in supported locations.* For\n more information, see\n [Locations supported for data transfer](/network-connectivity/docs/network-connectivity-center/concepts/locations).\n3. In each region, a router appliance instance establishes Border Gateway\n Protocol (BGP) peering with the appropriate Cloud Router. Each\n Cloud Router receives and advertises route prefixes from the\n corresponding on-premises location.\n\n4. The Cloud Routers dynamically exchange all received\n routes with each other. This configuration provides end-to-end dynamic route\n exchange and data plane connectivity between `Customer network A` and\n `Customer network B`.\n\n | **Important:** For Cloud Routers in different regions to exchange routes with each other, you must enable global dynamic routing mode in your VPC network. For more information, see [Dynamic routing](/vpc/docs/vpc#routing_for_hybrid_networks).\n\nFor detailed configuration steps for a load-balanced single-site topology,\nsee\n[Create router appliance instances](/network-connectivity/docs/network-connectivity-center/how-to/creating-router-appliances).\n\nRequirements\n------------\n\nFollow these requirements when deploying router appliance instances.\n\n### BGP configuration\n\n- The router appliance image that you install must support the BGP routing protocol.\n- To enable BGP peering between a router appliance instance and a Cloud Router, attach each router appliance instance as a spoke to a Network Connectivity Center hub.\n- Create a Cloud Router in the same region as the [subnet](/vpc/docs/vpc#subnets_vs_subnetworks) that contains the peering interface of the router appliance instance.\n- Manually create BGP interfaces on the router appliance instance. These interfaces must be in the same subnet as the router appliance instance.\n- Manually create BGP sessions with Cloud Router from the router appliance instance.\n- For VMs that have multiple network interfaces configured as part of the router appliance instance, you can establish BGP sessions with Cloud Routers that are in the same subnet as the VM interface. For more information about VM interfaces, see [Multiple network interfaces overview and examples](/vpc/docs/multiple-interfaces-concepts).\n\n### Availability recommendations\n\n- The standard service-level agreement (SLA) for Compute Engine VMs also applies to the availability of router appliance instances. This availability SLA is 99.5% for a single VM and 99.99% for VMs in multiple zones. For more information, see the [Compute Engine SLA](/compute/sla).\n- For a pair of router appliance instances, each for a different on-premises location, run at least two VMs in different zones. Each VM must peer with a pair of redundant Cloud Router interfaces. For more information about zones, see [Regions and zones](/compute/docs/regions-zones).\n\nConsiderations\n--------------\n\nBefore using Router appliance, review the following sections.\n\n### General considerations\n\n- *Router appliance requires Network Connectivity Center to operate.* That is, you can't configure standalone router appliance instances that peer with a Cloud Router or with other peer routers. You must configure router appliance instances as part of a Network Connectivity Center spoke.\n- Router appliance is only supported in the Shared VPC model when\n deployed in the host project. The router appliance instance must be deployed\n in the host project and all the other associated resources, such as hub,\n spoke, and Cloud Router.\n\n Router appliance does not support Shared VPC when the\n Router appliance VM is deployed in the service project.\n\n### Routing considerations\n\n- If multiple router appliance instances announce the same routing prefixes with the same MED, Google Cloud uses equal-cost multipath (ECMP) routing across all the router appliance instances.\n- *We recommend not advertising the same prefixes through a mix of different\n spoke types (router appliance instances, Cloud VPN gateways,\n and VLAN attachments).* If the same prefixes are reachable through a mix of spoke types, using ECMP across the mixed spoke types can lead to imbalanced traffic across each link.\n- If a single Cloud Router learns a prefix with multiple next hops, Cloud Router selects the next hops with the shortest AS path length first, and then uses the MED to break ties. For more information, see [AS path length](/router/concepts/learned-routes#as-path-length-considerations) in the Cloud Router documentation.\n\nWhat's next\n-----------\n\n- To set up Google Cloud resources for your router appliance instance, see [Create router appliance instances](/network-connectivity/docs/network-connectivity-center/how-to/creating-router-appliances).\n- To view a list of partners whose solutions are integrated with Network Connectivity Center, see [Network Connectivity Center partners](/network-connectivity/docs/network-connectivity-center/partners).\n- To view Router appliance monitoring and logging information, see [Viewing logs and metrics](/network-connectivity/docs/network-connectivity-center/how-to/viewing-logs-metrics).\n- To find solutions for Router appliance issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshooting-ra).\n- To get details about API and `gcloud` commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
