--- title: "vDiscovery on AWS VPCs" canonical: "https://docs.infoblox.com/space/NAIG/37650904/vDiscovery%20on%20AWS%20VPCs" format: markdown --- A vDiscovery job retrieves information about virtual entities in cloud environments that are managed through a cloud management platform (CMP) such as AWS. The current vDiscovery feature supports tenants, networks, and compute VMs only. It does not support data that is retrieved from load balancer networks, load balancer VMs, Kubernetes platform VMs, application gateways, service VMs, SQL VMs, or any other VMs that are created by cloud services such as Kubernetes service or analytics service, where the IPAM is handled by the respective orchestration engines of the cloud provider. If the vDiscovery job retrieves unsupported data from AWS, then it impacts the performance of the vDiscovery process. You can configure a vDiscovery job to discover data from a single AWS account or, starting from NIOS 9.0.4, from multiple accounts in an AWS organization. # Prerequisites Before you configure a vDiscovery job to discover and synchronize data, complete the following prerequisites: - In the AWS Management Console: - According to the type of authentication that you intend to use, create an instance profile or IAM credentials required to authenticate the connection between NIOS and AWS. For more information, see the *Credentials for vDiscovery* section. - For multi-account vDiscovery, set up the AWS organization and keep the role ARN (Amazon Resource Name) of the AWS Management account handy. For more information, see *[Setting up the AWS Environment for Multi-Account Synchronization](https://infoblox-docs.atlassian.net/wiki/spaces/NAIG/pages/277742797)*. - In Infoblox NIOS: - Configure a DNS resolver. For more information, see the *Configuring a DNS Resolver* section. - Only for NIOS version 9.0.4 and later: Ensure that the Cloud Sync service is running on the Grid member that performs the vDiscovery job. For more information, see the *[Starting and Stopping the Cloud Sync Service](https://infoblox-docs.atlassian.net/wiki/spaces/NAIG/pages/277546012)* section. - For the vDiscovery synchronization to function properly, ensure that your network firewall settings permit access to the below mentioned global STS endpoint and the regional STS endpoints specific to your region. This is crucial for establishing a connectivity between the NIOS appliance and your configured AWS accounts. For other regional endpoints, see the *[AWS STS Regions and endpoints](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)* page. In the list, replace with your AWS region. If you have deployed resources in multiple regions, make sure that all regional endpoints are accessible. - ec2..amazonaws.com (primary endpoint for EC2 discovery operations) - sts.amazonaws.com (global STS endpoint for authentication) - sts..amazonaws.com (regional STS endpoints for authentication) - ip-ranges.amazonaws.com (required for fetching AWS public IP ranges) - organizations..amazonaws.com (required for account discovery) - http://aws.amazon.com/ (general AWS endpoint access) ## Credentials for vDiscovery When you configure a vDiscovery job through the Infoblox GUI (Grid Manager) as explained in the *Configuring vDiscovery Jobs* topic in the *[Infoblox NIOS Documentation](https://docs.infoblox.com/space/NIOS/35400616/NIOS)**.*, you can choose to use **Instance ** **Profile** or **IAM** ** Credential** for authentication. An instance profile is a container for an IAM role that you use to pass the role information to an EC2 instance when the instance is up and running. Select this option if you want to collect information from AWS by waiving a user's credentials and using configuration of a predefined IAM role to get a temporary token that allows API calls. Note that you must first configure the option for "instance profile" in AWS, define an IAM role in the instance profile, and then set permissions for this role before you can select this option in NIOS. Otherwise, this option is disabled. When you select this option, you do not need to provide user credentials for vDiscovery jobs. You can also select IAM credentials if you want to authenticate by using IAM roles to grant secure access to AWS resources from your EC2 instances when they are up and running. When you select this authentication method, you must provide the Access Key ID and Secret Access Key for the AWS endpoint. This is the secret key pair for the administrator account that executes the vDiscovery job. > ⚠️ **Note** > ⚠️ > ⚠️ In AWS, access keys are used to digitally sign API calls made to AWS services. Each access key credential is comprised of an access key ID and a secret key. The secret key portion must be secured by the AWS account holder or the IAM user to whom they are assigned. As a best practice, users should rotate their access keys on a regular basis. Refer to the document *AWS* *Security Best Practices* by Amazon Web Services ([http://aws.amazon.com/whitepapers/aws-security-best-practices/](http://aws.amazon.com/whitepapers/aws-security-best-practices/)) and the AWS Documentation page IAM Best Practices ([http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html](http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) ) for more information. Before assignment to the NIOS cloud admin account, AWS users need the following AWS IAM permissions to use the vDiscovery feature to discover the resources in their VPCs and manage them through IPAM: - `iam:GetUser ` - `ec2:DescribeVpcs ` - `ec2:DescribeSubnets ` - `ec2:DescribeRouteTables ` - `ec2:DescribeAddresses` - `ec2:DescribeNetworkInterfaces ` - `ec2:DescribeInstances` For more information about how to configure vDiscovery, refer to *[Configuring vDiscovery Jobs](https://infoblox-docs.atlassian.net/wiki/spaces/nios90/pages/704348239)* in the *[Infoblox NIOS Documentation](https://docs.infoblox.com/space/NIOS/35400616/NIOS)**.* ## Configuring a DNS Resolver For the NIOS vDiscovery feature to work on AWS VPCs with the Infoblox vNIOS for AWS instance on public or private subnets, configure the DNS Resolver setting in the *Grid* *Properties* editor in NIOS to add the IP address of the upstream DNS server within AWS. The DNS server must resolve both the user-provided AWS service endpoint and the host name iam.amazonaws.com to the NIOS configuration. To configure a DNS resolver for the Grid, complete the following in Grid Manager: 1. From the **Grid** tab -> **Grid** **Manager** tab -> **Members** tab, expand the Toolbar, and then click **Grid** **Properties**. 2. In the *Grid Properties* editor, complete the following: - Click the **DNS** **Resolver** tab and select the **Enable** **DNS** **Resolver** checkbox if it is not already selected. - In the **Name** **Servers** list, click **Add** to add the IP address of the upstream DNS server to the list. - Enter the IP address and press **ENTER**. 3. Save the configuration. The changes may take a brief period of time to become active. The following figures illustrate AWS cloud-based and on-premises-based appliances communicating with the AWS endpoints to initiate vDiscovery for their VPCs: * Infoblox vNIOS for AWS Appliance Routing to Endpoints for vDiscovery Tasks* ![1.10.drawio.png](media://9637ee50-57e8-4fb3-9033-90be07591404) > Macro (excerpt) > > > Macro (drawio) By adding the DNS resolver, communication by the Infoblox vNIOS for AWS appliance to the endpoints is automatic for vDiscovery. The following diagram illustrates the same process for an on-premises NIOS Cloud Platform appliance: *On-Premises NIOS Appliance Configured for vDiscovery Tasks* ![On-Premises NIOS Appliance Configured for vDiscovery Tasks.png](media://277e5f6d-198b-4572-b47a-c1c3ab2a249f) > Macro (excerpt) > > > Macro (drawio) > ⚠️ **Note** > ⚠️ > ⚠️ Network routing may also be required to enable the member to communicate with the AWS endpoints. You can also set up a proxy server in your data center so that you can perform vDiscovery through the proxy server. For information about how to configure a proxy server on your NIOS virtual appliance, refer to the *Infoblox NIOS Documentation*. ## Starting and Stopping the Cloud Sync Service In NIOS 9.0.4 and later, to execute a vDiscovery job configured on a Grid member in Infoblox NIOS, the Cloud Sync service must be running on the Grid member. If the member is not assigned with any existing vDiscovery jobs, the service is automatically enabled when you create a vDiscovery job on the member. > Macro (excerpt-include) # Objects Discovered and Collected by vDiscovery A number of different network object types are discovered, collected and added to the NIOS database during the vDiscovery process. You may convert some object types to Managed objects in NIOS IPAM. - Virtual Private Clouds - Availability Zone - Tenants - Subnets - EC2 Instances (virtual machines); - IP Addresses > ⚠️ **Note** > ⚠️ > ⚠️ vDiscovery is not supported for Elastic IP addresses allocated from a public IP address pool that you have brought to your AWS account, or from a private pool created from your on-premises network (Bring your own IP address). It is supported only if Elastic IP addresses are allocated from Amazon's pool of public IPv4 addresses. # Creating DNS Records for Discovered IP Addresses When you configure vDiscovery jobs, you can enable the appliance to automatically create DNS records for discovered virtual instances in your AWS VPCs. When you enable this feature, NIOS automatically adds Host records or A and PTR records to the authoritative zones for the discovered IP addresses based on your configuration. You can also enter a formula that NIOS uses to create the DNS names for the discovered IP addresses based on their VM parameters such as vm_name or discovered_name for data discovered through AWS. By doing so, NIOS is able to discover public and private IP addresses by looking up the corresponding DNS names. Discovered data includes IP addresses for the VMs and associated information such as VM ID, VM Name, Tenant ID, and others. Note that corresponding zones must already exist in order for NIOS to add DNS records. Otherwise, NIOS does not add any DNS records and it logs a message to the syslog. NIOS automatically adds DNS records based on the following conditions: - The corresponding DNS zones must already exist in the NIOS database. NIOS does not automatically create DNS zones for the records. - To create a PTR record, the corresponding reverse-mapping zone must exist. - A DNS zone cannot be associated with more than one DNS view. NIOS does not create DNS records for zones that are associated with multiple DNS views. - NIOS adds new DNS records only if the VM name for the discovered IP address is available and there is no conflict between the discovered data and the associated network view. The following matrix captures some scenarios about how vDiscovery handles various actions and what the outcome is for the information on the Cloud Platform appliance and in the NIOS database. > ⚠️ **Note** > ⚠️ > ⚠️ vDiscovery modifies records that are created by the vDiscovery process only. It does not create or update DNS records that are originally created by other admin users. | **Actions** **and** **Conditions** | **Cloud** **Platform** **Data** **before** **vDiscovery** | **Cloud** **Platform** **Data** **after** **vDiscovery** | **NIOS** **Data** **before** **vDiscovery** | **NIOS** **Data** **after** **vDiscovery** | | --- | --- | --- | --- | --- | | - Add new interface to existing VM (vma) with the same discovered name on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | | - Add new interface to existing VM (vma) with different discovered name (vmb) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vma.corp1.com 10.10.10.2 vmb.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: vmb.corp1.com (10.10.10.2) | | - Add new interface to existing VM (vma) with different discovered name (vmb) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vma.corp1.com 10.10.10.2 vmb.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: vmb.corp1.com (10.10.10.2) | | - Remove existing VM (vma) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com | No data for vma | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com | | - Remove existing VM (vma) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com | No data for vma | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | | - Remove existing interface (10.10.10.2) from VM (vma) with different discovered name (vmb) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com 10.10.10.2 vmb.corp1.com | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: vmb.corp1.com (10.10.10.2) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | | - Remove existing interface (10.10.10.2) from VM (vma) with different discovered name (vmb) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com 10.10.10.2 vmb.corp1.com | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: vmb.corp1.com (10.10.10.2) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: vmb.corp1.com (10.10.10.2) | | - Update record name (from vma to vm1) for the existing interface (10.10.10.1) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vm1.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vm1.corp1.com (10.10.10.1) | | - Update record name (from vma to vm1) for the existing interface (10.10.10.1) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vm1.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: vm1.corp1.com (10.10.10.1) | | - Automatic creation of Host records - Change FQDN template from ${discover_name) to ${vm_name} - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com vm_name: ABC | 10.10.10.1 vm1.corp1.com vm_name: ABC | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: ABC.corp1.com (10.10.10.1) | | - Automatic creation of Host records - Change FQDN template from ${discover_name) to ${vm_name} - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com vm_name: ABC | 10.10.10.1 vm1.corp1.com vm_name: ABC | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **Host** **record**: ABC.corp1.com (10.10.10.1) | | - Change vDiscovery task configuration from creation of Host record to A and PTR records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **A** **record**: vma.corp1.com (10.10.10.1) | | - Change vDiscovery task configuration from creation of Host record to A and PTR records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *admin*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) **A** **record**: vma.corp1.com (10.10.10.1) | | - Add new VM (vma) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; no DNS records | No data for vma | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | | - Add new VM (vma) on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery* *or* *admin*) | No data for vma | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | | - Add new interface to existing VM (vma) with the same discovered name on Cloud Platform appliance - Automatic creation of Host records - **In** **NIOS**: existing zone corp1.com; existing Host record (*originally* *created* *by* *vDiscovery*) | 10.10.10.1 vma.corp1.com | 10.10.10.1 vma.corp1.com | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1) | **Zone**: corp1.com **Host** **record**: vma.corp1.com (10.10.10.1, 10.10.10.2) | To enable the appliance to automatically create DNS records, complete the following in Grid Manager: 1. For a new vDiscovery job: From the **Data** **Management** tab, select the **IPAM** tab, then select **vDiscovery** -> **New** from the Toolbar; or from the **Cloud** tab, select **vDiscovery** -> **New** from the Toolbar. or To modify an existing job: From the **Data** **Management** tab, select the **IPAM** tab and click **vDiscovery** -> **Discovery** **Manager** from the Toolbar, or from the **Cloud** tab, select **vDiscovery** -> **Discovery** **Manager** from the Toolbar. In the **vDiscovery** **Job** **Manager** editor, click the Action icon next to a selected job and select **Edit** from the menu. 2. In step four of the v*Discovery* *Job* wizard, or on the **Data** **Consolidation** tab of the *vDiscovery* *Job* *Properties* editor, complete the following: **For** **every** **newly** **discovered** **IP** **address,** **create**: Select this checkbox to enable NIOS to automatically create or update DNS records for discovered VM instances if the records were originally created by vDiscovery. - **Host**: Select this to automatically create Host records for discovered VMs. - **A** **&** **PTR** **Record**: Select this to automatically create A and PTR records for discovered VMs. Note that the DNS zones and reverse-mapping zones to which the records belong must exist in NIOS. Otherwise, vDiscovery does not create the records. - **The** **DNS** **name** **will** **be** **computed** **from** **the** **formula**: Enter the formula that NIOS uses to create FQDNs for discovered VMs. You can use the auto-generated FQDNs for DNS resolution purposes. You must use the syntax of ${**parameter** **name**} for this formula. For AWS, this field supports the **vm_name** and **discovered_name** parameters. For example, when you enter **${vm_name}.corp100.com** and the discovered vm_name = XYZ, the DNS name for this IP becomes **XYZ.corp100.com**. When you enter** ${discover_name}** here and the discovered name for the IP is** ip-172-31-1-64.us-west-1.compute.internal**, the DNS name for this IP is  **ip-172-31-1-64.us-west-1.compute.internal**. Note that if the **${vm_name}** parameter of an instance contains any special character, the appliance will not be able to identify this instance and will convert it to a managed VM using the **vm_id** parameter.