Understanding How AWS Security Groups work with VMware Cloud on AWS

Its no secret that one of the most appealing features of VMware Cloud on AWS is the ability for VMs to interact with AWS services. However, understanding that there are two major technologies in play to make this happen, and how they interact is a necessity to make you successful. Luckily, both AWS and VMware have made this integration very simple. To be successful in these integrations you must understand the AWS Security Groups and the NSX-T Firewall rules. This blog post focuses on how the Security Groups are leveraged to allow the desired interactions between the VMware stack and AWS services.

First things first…

When you go to deploy an SDDC in VMware Cloud on AWS, you are asked to select a VPC and subnet that you already own that will link to your SDDC.

This is the VPC where we will add AWS services that we want to interact with our SDDC virtual machines. Choosing a VPC that is in the same Availability Zone will help you to not incur cross-AZ data transit charges when your applications are interacting. Once the VPC and subnet have been selected, an AZ chosen for the SDDC, and the rest of the prompts completed, your SDDC will deploy. After about 110 minutes, you’ll have a full-fledged SDDC ready for some action.

How Do Security Groups Work with VMware Cloud on AWS?

When you deploy an SDDC and select a VPC to attach, it is extremely important to note that the ‘Default Security Group’ of that VPC will become the Security Group for the Elastic Network Interfaces (ENI). While many might not think this is important to understand, there is a key differentiator in how the Security Group for the ENIs work as opposed to Security Groups for the rest of the AWS services.

The default VPC Security group Inbound and Outbound rules are actually in relation to the ENI itself, meaning that ‘Inbound’ rules would have the source IP from within the VPC subnet (see the dotted arrow in the image below). Traditionally an inbound rule would have a source of 0.0.0.0/0 or possibly another subnet of a network connected via VPN, and would be created for data ENTERING the VPC. However, with the Security Group for the ENI, ‘Inbound’ is actually EXITING the VPC and ENTERING the VMware Cloud on AWS SDDC. Confusing?? You’ll pick it up quickly! That’s why I’m writing about it :).

Any additional AWS Services you add to this VPC should be added to an additional Security Group. As you can see in the image above, I have an EC2 Security Group that I use, which has the inbound subnets from VMware Cloud on AWS. All additional Security Groups created for the VPC will act as a normal Security Group (Inbound is actual data coming from outside into the Security Group).

If you disregard my advice…

Well, that’s your prerogative :). However, things get to be a bit tricky when you throw both your AWS services into the same default VPC Security Group as VMware Cloud on AWS. For instance, you would be combining inbound rules into the VPC from external sources, with inbound rules into the ENI from local sources. Things just get messy and are more confusing to keep track of. Just don’t do it.

As far as all the rest of the information in the diagram, I’ll be doing a few additional follow-up posts on the routing and keeping the VPC Route-table up-to-date. Stay tuned!

For more information on VMware Cloud on AWS:

VMware Cloud on AWS Homepage: https://cloud.vmware.com/vmc-aws
Docs and How-To’s: https://docs.vmware.com/en/VMware-Cloud-on-AWS/
Twitter: @vBrianGraf
Official Twitter: @vmwarecloudaws