En este tema, se proporciona una descripción general de la arquitectura del sistema de Apigee. Está diseñada con el fin de ayudarte a comprender qué componentes se crean durante el aprovisionamiento y su propósito en el sistema general.
Durante el aprovisionamiento, se configuran y se crean componentes que permiten la comunicación bidireccional entre una red de nube privada virtual (VPC) administrada que administras y una red de VPC administrada por Apigee.
Después de completar los primeros pasos de aprovisionamiento, las dos VPC existen, pero aún no pueden comunicarse entre sí. Se necesita más configuración para permitir la comunicación bidireccional. Consulta la Figura 1.
Figura 1: Tu VPC y la VPC de Apigee no pueden comunicarse entre ellas sin ninguna otra configuración.
Para habilitar la comunicación entre las VPC, usamos el intercambio de tráfico entre redes de VPC. El intercambio de tráfico de red permite la conectividad de direcciones IP internas entre dos redes de nube privada virtual (VPC), sin importar si pertenecen al mismo proyecto o a la misma organización de Google Cloud. Después de completar el paso de intercambio de tráfico de red, es posible la comunicación entre las dos VPC. Consulta la Figura 2.
Figura 2: El intercambio de tráfico entre redes de VPC permite la comunicación entre VPC.
Para enrutar el tráfico de las aplicaciones cliente de Internet a Apigee, usamos un balanceador de cargas de HTTPS externo (XLB). Un XLB puede comunicarse entre proyectos de Google Cloud, como entre el
proyecto de Google Cloud del cliente y el proyecto de Google Cloud de Apigee con
la referencia del servicio entre proyectos.
También puedes aprovisionar un
grupo de instancias administrado (MIG) de máquinas virtuales (VM) que funcionen como un puente de red.
Las VM de MIG tienen la capacidad de comunicarse bidireccionalmente en las redes con intercambio de tráfico. Cuando se completa el aprovisionamiento, las apps en Internet se comunican con la XLB, el XLB se comunica con la VM del puente y la VM del puente se comunica con la red de Apigee. Consulta las Figuras 3 y 4.
Figura 3: Las VM administradas permiten que las solicitudes y respuestas fluyan entre las redes con intercambio de tráfico.
En esta configuración, el tráfico se enruta desde Apigee (por ejemplo, desde la política MessageLogging) a una carga de trabajo que se ejecuta en tu VPC interna. En este caso, la comunicación a tu VPC interna no pasa por una IP de NAT de salida. En su lugar, puedes enrutar el tráfico a través de una de las IP de la instancia de Apigee.
Figura 4: El tráfico se enruta de forma privada a una carga de trabajo en tu VPC interna.
Ciclo de vida de la llamada al proxy de API
En la siguiente ilustración, se muestra el ciclo de vida de una llamada al proxy de API cuando se mueve a través de los componentes del sistema de Apigee aprovisionados (Figura 5):
Figura 5: El tráfico se enruta de forma privada a una carga de trabajo en tu VPC interna.
Una app cliente llama a un proxy de API de Apigee.
La solicitud llega a un balanceador de cargas de HTTPS externo (XLB) global L7. El XLB se configura con una IP pública y externa, y un certificado TLS.
XLB envía la solicitud a una máquina virtual (VM). La VM funciona como un puente entre tu VPC y la VPC de Google (administrada por Apigee).
La VM envía la solicitud a Apigee, que procesa la solicitud del proxy de API.
Apigee envía la solicitud al servicio de backend y la respuesta se envía al cliente.
Arquitectura con intercambio de tráfico entre VPC inhabilitado
Durante el aprovisionamiento, se configuran y se crean componentes que permiten la comunicación bidireccional entre una red de nube privada virtual (VPC) administrada que administras y una red de VPC administrada por Apigee.
Después de completar los primeros pasos de aprovisionamiento, las dos VPC existen, pero aún no pueden comunicarse entre sí. Se necesita más configuración para permitir la comunicación bidireccional. Consulta la Figura 6.
Figura 6: Tu VPC y la VPC de Apigee no pueden comunicarse entre ellas sin ninguna otra configuración.
Para habilitar la comunicación entre las VPCs, usamos
Private Service Connect
(PSC) para enrutar el tráfico ascendente a Apigee y el tráfico descendente a los servicios de destino que se ejecutan
en tus proyectos de Google Cloud.
PSC habilita la conexión privada entre un productor de servicios (Apigee) y un consumidor del servicio
(uno o más proyectos de Cloud que tú controlas). Con este método (Figura 7), las solicitudes pasan a través de
un balanceador de cargas externo global o un balanceador de cargas externo regional a un único punto
de adjunto, llamado adjunto de servicio.
Para conectar Apigee de forma privada a un destino de backend, debes crear dos entidades: un adjunto de servicio en la red de VPC en la que se implementa el destino y un adjunto de extremo en la VPC de Apigee. Estas dos entidades permiten que Apigee se conecte al servicio de destino. Consulta Patrones de herramientas de redes descendentes.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (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)."]]
