Tag Archives: VMware Cloud on AWS

Native AWS VPC Connecting to VMware Cloud on AWS (Part 2) – Route Tables and Transit Gateway Attachments

Welcome to Part 2 of VPN connectivity to VMC via AWS VPN. For this post, I will walk through how to attach an AWS VPC to an AWS Transit Gateway in order for route tables to be learned by the VMC SDDC and AWS VPC that will ultimately allow communication from workloads in AWS and workloads in VMC. If you immediately try to ping across the VPN from an EC2 instance to a VMC VM, it will fail as there is more work to do in order to create communication pathways in the form of adding a VPC to the Transit Gateway as well as configure some NSX rules.

In the diagram above I created two EC2 instances with an AWS VPC. For the sake of testing and validation, I first had to create a jump VM with access to the internet in order to remote into the workload VM. This is because, in order for the workload VM to ping across the VPN, 0.0.0.0/0 must be routed through the Transit Gateway and not an Internet Gateway. The goal here is to have a VM on the 10.0.10.32/27 subnet ping a VM on the 10.250.10.0/24 subnet.

To start, the first thing to check is the routing table for the Transit Gateway. This is done by selecting “Transit Gateway Route Tables” on the sidebar with the VPC.

You will then see a list of learned routes from the VMC SDDC. For the sake of this blog, I have deployed AWS EC2 Instances on a subnet that I plan on attaching to the Transit Gateway (10.0.10.0/24). However, notice below that only the learned routes for the VPN to VMC are listed below. While the 10.250.10/0/24 subnet is learned, in order to open communication via the AWS VPC, we first need to attach the VPC to the Transit Gateway so the 10.0.10.0/27 subnet is included. Here are the steps to create the VPC attachment to the Transit Gateway.

This image has an empty alt attribute; its file name is image-18-1.png

Step 1: Select “Transit Gateway Attachments” then “Create Transit Gateway Attachment”. Find correct Transit Gateway ID.

This image has an empty alt attribute; its file name is image-20-1.png

Step 2: Add tag for attachment name.

This image has an empty alt attribute; its file name is image-17-1.png

Step 3: Select the correct VPC and ensure you have the correct subnet selected. Select “Create Attachment”

This image has an empty alt attribute; its file name is image-19-1.png

As you can see, now that the VPC is attached to the TGW, the 10.0.10.0/24 subnet is now listed. This will now allow for the routing of traffic from my EC2 instance to my VM on VMC.

This image has an empty alt attribute; its file name is image-25.png

The final step is to create groups and add inbound and outbound firewall rules within the Network & Security section of the SDDC console. Make sure to apply the rule to the VPN Tunnel Interface and NOT “All Uplinks“. The reason for this is that a firewall rule applied to All Uplinks does not apply to the VPN Tunnel Interface (VTI), which is a virtual interface and not a physical uplink. The VPN Tunnel Interface must be specified explicitly in the Applied To parameter of any firewall rule that manages workload VM communications over a route-based VPN. In addition, you can see how groups are created on an earlier blog here.

Now that the routing table is complete and Compute Gateway Firewall rules are in place, you can test!

EC2 Windows VM
Ping results from EC2 VM to VMC VM
Advertisement

VMworld 2021 – 11 Sessions I’m Excited About!!!!

While I’m disappointed I can’t see my coworkers and customers again this year at VMworld this October 5-7, I’m still looking forward to all the great content that will be shared. One of the benefits of virtual is again this year is that it’s free for all attendees! Here’s my Top 11.

VMware vSAN – Dynamic Volumes for Traditional and Modern Applications [MCL1084] – Duncan Epping and Cormac Hogan are at it again presenting their deep knowledge of VSAN in both traditional and modern application use cases. I’m looking forward to see their take on VMware vSphere container storage interface (CSI) in Kubernetes! 

William Lam – App Modernization Deep Dive with VMware Cloud on AWS and VMware Tanzu [MCL2290] – Is VMworld even VMworld without William?! I have been waiting for a long time to talk VMWonAWS and Tanzu!! For those of you who want to see modern apps with Tanzu on VMWonAWS, this session is a must!

