AWS Public Sector Blog
Landing Zone Accelerator connectivity with VMware Cloud on AWS
The Landing Zone Accelerator on AWS (LZA) solution from Amazon Web Services (AWS) deploys a cloud foundation that is architected to align with AWS best practices and multiple global compliance frameworks. Customers with highly-regulated workloads and complex compliance requirements can use the LZA to better manage and govern their multi-account environment. When used in coordination with other AWS services, it provides a comprehensive low-code solution across over 35 AWS services.
Some customers may use VMware Cloud on AWS to integrate on-premises vSphere environments, allowing them to move existing workloads to the cloud more quickly. If your organization leverages these cloud services, integrating your VMware workload with natively managed AWS services can help you reduce your operational overhead and optimize your total cost of ownership (TCO).
In this blog post, explore the technical considerations related to integrating your LZA landing zone with your VMware Cloud on the AWS environment. We assume that you’re familiar with the VMware Cloud Software Defined Data Center (SDDC) deployment and best practices, the VMware Cloud on AWS networking architecture, and LZA deployment.
Important account considerations for connected VPC
First, decide the account you will use for the virtual private cloud (VPC) that is connected to the VMware SDDC during SDDC deployment.
For this blog post, we provide an example of an LZA landing zone, which implements strong segregation of your development, test, and production accounts by default. This means that the routing table configuration of your AWS Transit Gateway prevents these accounts from communicating with each other for security reasons. We assume in the architecture design described in this post that your intent is to integrate VMware Cloud on AWS and LZA while respecting your existing security specifications. The compliance enforced within the LZA environment does not automatically extend to the VMware Cloud on AWS, so additional steps may be needed within the VMware Cloud environment to meet compliance requirements as needed for VMware SDDC workloads.
Keeping these considerations in mind, this post provides an example of an organization that has been created using AWS Control Tower. In this example, we create an AWS account that will be used for the connected VPC workloads. The following Figure 1 shows how this account fits into the LZA architecture with the organization unit (OU) named “sddc” and account named “sddc-Team1.” You can deploy additional accounts if needed within the same OU if you decide to further segregate workloads. The dedicated “SDDC_connected_VPC” can then be deployed in these AWS accounts. This approach allows you to define specific service control policies (SCP) for all of your AWS accounts within this OU within your organization. This makes sure that the native AWS services being used with VMware workloads can be configured independently from the rest of the LZA environment.
Figure 1. AWS accounts structured into organizational units (OUs) under the root account.
Once deployed, we suggest using a functional account approach as illustrated in Figure 2, to give various teams parallel access to the “SDDC_connected_VPC” while still supporting the capability to isolate certain workloads in specific accounts. Figure 2 below illustrates a multi-account structure example that is possible to create when deploying the LZA. This multi-account organization approach illustrates how a customer can leverage the AWS Organizations services (OUs and SCP) to centralize management of multiple AWS accounts.
Figure 2. The LZA prescriptive architecture, in which teams have separate but parallel access to the SDDC VPC, which allows for the isolation of certain workloads in specific accounts.
The three communication paths required for LZA connectivity with VMware Cloud
The architecture for the LZA integration with VMware Cloud on AWS SDDC requires careful planning for your network architecture. The technical requirements to integrate LZA with VMware Cloud on AWS are:
- Enable communication between VMware Cloud on AWS SDDC workloads and native AWS Cloud services: for example, Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS), Amazon FSx, or Amazon Elastic File System (Amazon EFS).
- Enable communication for VMware vMotion and VMware HCX-based workload migration from on-premise data centers to VMware Cloud on AWS
- Enable communication from your VMware Cloud on AWS SDDC to the internet while supporting AWS Network Firewall packet inspection
To fulfill these requirements, there are three communication network paths that need to be created to support communication between VMware Cloud on AWS and the following environment:
1. From the on-premise datacenter to the VMware Cloud on AWS SDDC
2. From the LZA workload AWS account used for the VPC (SDDC_connected_VPC) to the VMware Cloud on AWS SDDC
3. From the LZA Transit Gateway deployed in the shared network account to the VMware Transit Connect with intra-Region peering.
Figure 3. The LZA networking architecture, which features the architecture for connectivity between the AWS Transit Gateway and VMware Transit Connect. The orange dotted lines from the user over the Internet Gateway, through the AWS Transit Gateway and to the SDDC_connected_VPC shows how all external connectivity from the VMware Cloud on AWS SDDC and LZA always passes through the perimeter VPC using the AWS Transit Gateway attachment.
Path 1: On-premise connectivity to the VMware Cloud on AWS SDDC
If you’re deploying LZA and VMware Cloud on AWS, you’ll need dedicated connectivity from your on-premise environment to the cloud, instead of using an internet connection, for higher bandwidth, lower latency, and a consistent network experience for your users. In our architecture illustrated in Figure 4, we are also using redundant AWS Direct Connect network connections for a highly available hybrid connectivity.
Figure 4. The AWS Direct Connect Gateway supports hybrid connectivity from on-premise datacenters through the LZA Network Account to the VMware Cloud on AWS account.
Additionally, to enable multi-region connectivity, a transit virtual interface (Transit VIF) over AWS Direct Connect connects the on-premise environment to an AWS Direct Connect Gateway. This AWS Direct Connect Gateway is then associated to the AWS Transit Gateway located in the LZA network account in one or more Regions.
The AWS Transit Gateway is highly available by design, so we do not need to deploy additional transit gateways for redundancy. Read more about AWS Direct Connect and AWS Transit Gateway.
The AWS Transit Gateway is configured with an “intra-Region peering” with the VMware Transit Connect in the same Region to provide on-premise connectivity. In addition to communication with VMware workloads, you can use HCX features like HCX Network Extension to extend Layer 2 networks from your existing data center into the VMware Cloud on AWS SDDC. Virtual machines that have been migrated using HCX can then retain the IP and media access control (MAC) addresses for a seamless transition to running workloads in the cloud.
Care must be taken to not advertise the same routes on different gateway associations with a single AWS Direct Connect Gateway. In other words, network traffic to and from VMware Cloud on AWS and AWS Transit Gateway must use the same route when communicating with your data center.
Path 2: LZA SDDC connected VPC to the VMware Cloud SDDC
The “SDDC_connected_VPC” in the LZA is connected to the SDDC using elastic network interfaces deployed along with the SDDC. This “SDDC_connected_VPC” can be used to integrate AWS services with virtual machines running in the SDDC. This high throughout and low latency link is especially important for integrating data intensive or latency sensitive services like Amazon EFS, Amazon FSx, Amazon S3, or Amazon RDS.
You can also use the “SDDC_connected_VPC” for running elastic load balancers for internet ingress load balancing for VMware virtual machines in the SDDC, as per the LZA architecture. Read more about augmenting VMware Cloud on AWS workloads with native AWS Services.
Path 3: Connectivity to shared services and Internet egress
Aside from traffic to the “SDDC_connected_VPC” and connectivity to on-premises through VMware Transit Connect intra-Region peering with LZA AWS Transit Gateway peering, the architecture also requires all other traffic to be sent to the LZA AWS Transit Gateway through the intra-Region peering.
This includes traffic to all shared services within the LZA, such as Amazon Route 53 inbound domain name system (DNS) resolvers and communication with other VPCs. Internet connectivity for workloads within the SDDC also traverses this intra-Region peering. Figure 3 above shows the architecture for connectivity between the AWS Transit Gateway and VMware Transit Connect. Learn how to configure intra-Region peering from VMware Managed Transit Gateway to AWS Transit Gateway in the VMware blog, “Getting Started with VMware Transit Connect Intra-Region Peering for VMware Cloud on AWS.”
It’s important to control route propagation to make sure that only the endpoint VPC, as well as the LZA operations account, can communicate with your VMware Cloud on AWS SDDC environment via the Transit Gateway. You’ll need to propagate the route table to enable communication between LZA and VMware Transit Connect. It’s important to note that the VMware Transit Connect does not propagate its routes to the LZA Transit Gateway by default, unless you are using the VMware Transit Connect Managed Prefix Lists.
This approach makes sure that all ingress and egress traffic goes through the perimeter firewall to be inspected. The orange dotted line in the Figure 3 diagram shows how all external connectivity from the VMware Cloud on AWS SDDC and LZA always passes through the perimeter VPC using an AWS Transit Gateway attachment.
Support communication privacy with DNS configuration for the SDDC
To make sure that you have communication privacy, use internal endpoints to communicate from your SDDC to the workload and services deployed in AWS. In your VMware Cloud on AWS vCenter management console, you can enter the IP addresses of the Amazon Route 53 DNS resolver information that has been configured in the LZA landing zone.
Conclusion
In this blog post, we’ve described the networking architecture you can use to deploy your VMware Cloud on AWS SDDC—while enabling communication with native AWS services that run AWS in an LZA landing zone and with the internet. With this, you can take full advantage of AWS native services, deploy workloads in two distinctive compute environments, and lower your operational overhead costs.
Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.
Please take a few minutes to share insights regarding your experience with the AWS Public Sector Blog in this survey, and we’ll use feedback from the survey to create more content aligned with the preferences of our readers.
Connectivité Accélérateur de Zone d’accueil sur AWS (LZA) avec VMware Cloud on AWS
La solution Accélérateur de zone d’accueil sur AWS (LZA) d’Amazon Web Services (AWS) déploie une fondation virtuelle qui est conçu pour s’harmoniser avec les bonnes pratiques de AWS et multiples cadres de conformité mondiaux. Les clients ayant des charges de travail hautement réglementées et des exigences de conformité complexes peuvent utiliser LZA pour mieux gérer et gouverner leur environnement multi-comptes. Lorsqu’il est utilisé en coordination avec d’autres services AWS, il offre une solution complète à faible code pour plus de 35 services AWS.
Certains clients utilisent également VMware Cloud on AWS pour intégrer des environnements vSphere sur place, ce qui leur permet de déplacer plus rapidement les charges de travail existantes vers le nuage. Si votre entreprise tire parti de ces services virtuels, l’intégration de votre charge de travail VMware aux services AWS gérés en mode natif peut vous aider à réduire vos frais généraux d’exploitation et à optimiser votre coût total de possession (TCO).
Dans ce blogue, nous passons en revue les considérations techniques liées à l’intégration de votre zone d’accueil LZA à votre VMware Cloud dans l’environnement AWS. Nous supposons que vous connaissez le déploiement de VMware Cloud Software Defined Data Center (SDDC), l’architecture de réseautage VMware Cloud on AWS et le déploiement de LZA.
Considérations importantes en matière de compte pour le VPC connecté
Premièrement, vous devez décider du compte que vous utiliserez pour le virtual private cloud (VPC) connecté au SDDC VMware pendant le déploiement de votre SDDC.
Dans ce blogue, nous donnons un exemple de zone d’accueil LZA, qui met en œuvre une ségrégation forte de vos comptes de développement, de test et de production par défaut. Cela signifie que la configuration de la table de routage de votre AWS Transit Gateway empêche ces comptes de communiquer entre eux pour des raisons de sécurité. Nous supposons dans la conception de l’architecture décrite dans cet article que vous avez l’intention d’intégrer VMware Cloud on AWS et LZA tout en respectant vos spécifications de sécurité existantes. La conformité appliquée au sein de l’environnement LZA ne s’étend pas automatiquement à VMware Cloud on AWS, de sorte que des étapes supplémentaires peuvent être nécessaires dans l’environnement VMware Cloud pour répondre aux exigences de conformité requises pour les charges de travail VMware SDDC.
En gardant ces considérations à l’esprit, le présent article fournit un exemple d’organisation qui a été créée à l’aide du service AWS Control Tower. Dans cet exemple, nous créons un compte AWS qui sera utilisé pour les charges de travail VPC connectées. La figure 1 suivante montre comment ce compte s’intègre à l’architecture LZA avec l’unité organisationnelle (UO) nommée « sddc » et le compte nommé « SDDC-Team1 » Vous pouvez déployer des comptes supplémentaires au besoin au sein de la même unité d’organisation si vous décidez de séparer davantage les charges de travail. Le « SDDC_Connected_VPC » dédié peut ensuite être déployé dans ces comptes AWS. Cette approche vous permet de définir des politiques de contrôle de service (SCP) spécifiques pour tous vos comptes AWS dans cette unité d’organisation. Cela permet de s’assurer que les services AWS natifs utilisés avec les charges de travail VMware peuvent être configurés indépendamment du reste de l’environnement LZA.
Figure 1. Comptes AWS structurés en unités organisationnelles (OU) sous le compte racine.
Une fois déployé, nous suggérons d’utiliser une approche de compte fonctionnel, comme l’illustre la figure 2, pour donner à diverses équipes un accès parallèle au « SDDC_Connected_VPC » tout en prenant en charge la capacité d’isoler certaines charges de travail dans des comptes particuliers. La figure 2 ci-dessous illustre un exemple de structure à comptes multiples qu’il est possible de créer lors du déploiement de LZA. Cette approche organisationnelle à comptes multiples illustre comment un client peut tirer parti du service AWS Organizations (OU et SCP) pour centraliser la gestion de plusieurs comptes AWS.
Figure 2. L’architecture prescriptive LZA, dans laquelle les équipes ont un accès distinct mais parallèle au VPC SDDC, ce qui permet d’isoler certaines charges de travail dans des comptes spécifiques.
Les trois voies de communication requises pour la connectivité LZA avec VMware Cloud
L’architecture d’interconnectivité de LZA avec VMware Cloud on AWS SDDC nécessite une planification minutieuse de votre architecture réseau. Les exigences techniques pour intégrer LZA à VMware Cloud on AWS sont les suivantes :
- Activer la communication entre les charges de travail VMware Cloud sur AWS SDDC et les services virtuels natifs d’AWS : par exemple, Amazon Simple Storage Service (Amazon S3) Amazon Relational Database Service (Amazon RDS), Amazon FSx ou Amazon Elastic File Systems (Amazon EFS).
- Permettre la communication pour la migration de charge de travail basée sur VMware VMotion et VMware HCX à partir des centres de données sur site vers VMware Cloud on AWS
- Permettre la communication de votre VMware Cloud on AWS SDDC vers Internet tout en prenant en charge l’inspection des paquets via le pare-feu AWS Network Firewall
Pour répondre à ces exigences, trois chemins de réseau de communication doivent être créés pour prendre en charge la communication entre VMware Cloud on AWS et l’environnement suivant :
- Du centre de données sur site au logiciel VMware Cloud on AWS SDDC
- Du compte AWS de charge de travail LZA utilisé pour le VPC (SDDC_Connected_VPC) au VMware Cloud on AWS SDDC
- De la passerelle de transit LZA AWS Transit Gateway déployée dans le compte réseautique partagé à VMware Transit Connect avec l’appairage « intra-region peering »
Figure 3. L’architecture de réseautique LZA, qui comprend l’architecture de connectivité entre la passerelle de transit AWS Transit Gateway et VMware Transit Connect. Les lignes pointillées orange, de l’utilisateur à travers la passerelle Internet, via la passerelle de transit AWS Transit Gateway et le SDDC_Connected_VPC, montrent comment toute la connectivité externe du nuage VMware sur le SDDC et le LZA passe toujours par le VPC périphérique à l’aide d’AWS Transit Gateway.
Chemin 1 : Connectivité sur place au VMware Cloud sur le SDDC d’AWS
Si vous déployez LZA et VMware Cloud on AWS, vous aurez besoin d’une connectivité dédiée de votre environnement sur place au nuage, au lieu d’utiliser une connexion Internet, pour une bande passante plus élevée, une latence plus faible et une expérience réseau uniforme pour vos utilisateurs. Dans notre architecture illustrée à la figure 4, nous utilisons également des connexions réseau redondantes AWS Direct Connect pour une connectivité hybride hautement disponible.
Figure 4. La passerelle AWS Direct Connect prend en charge la connectivité hybride depuis les centres de données sur site via le compte réseautique LZA jusqu’au compte VMware Cloud on AWS.
De plus, pour permettre une connectivité multirégionale, une interface virtuelle de transit (Transit VIF) sur le système de connexion AWS Direct Connect relie l’environnement sur site à une passerelle AWS Direct Connect Gateway. Cette passerelle AWS Direct Connect Gateway est ensuite associée à la passerelle de transit AWS Transit Gateway située dans le compte réseautique LZA dans une ou plusieurs régions.
Le service AWS Transit Gateway est hautement disponible de par sa conception, de sorte que nous n’avons pas besoin de déployer d’autres passerelles de transit pour la redondance. Pour en savoir plus sur AWS Transit Gateway et AWS Direct Connect.
AWS Transit Gateway est configurée avec un appairage « intra-region peering » avec VMware Transit Connect dans la même région pour fournir une connectivité sur site. En plus de communiquer avec les charges de travail VMware, vous pouvez utiliser des fonctions HCX comme HCX Network Extension pour étendre les réseaux de couche 2 de votre centre de données sur site existant au VMware Cloud on AWS SDDC. Les machines virtuelles qui ont été migrées à l’aide de HCX peuvent ensuite conserver les adresses IP et MAC (Media Access Control) pour une transition transparente vers l’exécution de charges de travail dans le nuage.
Il faut prendre soin de ne pas annoncer les mêmes routes sur différentes associations avec une passerelle AWS Direct Connect Gateway unique. En d’autres termes, le trafic réseau à destination et en provenance de VMware Cloud sur les services d’AWS et d’AWS Transit Gateway doit utiliser la même route lorsque vous communiquez avec votre centre de données.
Chemin 2 : VPC LZA SDDC connecté au SDDC VMware Cloud
Le « SDDC_Connected_VPC » de LZA est connecté au SDDC à l’aide d’interfaces de réseau élastiques déployées avec le SDDC. Ce « SDDC_Connected_VPC » peut être utilisé pour intégrer les services AWS aux machines virtuelles fonctionnant dans le SDDC. Ce lien à grande capacité et à faible latence est particulièrement important pour intégrer des services exigeants accès à de large quantité de données ou à des données sensibles avec accès à faible latence comme Amazon EFS, Amazon FSx, Amazon S3 ou Amazon RDS.
Vous pouvez également utiliser le « SDDC_Connected_VPC » pour exécuter des équilibreurs de charge élastiques permettant l’équilibrage de communication provenant d’Internet pour les machines virtuelles VMware dans le SDDC, conformément à l’architecture LZA. Apprenez-en plus sur l’augmentation des charges de travail VMware Cloud on AWS avec les services AWS natifs.
Chemin d’accès 3 : Connectivité aux services partagés et sortie Internet
Outre le trafic vers le « SDDC_Connected_VPC » et la connectivité sur site par le biais de l’appairage « intra-région peering » avec le VMware Transit Connect et LZA AWS Transit Gateway, l’architecture exige également que tout autre trafic soit envoyé à la passerelle LZA AWS Transit Gateway par l’intermédiaire de l’appairage « intra-region peering ».
Cela comprend le trafic vers tous les services partagés au sein de LZA, tels que les résolveurs de noms de domaine entrants (DNS) Amazon Route 53 et la communication avec d’autres VPC, la connectivité Internet pour les charges de travail au sein du SDDC traverse également cet appairage « intra-region peering ». La figure 3 ci-dessus illustre l’architecture de connectivité entre la passerelle de AWS Transit Gateway et VMware Transit Connect. Apprenez à configurer l’appairage « intra-region peering » de VMware Managed Transit Gateway à AWS Transit Gateway dans le blogue VMware intitulé « Getting Started with VMware Transit Connect Intra-Region Peering for VMware Cloud on AWS. »
Il est important de contrôler la propagation des routes pour s’assurer que seul le Endpoint VPC donnant accès aux services AWS, ainsi que le compte d’opérations LZA, peuvent communiquer avec votre environnement VMware Cloud on AWS SDDC via le AWS Transit Gateway. Vous devrez propager la table de routage pour permettre la communication entre LZA et VMware Transit Connect. Il est important de noter que VMware Transit Connect ne propage pas par défaut ses routes vers la passerelle de transit LZA, AWS Transit Gateway, sauf si vous utilisez les listes de préfixes gérés VMware Transit Connect.
Cette approche permet de s’assurer que tout le trafic d’entrée et de sortie passe par le pare-feu du périmètre afin d’être inspecté. La ligne pointillée orange du diagramme de la figure 3 montre comment toute la connectivité externe de VMware Cloud sur SDDC et LZA passe toujours par le VPC de périmètre à l’aide d’une connexion au AWS Transit Gateway.
Prise en charge de la confidentialité des communications avec la configuration DNS pour le SDDC
Pour vous assurer de la confidentialité des communications, utilisez des points de terminaison internes pour communiquer de votre SDDC à la charge de travail et aux services déployés dans AWS. Dans votre console de gestion VMware Cloud on AWS vCenter, vous pouvez entrer les adresses IP du service de résolution DNS Amazon Route 53 configurées dans la zone d’accueil LZA.
Conclusion
Dans ce blogue, nous avons décrit l’architecture réseau que vous pouvez utiliser pour déployer votre VMware Cloud on AWS SDDC, tout en permettant la communication avec les services AWS natifs s’exécutant dans une zone d’accueil LZA et avec Internet. Grâce à cela, vous pouvez tirer pleinement parti des services natifs d’AWS, déployer des charges de travail dans deux environnements informatiques distincts et réduire vos frais généraux d’exploitation.