[[["わかりやすい","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-18 UTC。"],[[["\u003cp\u003eThis documentation covers the system architecture of Apigee and Apigee hybrid, focusing on the components created during provisioning and their roles.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers two provisioning options: with VPC peering, which allows communication via network peering between two VPCs, and without VPC peering, which utilizes Private Service Connect (PSC).\u003c/p\u003e\n"],["\u003cp\u003eWhen VPC peering is enabled, a managed instance group (MIG) of virtual machines (VMs) acts as a network bridge to enable bidirectional communication between the customer's VPC and Apigee's VPC, via the global external HTTPS load balancer (XLB).\u003c/p\u003e\n"],["\u003cp\u003eWhen VPC peering is disabled, Private Service Connect (PSC) facilitates private connections between Apigee and target services in other Google Cloud projects, passing requests through either a global or regional load balancer to service attachments.\u003c/p\u003e\n"],["\u003cp\u003eThe API proxy call lifecycle in a peered configuration involves a client app request landing on the XLB, then being routed through a bridge VM to Apigee for processing and then on to the backend service.\u003c/p\u003e\n"]]],[],null,["# Apigee architecture overview\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nThis topic provides an overview of the Apigee system architecture. It is intended\nto help you understand which components are created during\n[provisioning](/apigee/docs/api-platform/get-started/overview) and their\npurpose in the overall system.\n\nApigee provides two options for provisioning: [with VPC peering](/apigee/docs/api-platform/get-started/install-cli)\nand [without VPC peering](/apigee/docs/api-platform/get-started/install-cli-non-peered). Both\noptions are described in the sections that follow.\n\n- [Architecture with VPC peering enabled](#withvpcpeering)\n- [Architecture with VPC peering disabled](#withoutvpcpeering)\n\nArchitecture with VPC peering enabled\n-------------------------------------\n\nThis section describes the Apigee system architecture when Apigee is [provisioned with\nthe VPC peering option](/apigee/docs/api-platform/get-started/install-cli).\n\n### Provisioning overview\n\nDuring provisioning, components are configured and created that allow bidirectional\ncommunication between a virtual\nprivate cloud network (VPC) managed by you and a VPC network managed by Apigee.\nAfter you complete the first few provisioning steps, the two VPCs exist, but as yet\ncannot communicate back and forth. Further configuration is needed to allow bidirectional\ncommunication. See Figure 1.\n**Figure 1**: Your VPC and Apigee's VPC cannot communicate with each other without further configuration.\n\nTo enable communication between VPCs, we use\n[VPC\nnetwork peering](/vpc/docs/vpc-peering). Network peering allows internal IP address connectivity across two\nVirtual Private Cloud (VPC) networks regardless of whether they belong to the same project\nor the same Google Cloud organization. After the network peering step is completed, communication\nis possible between the two VPCs. See Figure 2.\n**Figure 2**: VPC network peering enables communication between VPCs.\n\nTo route traffic from client apps on the internet to Apigee, we use a global external HTTPS\nload balancer (XLB). An XLB can communicate across Google Cloud projects, such as between the\ncustomer Google Cloud project and the Apigee Google Cloud Project, using\n[cross-project service referencing](https://cloud.google.com/load-balancing/docs/https#cross-project).\n\n\nYou could also provision a\n[managed instance group](/compute/docs/instance-groups#managed_instance_groups) (MIG) of virtual machines (VM) that serve as a network bridge.\nThe MIG VMs have the capability to communicate bidirectionally across the peered networks. When\nprovisioning is complete, apps on the internet talk to the XLB, the XLB talks to the\nbridge VM, and the bridge VM talks to the Apigee network. See Figure 3 and Figure 4.\n**Figure 3**: Managed VMs allow requests and responses to flow between the peered networks.\n\n\nIn this configuration, traffic is routed from Apigee (for example, from the MessageLogging policy)\nto a workload running in your internal VPC. In this case, communication to your internal VPC does\nnot go through a NAT IP of the Egress. Instead, you can route the traffic through one of the\nApigee instance IPs.\n**Figure 4**: Traffic routed privately to a workload in your internal VPC.\n\n### API proxy call lifecycle\n\nThe following illustration shows the lifecycle of an API proxy call as it moves through the\nprovisioned Apigee system components (Figure 5):\n**Figure 5**: Traffic routed privately to a workload in your internal VPC.\n\n1. A client app calls an Apigee API proxy.\n2. The request lands on a global L7 external HTTPS load balancer (XLB). The XLB is configured with an external/public IP and a TLS certificate.\n3. The XLB sends the request to a virtual machine (VM). The VM serves as a bridge between your VPC and Google's VPC (managed by Apigee). **Note:** The XLB is not capable of communicating across the peered networks. A VM, on the other hand, can be configured to talk to Apigee across the peered network. That is why we provision a [managed instance group](/compute/docs/instance-groups#managed_instance_groups) (MIG) of VMs to function as a network bridge.\n4. The VM sends the request to Apigee, which processes the API proxy request.\n5. Apigee sends the request to the backend service, and the response is sent back to the client.\n\nArchitecture with VPC peering disabled\n--------------------------------------\n\nThis section describes the Apigee system architecture when Apigee is [not provisioned with\nthe VPC peering option](/apigee/docs/api-platform/get-started/install-cli-non-peered).\n\nDuring provisioning, components are configured and created that allow bidirectional\ncommunication between a virtual\nprivate cloud network (VPC) managed by you and a VPC network managed by Apigee.\nAfter you complete the first few provisioning steps, the two VPCs exist, but as yet\ncannot communicate back and forth. Further configuration is needed to allow bidirectional\ncommunication. See Figure 6.\n**Figure 6**: Your VPC and Apigee's VPC cannot communicate with each other without further configuration.\n\nTo enable communication between VPCs, we use\n[Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect)\n(PSC) for routing northbound traffic to Apigee and southbound traffic to target services running\nin your Google Cloud projects.\n\n\nPSC enables private connection between a service producer (Apigee) and a service consumer\n(one or more other Cloud projects that you control). With this method (Figure 7), requests pass through\neither a global external load balancer or a regional external load balancer to a single point\nof attachment, called a [service attachment](/vpc/docs/private-service-connect#service-attachments).\n\nTo privately connect Apigee to a backend target, you must create two entities: a\n[service attachment](/vpc/docs/private-service-connect#service-attachments)\nin the VPC network where the target is deployed and an [endpoint attachment](/apigee/docs/reference/apis/apigee/rest/v1/organizations.endpointAttachments/create) in the Apigee VPC. These\ntwo entities allow Apigee to connect to the target service. See [Southbound networking patterns](/apigee/docs/api-platform/architecture/southbound-networking-patterns-endpoints).\n\n\nThe steps for provisioning Apigee with PSC (without VPC peering) are described in\n[Command line provisioning without VPC peering](/apigee/docs/api-platform/get-started/install-cli-non-peered).\n\n\n**Figure 7.** Apigee architecture without VPC peering. For details of this architecture, see [Apigee architecture overview](/apigee/docs/api-platform/architecture/overview)."]]