Achieving Happiness: The Quest for Something New [IC1484] – Those of you who have met Amanda Blevins know that she’s not only about technology but is also passionate about personal development and brand building. Many things have changed over the past 18 months with our day to day profession and I’m anxious to see what insights Amanda and Steve Athanas (CIO UMass Lowell) will have for us!

A Guide to vSphere with VMware Tanzu: Day 2 Operations for the VI Admin [APP1718] – No doubt Dean Lewis and Simon Conyard will bring their technical acumen and British wit to the session as they cover basic Kubernetes architecture in a way that makes sense for the VI Admin. Kubernetes is a fun word to say, but it’s a completely different thing to say AND do in the enterprise….at the end of the day, you still need to manage the application. These two gents will show you how!

An End-to-End Demo of Day 0 to Day 2 VMware Tanzu Management with vRealize [APP1586] – Matt Bradford and Sam McGeown always create great demos for their sessions. This is a must see for those on the Tanzu and modern application path and want to see how the vRealize suite is making Day 0-2 a cinch.

A Guide to the Cloud Operating Model [MCL1115] – Clouds are becoming the new silos. SaaS can grow your environment exponentially at a rapid pace and before you know it, you’re in the same siloed chaos you were in before cloud. Taruna and Martijn walk you through VMware’s multi-cloud approach when creating a consistent cloud operating model. It’s great to leverage multiple clouds based on specific use cases but it’s important to know how to best manage them.

Design Principles: Cloud Architecture Design and Operations [MCL2151] – Without a doubt these two Principal Architects are some of the smartest people I know at VMware. Mitesh and Andrea have been designing Enterprise VMWonAWS deployment since the service has been available. If you want to know how best to design VMWonAWS for production, this session is #1!

Automate VMware HCX Workload Migration to VMware Cloud on AWS [MCL1050] – This session would be #2 to the one above. Now that you have the VMWonAWS SDDC deployed, it’s time to migrate! Phoebe and Asaf bring their VCDX (between them, they have four!) and HCX knowledge to show you how to automate your migrations.

Cloud Workload Security and Protection on VMware Cloud [SEC1296] – While you’ve migrated workloads to VMWonAWS, you still need to secure them. Being in the cloud does not remove you from needing to protect the asset. Using the security features of NSX on VMWonAWS is a great start. To be even more secure, this panel will show how you can leverage Carbon Black on VMWonAWS.

A Guide to Application Migration Nirvana [MCL1264] – Bottom line….application migrations can be HARD! vRealize Network Insight has quickly become one of the main tools used to help customers understand applications and how to effectively plan for migrations to VMware’s Cloud. Martijn Smit has a wealth of experience to share do be sure to add this to the schedule!!

VMware DRaaS – Combine Two Services for Comprehensive Disaster Recovery Plans [MCL1202] – This session should be awesome! It’s not just about Site Recovery Manager (SRM) anymore. If you haven’t taken a look at VMware Cloud Disaster Recovery (VCDR aka Datrium) yet, you should. This session will cover both solutions and how we’re allowing customers to recover from ransomeware attacks, outages, and more. It’s all about flexibility and this session will give you the information you need to make those critical business continuity and disaster recovery decisions.

I admit that most of these sessions are cloud and application based but that’s where my passion lies and that’s where my customers are headed! Don’t forget to register today and Enjoy VMworld 2021!!!!

Native AWS VPC Connecting to VMware Cloud on AWS (Part 1) – Native VPC Connectivity via VPN

With the release of VMware Cloud on AWS 1.12, we delivered additional connectivity options with the addition of transit connect (VMware managed AWS Transit Gateway). Over the past few weeks, I have been working on a project that has specific success criteria as well as challenges that prevent certain connectivity options so I thought what better way to show how we got around the issue than to show how we did it as Transit Connect and AWS Direct Connect were out of scope. The plan is to have this be a multiple part blog series that details how to setup and test a route based VPN, attach to native AWS EC2 workloads via ENI in the VMC VPC as well as leverage a Transit connect that makes connectivity easier to configure, manage and maintain. The diagram below is the overall architecture for those already leveraging AWS native services via a Direct Connect and Transit Gateway but can only connect to VMC via IPSEC VPN for certain reasons (shout out to fellow VMC Architect Will Lin for the assist!). While Direct Connect provides much better speeds and feeds, you may still be able to accomplish what you need depending on your application requirements.

