Understanding peering ranges

This page applies to Apigee, but not to Apigee hybrid.

View Apigee Edge documentation.

Important: This topic only applies to organizations that were created with VPC peering enabled. See also Apigee networking options.

Apigee facilitates communications between client API requests and Apigee and Cloud services through a connection between two networks: the Apigee VPC (or runtime plane) and the Customer VPC. These two networks are tethered together using a private connection in a process known as VPC peering.

The following example shows how VPC peering enables communication between the Apigee VPC and the Customer VPC:

VPC peering enables the Apigee VPC to process requests and responses sent to the Customer VPC:

• Northbound traffic: API proxy requests sent from clients to the Customer VPC that are passed through to the Apigee runtime plane for processing. Additional services such as logging, identity management, and metrics are also accessible to the runtime plane.

• Southbound traffic: API proxy requests that must access target APIs or other backend services on the Customer VPC constitute the southbound route. These southbound services process the responses before returning them to the Customer VPC for further processing by the Apigee runtime before a response is sent to the client.

The Apigee provisioning step, Configure service networking, performs the VPC peering and allocates an IP Address Range (a CIDR range) to Apigee.

Network sizing

Each Apigee instance requires a non-overlapping CIDR range of /22. The Apigee runtime plane (aka data plane) is assigned IP addresses from within the CIDR range. As a result, it's important that the range is reserved for Apigee and not used by other applications in the customer VPC network.

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.

An instance is created when:

1. An Apigee organization is first provisioned, either through the UI wizard or the command-line interface (CLI).
2. When expanding Apigee to a new Cloud region for an existing organization. See also Expanding Apigee to multiple regions.

Note: You must have the role of Apigee Organization Admin or Apigee Operator to create an instance.

When you create an instance, there are two options for specifying a network IP range:

• 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.
• 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)). .

After you create an instance, you cannot change the CIDR range. To change the CIDR range, you must delete the instance and reconfigure a new one. Be careful if you have only one instance in an organization.

Considerations

Before allocating CIDR ranges, refer to Considerations in the Virtual Private Cloud documentation.

When creating a peering connection with Google, ensure that public IPs are not exchanged. To check:

1. In the Google Cloud console, go to the VPC Network Peering page. See also Using VPC Network Peering.

   Go to VPC network peering

2. Select your VPC network peering connection.
3. In the Peering connection details, make sure that Exchange subnet routes with public IP is set to None, as shown in the following screenshot.

   

   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.