Peanut butter and Jelly…..that’s how I often end up describing VMware Cloud on AWS. It truly allows customers get the best of both worlds, between AWS and their VMware powered Software Defined Data Center (SDDC). Customers no longer have to make a binary decision. This is done by providing the leading compute, storage, and network virtualization stack deployed on dedicated, elastic, bare-metal, and highly available AWS infrastructure.There are excellent blogs by Humair Ahmed that provide details on the service itself, how SDD’s are spun up . https://blogs.vmware.com/networkvirtualization/2017/12/vmware-sddc-nsx-expands-aws.html/
Although I’m not going to blog about the bring-up process, since its addressed in Humair’s blog, one question I get a lot is how do we integrate with native AWS services. Firstly, let’s quickly address why is this important?
One of the key aspects I see customers mention as they move to native AWS services like RDS is that these are fully managed instances. As an end-user simply consume the database service, without worrying about the underlying OS or where the database actually runs. There are several blogs out there that discuss the benefits and disadvantages to this approach, but we can all agree on the ease of use aspect as being a key driver.
I was fortunate to get an opportunity to get some hands-on experience in the past few days on real hardware as part of a workshop. It’s pretty amazing to see this live in-person so I highly encourage you to reach out to your VMware team to sign up for a one: many workshop in your region.
In the next few minutes, I’ll try to explain how we can connect a native AWS RDS instance with a VM running in VMware Cloud on AWS which is providing the front end services for a photo album application.
First, I spin up a VM in VMware Cloud on AWS pretty much the same way we do on-premises. Once its up and running, I want to take note of the private IP address since we’ll be setting up a NAT rule for it.
Next, I grab a public IP from the console to access the front end from the internet. I’ll use this public IP to create a NAT rule which maps to the private IP that is listed above.
Since VMware Cloud on AWS has a default deny, we’ll create some firewall rules to allow inbound/outbound communication between AWS and VMware Cloud on AWS resources. We’ll also create a firewall rule to allow communication to the public IP we requested. The net firewall rule in place looks something like below
So, what happens on the native AWS side? Well, for that we’ll go to the SDDC bring-up process. This is outlined in-depth in Humair’s blog mentioned above, but key element here is the AWS Elastic Network Interface (ENI) that is created within the AWS customer VPC and used by VMware Cloud on AWS. These ENI’s are used to communicate between native AWS resources and VMware Cloud on AWS in the same VPC. This is extremely valuable to customers as it provides some real cost savings as compared to having to do VPC Peering or utilizing IGW where transit charges can be incurred. I highly encourage you to chat with your VMware team for more details on this topic and design scenarios!
Anyway, getting back to our example. Now that we’ve configured the required NAT and firewall rules on the VMware Cloud on AWS side, lets take a look on the AWS side.
We’ve already spun up an RDS instance, but it has no public access. Notice that the security groups that are attached to RDS already have the private IP information from VMware Cloud on AWS. Also, if we check the routing tables, we see the target as the ENI.
Once, everything is setup, let’s try to hit the webpage. Since I already provided the private IP of the RDS instance along with the DB details, I can now browse the website, upload data as needed.
There you have it! You have a VM that is connected to a RDS backend!
For more in-depth details, please refer to part 2 of Humair’s blog : https://blogs.vmware.com/networkvirtualization/2017/12/vmware-sddc-nsx-expands-aws.html/
For details on the service itself: https://cloud.vmware.com/vmc-aws