STEP 1: To get things started, we need to either identify or create a VPC that we want to communicate with the VMware Cloud on AWS SDDC. If you already have a VPC configured you can skip to Step 2. To create a new VPC, log into your AWS account go to Services > VPC> Create VPC. Similar to creating your VMC SDDCm it is paramount that plan your CIDR range appropriately so can assign subnetting correctly based on what you are trying to accomplish. ** Make sure you are selecting the correct AWS Region based on your requirements! **

Next, create a subnet that you will assign to the VPC. This is why understanding the CIDR ranges is important as you cannot have any overlap between your VPC CIDR and VPC subnets so keep that in mind as you build things out.

Creating a subnet assigned to the AWS VPC

Step 2: Deploy a AWS Transit Gateway (TGW). For reference, an AWS Transit Gateway connects VPCs and on-premises networks through a central hub. Keep in mind the default ASN number for the AWS TGW is 64512. If you are going to use an existing TGW, get the correct number from your team. For the sake of this blog, I setup the TGW with all the default settings.

Step 3: Create a Customer Gateway (CGW). A CGW is a resource that you create in AWS that represents the customer gateway device in your on-premises network, or VMC in this situation. 

In order to configure the CGW, you need to enter the VPN Public IP listed in the Networking & Security section of the SDDC console.

Step 4: With your transit and customer gateways configured, it’s time to create the VPN connection from the AWS side. Go to Services > VPC > Site-to-Site VPN Connections > Create VPN Connection. Name the VPN connection and select “Transit Gateway” as the gateway type and add your CGW. Take note that you can also add a new CGW didn’t as a part of the previous steps. We want to set the routing options to dynamic so we take advantage of BGP. My personal preference is to define the CIDR and per AWS documentation, this needs to be a /30 within a certain range. I also created a basic preshared key rather than have AWS create the key randomly.

AWS VPN Configuration

Step 5: Download the VPN configuration as a generic file. This is where you can validate the configuration and use it for configuring the VPN from the VMware Cloud SDDC Console.

Step 6: Configure the VPN on the SDDC. Go to the VMC SDDC Console > Networking & Security > VPN > Route Based > Add VPN. Here you want to take the Virtual Private Gateway Outside IP and enter that into the Remote Public IP Field. Take the Customer Gateway Inside IP Address and enter that number as the BGP Local IP. Next, take the Virtual Private Gateway Inside IP and enter that into the BGP Remote IP field. All that’s left is to enter the BGP ASN number that your configured earlier as a part of the TGW creation. It should also be listed in the config file you downloaded. If all numbers are correct, you should see the VPN Tunnel and BGP come up in a matter of minutes! If the VPN comes up and BGP does not, check your IPs and ASN numbers. Additional help can also be found here!!!!

You now have a working VPN from AWS to VMC!!! While the tunnel is up, there is more work to do so you can fully test traffic. In Part 2 I will cover routing tables and SDDC Gateway rules to enable two way communication. Stay tuned!!!!

Day 2 VMware Cloud on AWS SDDC Scale Up…in Four Clicks or Keystrokes!!!!!

As customers continue to build their cloud strategy with a combination of VMware products and services, one thing has been heard loud and clear…”Make Day 2 Operations easy!” As customers continue to move and increase their footprint in VMWonAWS, the SDDC’s demand for management resources will increase. While the VMC Sizer is a great tool to help understand the recommended size of an new SDDC, there will be times when SDDC growth is too big for the management VMs to handle after the SDDC is deployed…kind of like the time when Sheriff Brody realized he was going to need something much larger to catch a Great White shark.

When an SDDC is created, two resource pools are created. One named “Compute- ResourcePool” and one named “Mgmt-ResourcePool”. Mgmt-ResourcePool (MRP) is VMware managed and is comprised of vCenter, 2 NSX Edges, and 3 NSX Managers by default. In order ensure uptime and performance, all resources in this MRP have reservations assigned so these appliances always have what they need.

