Shared-Services VPC Deployments

Amazon Web Services supports peering of virtual private clouds. Users can dedicate VPCs to specific purposes, such as shared services in one VPC, and business workloads in other VPCs. AWS transparently routes network traffic between them and allows separate (but not overlapping) address spaces for each. The following figure illustrates Infoblox vNIOS for AWS support for multiple VPCs through AWS VPC peering.

Infoblox vNIOS for AWS Hybrid deployment, Shared-Service VPC

Characteristics of this deployment include the following:

• Organizations may use numerous VPCs in their AWS deployments, with business workload instances populating some VPCs and shared services populating a central hub VPC;

• Extension of the on-premises NIOS Grid to the organization's Amazon VPC;

• One or more Infoblox vNIOS for AWS instances in the AWS VPC, to perform vDiscovery and management of business assets and networks;

• Regular synchronization of data from the Infoblox vNIOS for AWS instance to the on-premises Grid Master;

• Appliances providing the primary DNS and secondary DNS may be located in the on-premises network or in the VPC; DNS setup depends entirely on how the user deployment operates, without restrictions;

• All discovered Cloud objects can be managed objects in NIOS IPAM;

• You can provision the Infoblox vNIOS for AWS instance with the Elastic Scale feature, or manually configure with licenses and Grid settings;

• Using the Cloud Platform license, the Infoblox vNIOS for AWS instance can operate as the API Proxy to the AWS API;

• Grid members in the on-premises network can manage VMware or OpenStack private clouds while the Infoblox vNIOS for AWS grid member manages the AWS VPC;

• Grid members in the VPC can survive locally if the connection to the Grid Master goes down, and continue to run vDiscovery tasks. It re-synchronizes with the Grid Master when the connection is restored;

• The organization's DNS namespace can extend to all objects in the VPC.

• You do not need to deploy Infoblox vNIOS for AWS instances in every VPC involved in a peering arrangement. The number and placement of Infoblox vNIOS for AWS instances should be based upon expected network object counts and expected volume of DNS query traffic in the peering VPCs;

• All peered VPCs must be fully contained in the same AWS region;

• A Infoblox vNIOS for AWS instance in the Shared Services VPC can run vDiscovery across the peering VPCs.
  It collects their data as a single Network View in NIOS;

• The Infoblox vNIOS for AWS instance can operate as the AWS API Proxy. It enables API access to all entities in each of the peered VPCs for which it is authoritative;

• Management of the peering VPC networks is performed through the same Amazon regional endpoint, because all VPCs are contained within the same AWS region;

• The CIDR blocks for each peered VPC are not allowed to have overlapping address spaces between one another;

• Changes to any business workflow instance in the peering VPCs are discovered by the Infoblox vNIOS for AWS instance during the next scheduled vDiscovery. Infoblox vNIOS for AWS then re-synchronizes with the Grid Master.