Enterprise IT needs visibility into the network and security status of their workloads, whether hosted on premises, or within AWS. While many AWS workloads are sandboxes for application development teams (DevOps), it is important to analyze these workloads. Increasingly, public cloud workloads are also fulfilling mission critical production needs for many organizations. Enterprise IT must be ready to determine the best location, security posture, and bandwidth allocation when deploying workloads. Having traffic pattern details as well as security analysis and recommendations readily available, helps organizations make the ideal hosting decisions to meet their business needs.
With the release of vRealize Network Insight (vRNI) 3.4 Enterprise Edition, Amazon Web Services (AWS) Public Cloud Support is now available. The vRNI traffic monitoring features provide visibility into native AWS constructs such as Virtual Private Clouds, VMs, Security Groups, firewall rules, and tags. vRNI also analyzes AWS traffic flows to provide security and micro-segmentation views of cloud workloads. This means you’ll be able to plan micro-segmentation and understand traffic patterns using data collected from your AWS instances. In this article, I’ll show you how to configure AWS as a datasource, then walk through how to leverage the new AWS entities within vRNI.
The first step is to to enable AWS VPC Flow Logs so we can collect flows from AWS. Here’s further information on enabling and using VPC Flow Logs. Be sure to check with AWS to determine what additional costs there might be, if any, for your environment before enabling VPC Flow Logs. vRNI 3.4 also requires an on premises Proxy server to collect AWS data. You will need your AWS Access Key ID and Secret Access Key to add the data source. Click the Enable Flow data collection checkbox to leverage captured VPC Flow Logs. Once you click Submit, the datasource is added. As you can see, adding AWS as a datasource is very straightforward.
Once the datasource is configured, we will begin collecting flow and entity details from AWS. The first place to look is Plan Security, new options will be available for micro-segmentation analysis. Click the Analyze Flows dropdown to choose a scope for planning. Notice VPC is listed, but we can also choose other options such as Security Groups or Tag. Security Groups in AWS perform a similar function to NSX security groups. If we don’t want to include NSX security groups while planning, the Analyze Flows and group-by options can filter those entities out of the equation. Likewise, tags could include the new vSphere tags option in 3.4 or AWS VM tags. Choosing the relevant scope in the interface will allow you to differentiate between tag types.
In addition to the micro-segmentation planning view, you can also examine VPCs and security groups in separate dashboards. These dashboards provide further details such as configuration properties, instances, associated security groups, and firewall rules. I’ll be covering more on that topic in an upcoming blog article.
Choose a VPC to analyze and examine different group-by options. The standard group-by options are presented, however not all are applicable for AWS scenarios. I mentioned Security Groups and tags, VMs are another option to choose. Selecting VMs shows flows between EC2 VMs for this VPC. We can take this information and determine how my AWS VMs are communicating within the public cloud and into a private cloud environment. I can also examine the flow details then look at firewall rule recommendations to facilitate communication or modify the security posture. In this way, you can understand how VMs, which include applications or services, are communicating. We can take this a step further to map our AWS VMs to an application for micro-segmentation planning.
The 3.2 release introduced the ability to creation applications by grouping VMs into tiers. With the 3.4 release, we can add AWS VMs as application tiers. The tiers consist of private, hybrid, or public cloud-based applications. When building an AWS application, you can leverage AWS VM tags to easily include relevant VMs or create conditions by name, IP address, port details, and custom search, to name a few options. Once we’ve built our tiers and saved the application, traffic patterns are clearly visible between the tiers and informed decisions can be made about a micro-segmentation strategy for that application.
Adding AWS entities into the 3.4 release now provides you with the ability to understand traffic patterns and plan micro-segmentation across your private and public cloud environments. This capability offers unparalleled visibility into public and private clouds, which further establishes vRealize Network Insight as the market leader for micro-segmentation planning, network visibility, and management. If you haven’t taken vRNI for a spin, there’s never been a better time.