For more information, Product Manager Vish Kalsi wrote a quick blog on choosing the correct SDDC deployment. In short, medium management appliances require 34 vCPU and 116GB memory to run vCenter, NSX Manager and other management appliances. Large management appliances require 68 vCPU and 240GB memory. Large SDDCs are ideal for addressing a larger density of workloads . Large SDDCs support enhanced network throughput on the NSX Edge appliance. VMware recommends large-sized deployments with more than 30 hosts or 3000 VMs, or if the resources (CPU or memory) are oversubscribed in the management cluster.

Previously, a VMware support ticket needed to be opened in order to convert a regular aka medium SDDC to large. This method was obviously not preferred by most as this is the opposite of a self-service cloud operation model. However, begging with VMWonAWS 1.10, you can now upscale your SDDC to large with just a few clicks….or keystrokes!!!

Start by logging into the Cloud Services Portal, select your SDDC and go to Settings > SDDC > Management Appliance. You will see your SDDC as well as the “Upsize” option listed as seen below.

Upsize Option within the Cloud Services Portal

The only thing left to do is accept the addition of hosts if necessary and understand that you can never go back to a regular size SDDC. Once Upsize is selected, the process takes about 2 hours to complete and you will lose connectivity. It is recommended to do this during a maintenance window.

Once complete, the Management appliances will reflect as a “Large”

Once, in vCenter, you will see that the NSX Edges have gone from 4 CPU x 8 GB RAM to 8 CPU x 32 GB RAM and vCenter has gone from 8 CPU x 28 GB RAM to 16 CPU x 37 GB RAM (only 12 of the 16 CPUs are reserved in this configuration). You can check the before and after in the VM summary as seen below.

Regular SDDC vCenter
Large SDDC vCenter

Now that the SDDCs have been upscaled, it’s onto bigger and better things for your VMWonAWS SDDC!

Effectively Planning VMware Cloud on AWS SDDC Upgrades

One of the questions I am often asked is now that I am using VMware Cloud on AWS, how do I go about managing my SDDC life cycle? The answer…..VMware has you covered! As of March 2020, we have made some significant enhancements to the Notification Gateway (NGW) that give you several options to receive updates from VMware Cloud Services regarding maintenance activities such as certificate replacements and SDDC upgrades to new releases. While the NGW can be leveraged in several different areas, my preferred integrations are with Slack and Microsoft Teams. Setting up these integrations are fairly straightforward. Look no further than William Lam’s blog for details.

Even if you have Webhook integrations setup, you will still get a notification email similar to the image below letting you know when your SDDC is scheduled for an upgrade.

Notification email from Notification Gateway detailing each phase of the SDDC upgrade.

It is imperative that you take note of the dates and times your SDDC is scheduled for each phase as your times will all be in UTC timezone so do your time conversions accordingly. When you login to your SDDC console and go to the maintenance tab and you will see each phase listed along with recommendations for each phase.

Each phase of the SDDC is highlighted below as well as details around SDDC accessibility during the upgrade. For detailed information, read my associate Tom Twyman’s blog and the SDDC upgrade notes found here. We continue to improve upgrade processes in the background so check back often!! There are additional considerations to make when integrating with HCX, Site Recovery and Horizon so be sure to understand the impacts listed in the read me!! Keep in mind that during Phase 1 your vCenter certificate will be updated and the NSX certificate will be updated during Phase 3. If you have other products and services that depend on vCenter, you will need to take the proper steps to accept the new certs.

While there are time estimates for each phase, mileage may vary during the upgrade. To make things a bit easier for you. I have included a simple excel spread sheet to help you plan your SDDC upgrade.

After going through several customer upgrades over the past two years, my top 5 things to do are

  1. Don’t forget about certificate validation afterwards!
  2. Plan your outages around each phase and best to be conservative. Allot for the full estimated time.
  3. Setup integrations with the NGW. While emails are nice, it has been my observation that people get too many emails these days and these notifications are often ignored. Pick a delivery method that will get your attention!
  4. Read the release notes as well as upgrade notes before your scheduled upgrade.
  5. Don’t panic! For some, giving VMware the keys to the car (SDDC) is unnerving, and they want to watch and be involved. Remember this is a service, we have you covered. Sit back and relax!

