Apigee는 Apigee VPC(또는 런타임 영역)와 고객 VPC 간의 연결을 통해 클라이언트 API 요청, Apigee, Cloud 서비스 간의 통신을 지원합니다. 이 두 네트워크는 VPC 피어링이라는 프로세스에서 비공개 연결을 통해 함께 테더링됩니다.
다음 예시에서는 VPC 피어링에서 Apigee VPC와 고객 VPC 간의 통신을 사용 설정하는 방법을 보여줍니다.
VPC 피어링을 사용하면 Apigee VPC에서 고객 VPC로 전송된 요청과 응답을 처리할 수 있습니다.
Northbound 트래픽: 클라이언트에서 고객 VPC로 전송되는 API 프록시 요청이며 처리를 위해 Apigee 런타임 영역으로 전달됩니다. 로깅, ID 관리, 측정항목 등의 추가 서비스도 런타임에 액세스할 수 있습니다.
Southbound 트래픽: 고객 VPC의 대상 API 또는 기타 백엔드 서비스에 액세스해야 하는 API 프록시 요청은 Southbound 경로를 구성합니다. 이러한 Southbound 서비스는 응답이 클라이언트에 전송되기 전에 응답을 처리하여 Apigee 런타임에서 추가 처리를 위해 고객 VPC로 응답을 반환합니다.
Apigee 프로비저닝 단계인 서비스 네트워킹 구성은 VPC 피어링을 수행하고 IP 주소 범위(CIDR 범위)를 Apigee에 할당합니다.
네트워크 크기 조정
각 Apigee 인스턴스에는 겹치지 않는 /22 CIDR 범위가 필요합니다. Apigee 런타임 영역(데이터 영역이라고도 함)에는 CIDR 범위 내에 있는 IP 주소가 할당됩니다.
따라서 이 범위는 Apigee에 예약되어야 하며 고객 VPC 네트워크의 다른 애플리케이션에서 사용하면 안 됩니다.
범위 자동 할당 - Apigee 인스턴스를 만들 때 Apigee가 Google에 할당된 더 큰 범위에서 사용 가능하고 겹치지 않는 범위를 할당하도록 허용합니다.
인스턴스를 다시 만들 때마다 IP 범위가 자동 할당됩니다. 이러한 경우 새 IP 범위를 사용할 수 있고 다른 제품 또는 서비스와 겹치지 않는 경우 이러한 새 IP 범위가 새 인스턴스에 사용될 수 있습니다.
IP 범위 지정 - Apigee에 사용되는 IP 범위를 지정할 수 있습니다. 이 IP 범위는 Apigee와 쌍으로 연결되는 겹치지 않는 범위여야 합니다. 이 옵션은 Cloud SQL, Cloud Memorystore, Apigee 등과 같이 여러 클라우드 제품에 대해 더 큰 IP 범위를 할당하려고 할 때 그리고 이러한 각 제품에 대해 실제 IP 범위를 지정하려고 할 때 유용합니다. 이 범위는 비공개로 사용되는 공개 IP 주소(PUPI)가 아닌 한 비RFC 1918 IP 범위일 수 있습니다.
.
인스턴스를 만든 후에는 CIDR 범위를 변경할 수 없습니다. CIDR 범위를 변경하려면 인스턴스를 삭제하고 새 인스턴스를 다시 구성해야 합니다. 조직에 인스턴스가 하나만 있으면 주의해야 합니다.
고려사항
CIDR 범위를 할당하기 전 Virtual Private Cloud 문서의 고려사항을 참조하세요.
Google과 피어링 연결을 만들 때 공개 IP가 교환되지 않는지 확인합니다. 확인하려면 다음 안내를 따르세요.
Google Cloud 콘솔에서 VPC 네트워크 피어링 페이지로 이동합니다.
또한 VPC 네트워크 피어링 사용을 참조하세요.
[[["이해하기 쉬움","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-08-19(UTC)"],[[["\u003cp\u003eThis content focuses on Apigee (not Apigee hybrid) and its network connectivity through VPC peering, which links the Apigee runtime plane and Customer VPC.\u003c/p\u003e\n"],["\u003cp\u003eVPC peering facilitates both northbound (client to Apigee) and southbound (Apigee to backend services) traffic flow between the Apigee VPC and the Customer VPC.\u003c/p\u003e\n"],["\u003cp\u003eEach Apigee instance requires a unique /22 CIDR range for its runtime plane, along with an additional non-overlapping /28 CIDR range for troubleshooting access.\u003c/p\u003e\n"],["\u003cp\u003eWhen creating an instance, you can either let Apigee auto-allocate the IP range or specify a custom, non-overlapping range, but this range cannot be modified after the instance is created.\u003c/p\u003e\n"],["\u003cp\u003eIt is crucial to ensure that public IPs are not exchanged when creating a peering connection with Google to avoid potential IP conflicts, as Apigee uses privately used public IP addresses (PUPI).\u003c/p\u003e\n"]]],[],null,["# Understanding peering ranges\n\n*This page\napplies to **Apigee** , but not to **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Important:** This topic only applies to organizations that were created with VPC peering enabled. See also [Apigee networking options](/apigee/docs/api-platform/get-started/networking-options).\n\nApigee facilitates communications between client API requests and Apigee and Cloud services\nthrough a connection between two networks: the Apigee (or *runtime plane* ) and the\nCustomer VPC. These two networks are tethered together using\n[a private connection](/vpc/docs/configure-private-services-access) in a process known\nas *VPC peering*.\n\nThe following example shows how VPC peering enables communication between the Apigee VPC and the\nCustomer VPC:\n\nVPC peering enables the Apigee VPC to process requests and responses sent to the Customer\nVPC:\n\n- **Northbound traffic:** API proxy requests sent from clients to the Customer VPC that are\n passed through to the Apigee runtime plane for processing. Additional services such as logging,\n identity management, and metrics are also accessible to the runtime plane.\n\n- **Southbound traffic:** API proxy requests that must access target APIs or other\n backend services on the Customer VPC constitute the southbound route. These southbound services\n process the responses before returning them\n to the Customer VPC for further processing by the Apigee runtime before a response is sent to the\n client.\n\n\nThe Apigee provisioning step, [Configure service networking](/apigee/docs/api-platform/get-started/install-cli#service-networking), performs the\nVPC peering and allocates an IP Address Range (a CIDR range) to Apigee.\n\nNetwork sizing\n--------------\n\nEach [Apigee instance](/apigee/docs/api-platform/system-administration/instances) requires a non-overlapping CIDR range of /22. The Apigee\nruntime plane (aka data plane) is assigned IP addresses from within the CIDR range.\nAs a result, it's important that the range is reserved for Apigee and not used by other\napplications in the customer VPC network.\n| **Note:** In addition to the /22 range that is created, Apigee requires a non-overlapping, available /28 CIDR range. This /28 range is used by Apigee to access the instance for troubleshooting purposes and cannot be customized or changed. See also [Creating instances](/apigee/docs/api-platform/system-administration/instances).\n\n\nAn instance is created when:\n\n1. An Apigee organization is first provisioned, either through the [UI wizard](/apigee/docs/api-platform/get-started/overview) or the [command-line interface](/apigee/docs/api-platform/get-started/install-cli) (CLI).\n2. When expanding Apigee to a new Cloud region for an existing organization. See also [Expanding Apigee to multiple regions](/apigee/docs/api-platform/system-administration/multi-region).\n\n| **Note:**You must have the role of Apigee Organization Admin or Apigee Operator to create an instance.\n\n\nWhen you create an instance, there are two options for specifying a network IP range:\n\n- **Auto-allocate the range** - When you create an Apigee instance, allow Apigee to allocate any available, non-overlapping range from the larger range allocated to Google. Each time an instance is re-created, the IP range is auto-allocated. In such cases, it is possible that the new instance may use a new IP range, if one is available and is non-overlapping with other products or services.\n- **Specify an IP range** - You can specify the IP range that Apigee will use. This IP range must be from the non-overlapping range that is peered with Apigee. This option is useful when you want to allocate a larger IP range for multiple Cloud products, such as Cloud SQL, Cloud Memorystore, Apigee, and others, and you also want to be able to specify actual IP ranges for each of these products. This range could be a non-RFC 1918 IP range as long as the range is not a privately used public IP address (PUPI)). .\n\n\nAfter you create an instance, you *cannot* change the CIDR range. To change the CIDR range,\nyou must delete the instance and reconfigure a new one. Be careful if you have only one\ninstance in an organization.\n\nConsiderations\n--------------\n\n\nBefore allocating CIDR ranges, refer to\n[Considerations](https://cloud.google.com/vpc/docs/configure-private-services-access#considerations) in the Virtual Private Cloud documentation.\n\n\nWhen creating a peering connection with Google, ensure that public IPs are not\nexchanged. To check:\n\n1. In the Google Cloud console, go to the **VPC Network Peering** page. See also [Using VPC Network Peering](https://cloud.google.com/vpc/docs/using-vpc-peering#console_1).\n\n [Go to VPC network peering](https://console.cloud.google.com/networking/peering/list?_ga=2.60789677.1018243021.1642011235-1753111617.1642011235)\n2. Select your VPC network peering connection.\n3. In the Peering connection details, make sure that **Exchange subnet routes with public IP** is set to **None** , as shown in the following screenshot.\n\n | **Note:** Apigee uses *privately used public IP* (PUPI) addresses, so setting **Exchange subnet routes with public IP** to something other than **None** could potentially cause an IP conflict.\n\n*[VPC]: Virtual Private Cloud"]]
