An AWS VPC automatically maps to a network view under NIOS. The main AWS subnet comprising the complete collection of IP addresses for the AWS VPC is automatically mapped to a NIOS network container. No subnets in the network container are allowed to have overlapping IPs or subnets.
Different AWS VPCs can contain overlapping IP address spaces as they are logically isolated from each other in AWS.

Subnet CIDR Guidelines

AWS places limits on how you can structure subnets within a VPC. All subnets within each AWS VPC are in a flat hierarchy, where you cannot define new subnetworks beyond the first level of subnets defined in the VPC. AWS does not provide for a containment hierarchy within subnets.

Figure 1.12 Subdividing VPCs into Subnets in IPAM

In IPAM, any subnet in an AWS address space can be treated as a network container or simply as a network.
22544426 shows two subnets that appear as subordinate network containers to the top-level container, which represents the actual VPC. Though the subnets can appear as containers, no smaller subnets can be created within them. For AWS, functionality as a subnet is exactly the same. Carefully consider the size of the subnets in your AWS virtual private cloud, because you cannot define subnets that are subordinate to those at the top level.

NIOS-AWS Subnet Size Restrictions

AWS allows you to create a subnet in your VPC that uses the same CIDR prefix and mask as for the host VPC, and add new instances to it. For example, consider a VPC prefix 10.0.0.0/16. In AWS, an administrator is allowed to create a subnet with the same prefix 10.0.0.0/16 and to run service instances within it. NIOS does not allow subnets in an AWS VPC that use the same prefix and mask as the VPC network container, and does not discover or recognize resources within that prefix. You will also not be able to create new objects in that subnet. Ensure that all VPCs to be managed or discovered through Grid Manager only use subnets with CIDR mask values that are smaller than the CIDR denoting the VPC. For example, the host VPC has a CIDR mask of /16, and the largest subnet has a mask of /18.

NTP and Hybrid Cloud Synchronization

Ensure that all appliances in a hybrid Grid configuration (for example, an on-premises Grid Master with cloud-based Grid members) are correctly time synchronized. If the Grid Master is not time-correct with all cloud-based Grid members, you will receive AWS authentication errors when attempting to issue directives through the API Proxy.

Using an Elastic IP Address

You may use either an AWS Elastic IP Address or a private IP address, associated with LAN1 on the vNIOS instance, to access the Infoblox vNIOS for AWS instance. (AWS automatically associates the LAN1 port on the vNIOS instance with the eth1 interface on the VM.) VPN access or an AWS Elastic IP is required for access to Infoblox vNIOS for AWS instances. Using an SSH terminal program such as PuTTY, you connect to the LAN1 IP address for CLI access to the instance.

If your VPC does not use a VPN connection (instead, for example, using the AWS Direct Connect service), you can assign an AWS Elastic IP address to the eth1 port of your Infoblox vNIOS for AWS instance. You do so through the AWS console. Elastic IP addresses are created and associated with your AWS account and can be allocated and re-allocated to different instances as needed.

When using an Elastic IP, the Security Group rules must permit only the IP addresses or prefixes to be allowed to access the virtual appliance. When you associate an Elastic IP address with an instance, AWS also lists it as a Public IP address for the instance. Additional security group settings may be required.
To set an Elastic IP address for your Infoblox vNIOS for AWS instance, do the following:

1. Log in to AWS.
2. In the main AWS Console page, click EC2. The EC2 Dashboard page opens.
3. Click Network & Security -> Elastic IPs.
   1. To create a new Elastic IP address, click Allocate New Address. A prompt requests confirmation of creation of the new Elastic IP. Click Yes, Allocate.
      –or–
      To associate an existing Elastic IP address with your Infoblox vNIOS for AWS instance, right-click an Elastic IP address entry in the table and choose Associate Address.
   2. From the Instance drop-down list, select the Infoblox vNIOS for AWS instance.
   3. Select the Private IP Address associated with the eth1 port on your Infoblox vNIOS for AWS instance.
   4. Click Associate. The Elastic IP address is associated with the selected instance and private IP. You can now begin accessing the instance through the newly associated IP address. (The Reassociation checkbox allows you to override an existing Elastic IP association and force the currently selected Elastic IP to be associated with your currently selected instance. Use this feature with caution.)

NIOS Treatment of AWS Public IP Addresses and Elastic IP Addresses

AWS Public IP addresses originate from Amazon's Public IP address pool. Infoblox vNIOS for AWS instances in the AWS cloud do not manage these public IP addresses, and you do not use NIOS IPAM functionality for them. The Infoblox appliance stores the relationships between private and public IP addresses and enables public IP addresses to be used for creation of DNS records.
NIOS stores AWS public IP addresses as Host records with addresses that do not belong to any IPAM network. These are mapped to a DNS zone that is common for multiple NIOS Cloud Platform members. This DNS zone must reside in a non-delegated network view (not managed by any specific Cloud Platform appliance) and the zone uses all associated Cloud Platform members as Grid primaries that are expected to create host records in this zone.
NIOS treats Elastic IP addresses in the same way. NIOS stores Elastic IPs as Host records without relationship to any IPAM network, and they are not managed under NIOS IPAM.

Common Guidelines for Infoblox vNIOS for AWS Usage

General guidelines for use of Infoblox vNIOS for AWS instances in AWS include the following:

• Where is your deployment? You need to know the Amazon Regions, VPCs and Subnets in which you deploy your Infoblox vNIOS for AWS instances, and which of these VPCs and Subnets you delegate to Infoblox vNIOS for AWS instances for management.
• Who will configure and manage the deployment? Amazon IAM (Identity and Access Management) configurations in your VPC should be configured correctly to work with Infoblox vNIOS for AWS. Your AWS accounts need the correct IAM permissions for cloud object configuration, discovery, and feature configuration. Infoblox vNIOS for AWS requires use of AWS IAM administrative accounts for full Amazon virtual private cloud integration with the Infoblox Grid. For details, see Credentials for vDiscovery and Assigning AWS User Credentials to the NIOS Cloud Admin Account.
• How will you secure your deployment? Network connections to your Infoblox vNIOS for AWS instances should be further locked down using the AWS Security Groups feature, to allow access only from the specific network addresses involved in your deployment.
• Where will your Infoblox AWS API Proxy be located? If you intend to use an Infoblox vNIOS for AWS instance as an AWS API Proxy for management of the Grid in the AWS cloud, ensure that your instance acting as the API Proxy will be reachable through the connection to the Amazon VPC.
• In large deployments, placement of Infoblox vNIOS for AWS instances can depend on the number of DNS queries and business workloads prevailing in each VPC. VPCs with relatively small amounts of DNS query traffic, or with services that do not produce heavy traffic flows, can be managed through an Infoblox vNIOS for AWS instance in a peering VPC. The managing instance, however, may have larger memory and storage requirements based on the scale of the networks for which it is expected to be authoritative.
• Schedule vDiscovery tasks for non-peak time periods when workflow demand is not as heavy.