Deploying a VMware Cloud on AWS SDDC End to End

For those of you who are ready to deploy your first Software Defined Data Center (SDDC) on VMware Cloud on AWS, there is a little bit more than meets the eye when it comes to the initial deployment. As a part of the VMware TAM Lab series, I demonstrate how to deploy an SDDC from start to finish, including the configuration of the VPC in AWS.

**SHAMELESS PLUG** – Subscribe to the TAM Lab YouTube channel. We are covering all VMware Technologies and use cases….including how to go about building your own home lab. Check it out!!!

My Guide for Passing the AWS Solution Architect Associate Exam

If you are reading this then you probably already have an understanding how fast Amazon Web Services rolls out new features and services. It’s impossible to know everything about AWS and I definitely struggled in my preparation for this exam. I set out to get certified almost two years ago but simply never could find the best time to take it. Truth be told, after rescheduling three times in 2018, I let my test expiration lapse because I literally didn’t have time to sit for it. In 2019 I was determined to pass the Solution Architect Associate exam as my 2018 failure was hovering over me like a black cloud. I am excited and relieved that I recently passed and I want to pass along some tips for those of you who want to be a certified AWS Solutions Architect. **Once I set a test date, I prepped for about six weeks.**

  1. Leverage AWS Free Tier – This exam was not easy for me as I spend over 90% of my time with VMware solutions and all my AWS exposure was after hours. That being said, leveraging the AWS Free Tier proved to be a lifesaver when preparing for the exam. There are some things that you will use in practice labs that may cost a few dollars but every cent is worth it. You will need hands on experience setting up S3, EC2, and VPC from scratch. The free tier makes it all possible with next to zero dollars in cost. My advice….look at as an investment.
  2. A Cloud Guru – Ryan Kroonenburg and team have done all of us a great service in making several AWS constructs easy to understand. The cost was well worth it. I didn’t get a membership but did purchase the AWS Certified Architect Associate course. I reviewed each session twice and went through the VPC, S3, Databases, and HA Architecture content several times. Make sure you understand all the labs!! I went through the practice tests as well but I didn’t quite find them deep enough to help me prepare. I had to find another test prep course…Whizlabs!
  3. Whizlabs! – I can confidently say that without Whizlabs AWS Practice Tests , I would not have passed the exam. Whizlabs provides great content that is similar to the exam and detailed explanations to each test question. I purchased the practice exam questions for under $10 at Udemy. As a matter of fact, they are having their Black Friday sale right now! DON’T TEST PREP WITHOUT IT!!!
  4. AWS.com FAQs – For S3, EC2 also read all about Database Services. There will be some questions that come straight out of the FAQs.
  5. AWS Certified SA Official Study Guide – I wouldn’t say this is a must have but for those of you who like having something physical in your hand to study, this will do the trick. I found some of the diagrams and summaries helpful.
  6. Architecting on AWS – This three day course helped me with better understanding AWS concepts and best practices. I don’t view this as a must but it was well worth my time.
  7. Practice, Practice, Practice – Understand the exam format helped me prepare. You will have plenty of time to answer all 65 questions if you practice beforehand. Understanding the concepts around VPCs and networking is a must. Also know RDS and DynamoDB inside out!!

As the VMware-AWS partnership continues to grow, it’s important for both companies to understand each others’ services. This exam was on the tough side but I felt well prepared by the time I sat for it. Preparing for this exam has definitely helped me in conversations with customers as they not only move vSphere workloads to VMware Cloud on AWS but also look for ways to innovate with AWS native services such as S3, RDS, Lambda and more. I highly recommended getting this certification. It’s well worth it!! Good luck in your studies and feel free to reach out to me if you have questions via Twitter @vSeanLambert or reply to this blog!

VMware Cloud on AWS – SDDC to SDDC VPN and MS AD Replication

This is part two of my blog on how to leverage Microsoft Active Directory as an Identity Source and have AD replicate between two VMware Cloud on AWS SDDCs. Now that I have Active Directory running in US East, I will setup a route based VPN between my US East SDDC and US West SDDC. For my lab, I am using a Route Based VPN to replicate Active Directory Traffic. To add Route Based VPNs to both SDDCs, take note of your SDDC Public IPs on your Management Networks, determine what you want your Autonomous System Numbers (ASN) to be, and determine your IPs for both BGP local IPs. To keep the BGP IP scheme simple, I chose 169.254.x.x/30 to only allow for two available IP addresses. FYI, There are two different number ranges for Public and Private ASN numbers. Public is 1-64,511 and Private is 64,512-65,535. Route based VPN makes things simple in this scenario since we are leveraging Border Gateway Protocol (BGP) where both SDDCs are able to exchange routes and leverage BGP peering. For a deeper dive into BGP peering specifically around AWS Direct Connect and VMware Cloud on AWS, check out Nico Vibert’s Blog. It will not disappoint!

SDDC Public IP Info

Once you have the ASN and SDDC Public IP information, you can add your route based VPN by going to Networking & Security tab -> Network -> VPN -> Route Based -> “Add VPN”. For my lab, I have kept all the defaults for the tunnel and IKE settings. You may need to make changes here based on your security requirements. You must, however, select a pre shared key that will be used for both VPN connections to establish a secure connection. I have also left the Remote Private IP field blank. Once you click “Save”, you will see the status of the VPN and BGP Remote IP go to a yellow status as the negotiations take place. If successful, you should see both Remote BGP IP and VPN status turn green.

SDDC to SDDC VPN once completed

The next step in the process is to deploy a second Domain controller inside the second SDDC. Before you can promote the second DC, you need to first deploy a Windows Server VM in SDDC #2. Once the VM is deployed, you will then need to establish two-way communication across the VPN tunnel to be able to add the Windows Server to the domain and promote it. Although the VPN is up, you still need to configure additional Gateway Firewall rules in order for Domain Controllers to talk to each other across networks. Go back to Networking & Security -> Security -> Gateway Firewall -> Compute Gateway -> Add New Rule. For two-way communication, add two rules that allow traffic to and from the Domain Controller. Make sure that you have this traffic go over the VPN Tunnel Interface and NOT the Internet Interface. Make these rules for both SDDCs.

Gateway Firewall Rules for VPN Tunnel Interface

Before promoting your soon-to-be Domain Controller, make sure you can ping across the VPN via IP and DNS FQDN. The next step in the process is to deploy a second Domain Controller inside SDDC #2. I will not go through the process in this blog but the steps are similar to setting up the first DC in that you need to promote the server to a Domain Controller. There are several blogs out there on how to do this but here’s one just in case. Once added, you can verify Active Directory is syncing across SDDCs and Domain Controllers by running “repadmin /replsummary” via the Command Prompt. You can now add users, GPOs, etc to either side and both SDDCs will have the same info. To take things even further, add your new Domain Controller as an identity source to the new SDDC. This will allow users to login to either vCenter as long as they have an account on the domain. If you missed my blog on setting up AD as an identity source with VMWonAWS, click here.

VMware Cloud on AWS – Identity Access with Microsoft AD

For years I have been Window (see what I did there) shopping Intel NUC, HP Microservers, Mac minis, and others to setup my home lab v 2.0. However, with the onslaught of Cloud Services, I continue to balk at the thought of dropping thousands of dollars every few years for new hardware, as well as the electric bill and management overhead that comes with it. With VMware Cloud on AWS, I wanted to see how I could create a lab environment and continue to use Active Directory for vCenter authentication. Due to not having an vCenter on prem, Hybrid Linked Mode (HLM) wasn’t an option for an identity source. VMware has existing documentation where you can see the options for Identity Sources. This blog will walk you through the setup and configuration steps I took to get AD working within VMWonAWS vCenter. Like with all things in Public Cloud, it’s critical to have your networking straight before you begin adding subnets, etc.

  • Create your subnet via SDDC > Networking & Security > Network > Segments > Add Segment
  • Login to vCenter with the cloudadmin account.  We can see the network segment is added in vCenter. Note that we cannot add networks from vCenter. We must use the SDDC Console to add logical networks
Networking View from vCenter

One of the great things about vSphere 6.7 and later is the additional functionality built into the Content Library. I have already loaded several OVF Templates and will deploy my Domain Controller from a Win2016 Std OVF template. For more content library goodness, check out William Lam’s blog here. I’m a huge fan and I recommend you use Content Libraries!!

During OVF deployment, place the VM on the correct network

With the Network Segment selected and IP assigned, the new Domain Controller will be able to communicate with the SDDC vCenter after a few more configurations.

Now that we have the DC on the proper network segment, we need to allow traffic to flow between the SDDC Management Gateway and the DC. To do this we need to create a Management Group. This is done by going to the SDDC Console > Networking & Security > Inventory > Groups > Management Group > Add Group. Add your domain controller to the Management Group with its assigned IP.

Once the Management Group assignment has been configured, we can now add a Gateway firewall rule to allow the domain controller to talk to the SDDC vCenter. To enable communication, go to SDDC Console > Networking & Security > Gateway Firewall > Management Gateway > Add New Rule. This is where adding the user defined group comes into play as we need to be able to select the group to add as the destination for the firewall rule.

We now need to allow communication via the DNS settings on the management gateway. We must remove the default DNS settings and add the domain controller(s) IPs so LDAP/AD can communicate with the SDDC vCenter. If we don’t change the IPs from default, we will get an LDAP error that the URL cannot be reached. Here’s a video that ties together the final piece of adding the DNS server and assigning the GlobalCloudAdmin role to the user I want to login to vCenter with the s2c.local domain credentials. In addition, you can read Nico Vibert’s blog that shows how to use AWS Directory Services as an identity source. Enjoy!!

AWS re:Invent 2018 – Takeaways

re:Invent 2018 was a week full of exciting announcements that kept me running from one session to another as well as took me out of my comfort zone as a technologist. There was so much going on that it was difficult to digest every session let alone keep up with all of the services and industries that AWS is in. However, these are my takeaways…..

  1. The AWS-VMware partnership runs deep! As previously mentioned, VMware CEO Pat Gelsinger was the only other CEO to join Andy Jassey on stage during his keynote where they announced AWS Outposts. I’m excited to see how customers use the service and the use cases behind them. In addition to the keynote, the VMware Code booth was busy from opening to close as we covered IoT (Raspberry Pi with sensors), Wavefront, VMware Cloud on AWS, and more. It was great to see so much activity and help customers realize that VMware is heavily invested in the cloud and can bring immediate value as customers continue to develop their cloud strategy.
  2. If you haven’t heard the words, Artificial Intelligence, Machine Learning, Deep Learning, Reinforced Learning, or Neural Networks….you WILL!! With services like SageMaker, RoboMaker, DeepRacer, DeepLens, Polly and more, intelligent software is here. From a VMware standpoint, we changed the SDDC acronym at VMworld 2018  from Software Driven Data Center to the Self Driving Data Center as we are working to build intelligent software in products such as vRealize Operations, NSX Data Center, and AppDefense as well as services like NSX Cloud and VMware Cloud on AWS. I would advise everyone to get a base understanding of AI and ML. It will benefit you greatly as skills will need to shift due to learning being built into software. I personally believe that things such as host and server configurations will be a thing of the past. Infrastructure as code is here and we all must learn to adapt. I recommend picking up Prediction Machines: The Simple Economics of Artifical Intelligence by Ajay Argwal, Joshua Gans,  and Avi Goldfarb.
  3. Get outside your comfort zone! re:Invent hosts some of the smartest people I have ever been around. re:Invent is not the time to keep to yourself and only bounce from session to session. Go see the exhibit halls, demo booths and more. Although you may get your badge scanned countless times and receive pointless swag, you may come away with some valuable connections and insight. Take this amazing opportunity to grow your professional network!
  4. There is too much to learn in one week! Consider re:Invent a conference that you will never be able to attend every session you want. The sheer scale of this event makes getting to everything impossible. However, with YouTube at your fingertips, you have an opportunity to review sessions you attended as well as see some you may have missed.

I know this post is a little late. I have been wanting to post this for some time. re:Invent was awesome and I can’t wait to attend next year!