AWS Secure Environment Accelerator (ASEA) connectivity with VMware Cloud on AWS

Lire cet article en français.

The Amazon Web Services (AWS) Secure Environment Accelerator (ASEA) landing zone helps customers deploy and operate a secure multi-account, multi-Region AWS environment, and is compatible with AWS Control Tower. The ASEA architecture addresses central identity and access management (IAM), governance, data security, comprehensive logging, and network design and segmentation, and meets the Canadian Centre for Cyber Security’s ITSG-33 specifications (a NIST 800-53 variant). Governments in Canada and others around the world currently use the ASEA, with over 30 deployments to date.

Some of these same customers are also using 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, we review the technical considerations related to integrating your ASEA 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 ASEA deployment and operation.

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.

When deploying ASEA, you inherit 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 ASEA while respecting your existing security specifications. The compliance enforced within the ASEA 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 explains how to create an organization using the AWS Organizations service and AWS account for the connected VPC workloads. Figure 1 below shows how this account fits into the ASEA 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 your AWS accounts 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 ASEA 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 that is typical when deploying ASEA. The ASEA prescriptive architecture graphic is posted in the ASEA GitHub repo. This multi-account organization approach shows how a customer can leverage the AWS Organizations services (OUs and SCP) to centralize management of multiple AWS accounts.

Figure 2. The ASEA 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 ASEA connectivity with VMware Cloud

The architecture for the ASEA integration with VMware Cloud on AWS SDDC requires careful planning for your network architecture. The technical requirements to integrate ASEA with VMware Cloud on AWS are:

• Enable connectivity with multiple AWS Regions
• Enable communication between VMware Cloud on AWS SDDC workloads and native AWS Cloud services: Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS), Amazon FSx, etc
• 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 Next Gen 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 data center to the VMware Cloud on AWS SDDC
2. From the ASEA workload AWS account used for the VPC (SDDC_connected_VPC) to the VMware Cloud on AWS SDDC
3. From the ASEA Transit Gateway deployed in the shared network account to the VMware Transit Connect with intra-region peering

Figure 3. The ASEA 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 ASEA always passes through the perimeter account using the AWS Transit Gateway attachment or IPsec VPN tunnels.

Path 1: On-premise connectivity to the VMware Cloud on AWS SDDC

If you’re deploying ASEA 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 data centers through the ASEA Shared 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 ASEA shared 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: ASEA SDDC connected VPC to the VMware Cloud SDDC

The “SDDC_connected_VPC” in the ASEA 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 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 ASEA 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 ASEA AWS Transit Gateway peering, the architecture also requires all other traffic to be sent to the ASEA AWS Transit Gateway through the intra-region peering.

This includes traffic to all shared services within the ASEA, 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 ASEA 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 ASEA and VMware Transit Connect. It’s important to note that the VMware Transit Connect does not propagate its routes to the ASEA Transit Gateway, so a static route must be added for all networks within the SDDC.

This approach makes sure that all ingress and egress traffic will go 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 ASEA always passes through the perimeter account using a AWS Transit Gateway attachment or IPsec VPN tunnels.

Support communication privacy with DNS configuration for the SDDC

To make sure that you have communication privacy, you’ll need to 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 ASEA.

Conclusion and learn more

In this blog post, we’ve described the networking architecture that you can use to deploy your VMware Cloud on AWS SDDC—while enabling communication with native AWS services that run AWS in an ASEA 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.

Download the sample infrastructure as code for the ASEA architecture from the GitHub repository. Read more about building a serverless web application architecture in the ASEA.

Do you have questions about the ASEA landing zone, how to integrate it with your VMware Cloud, or how to meet your compliance needs with AWS? Reach out to your AWS account manager, or contact the AWS Public Sector team directly.

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é entre AWS Secure Environment Accelerator et VMware Cloud sur AWS

La zone d’accueil ASEA (Secure Environment Accelerator) d’Amazon Web Services (AWS) aide les clients à déployer et à exploiter un environnement AWS multicomptes et multirégions sécurisé et est compatible avec AWS Control Tower. L’architecture de l’ASEA traite de la gestion centrale de l’identité et de l’accès (IAM), de la gouvernance, de la sécurité des données, de la journalisation complète, de la conception et de la segmentation du réseau, et répond aux spécifications ITSG-33 du Centre canadien de cybersécurité (une variante NIST 800-53). Les gouvernements du Canada et d’autres pays utilisent actuellement l’ASEA, avec plus de 30 déploiements à ce jour.

Certains de ces mêmes clients utilisent également VMware Cloud sur AWS pour intégrer des environnements vSphere sur site, ce qui leur permet de déplacer plus rapidement les charges de travail existantes vers le nuage. Si votre entreprise exploite ces services en nuage, l’intégration de votre charge de travail VMware aux services AWS gérés de manière native, peut vous aider à réduire vos frais généraux opérationnels et à optimiser votre coût total de possession (CTP).

Dans cet article de blogue, nous examinerons les considérations techniques liées à l’intégration de votre zone d’accueil ASEA à votre Cloud VMware dans l’environnement AWS. Nous supposerons que vous connaissez le déploiement de SDDC et les meilleures pratiques, l’architecture de réseautage VMware Cloud sur AWS ainsi que le déploiement et l’ exploitation de l’ASEA.

Considérations importantes relatives au compte pour le VPC connecté

Tout d’abord, choisissez le compte que vous utiliserez pour le cloud privé virtuel (VPC) connecté au SDDC VMware pendant le déploiement du SDDC.

Lors du déploiement de l’ASEA, vous hérité d’une solide isolation 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é. Dans la conception de l’architecture décrite dans cet article, nous supposons que votre intention est d’intégrer VMware Cloud sur AWS et ASEA tout en respectant vos spécifications de sécurité existantes. La conformité appliquée dans l’environnement ASEA ne s’étend pas automatiquement au VMware Cloud sur AWS, de sorte que des étapes supplémentaires peuvent être nécessaires dans l’environnement VMware Cloud sur AWS pour répondre aux exigences de conformité nécessaires pour les charges de travail VMware SDDC.

En gardant ces considérations à l’esprit, cet article explique comment créer une organisation à l’aide du service AWS Organizations et du compte AWS pour les charges de travail VPC connectées. La figure 1 ci-dessous montre comment ce compte s’intègre à l’architecture de l’ASEA, l’unité organisationnelle (UO) nommée « sddc » et le compte nommé « sddc-Equipe1 ». Vous pouvez déployer des comptes supplémentaires si nécessaire au sein de la même unité d’unité d’organisation si vous décidez de séparer davantage les charges de travail. Le VPC dédié connecté au SDDC peut ensuite être déployé dans ces comptes AWS. Cette approche vous permet de définir des politiques de contrôle des services (SCP) spécifiques pour vos comptes AWS au sein de votre organisation. Cela garantit que les services AWS natifs utilisés avec les charges de travail VMware peuvent être configurés indépendamment du reste de l’environnement ASEA.

Figure 1. Les comptes AWS sont structuré en unités organisationnelles (UO) sous le compte racine.

Une fois déployé, nous suggérons d’utiliser une approche de compte fonctionnelle telle qu’illustrée à la figure 2, pour donner à diverses équipes un accès parallèle au « SDDC_connected_VPC » tout en soutenant la capacité d’isoler certaines charges de travail dans des comptes particuliers. La figure 2 ci-dessous illustre une structure multicomptes qui est typique lors du déploiement de l’ASEA. Le graphique de l’architecture prescriptive de l’ASEA est affiché dans le dépôt GitHub de l’ASEA. Cette approche organisationnelle multicomptes illustre comment un client peut tirer parti du service AWS Organizations (UO et SCP) pour centraliser la gestion de plusieurs comptes AWS.

Figure 2. L’ architecture prescriptive de l’ASEA, dans laquelle les équipes ont un accès distinct mais parallèle au VPC de SDDC, ce qui permet d’isoler certaines charges de travail dans des comptes particuliers.

Les trois voies de communication requises pour la connectivité ASEA avec VMware Cloud

L’inter connectivité de l’ASEA avec VMware Cloud sur AWS SDDC nécessite une planification minutieuse de votre architecture réseau. Les exigences techniques pour intégrer ASEA à VMware Cloud sur AWS sont les suivantes :

• Activer la connectivité avec plusieurs régions AWS
• Activer la communication entre les charges de travail VMware Cloud sur AWS SDDC et les services cloud AWS natifs : Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS), Amazon FSx, etc.
• Activer la communication pour la migration des charges de travail VMware vMotion et VMware HCX des centres de données sur site vers VMware Cloud sur AWS
• Activez la communication de votre VMware Cloud sur AWS SDDC vers Internet tout en prenant en charge l’inspection des paquets du pare-feu de prochaine génération

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 sur AWS et l’environnement suivant :

1. Du centre de données sur site au SDDC VMware Cloud sur AWS

1. Du compte AWS de charge de travail ASEA utilisé pour le VPC (SDDC_connected_VPC) au SDDC VMware Cloud sur AWS
2. De la passerelle de transit (AWS Transit Gateway) ASEA déployée dans le compte réseau partagé au VMware Transit Connect avec appairage (peering) intra-région

Figure 3. L’architecture de réseau ASEA, qui comprend l’architecture de connectivité entre le AWS Transit Gateway et VMware Transit Connect. Les lignes pointillées orange de l’utilisateur via la passerelle Internet, via AWS Transit Gateway et vers le SDDC_connected_VPC montrent comment toute la connectivité externe de VMware Cloud sur AWS SDDC et ASEA passe toujours par le compte de périmètre à l’aide de la pièce jointe AWS Transit Gateway ou Tunnels VPN IPsec.

Chemin 1: Connectivité entre votre site et le VMware Cloud sur AWS SDDC

Si vous déployez ASEA et VMware Cloud sur AWS, vous aurez besoin d’une connectivité dédiée de votre environnement sur site au nuage, plutôt que d’utiliser une connexion Internet, pour une plus grande bande passante, une latence plus faible et une expérience réseau cohérente pour vos utilisateurs. Dans notre architecture illustrée à la figure 4, nous utilisons également des connexions réseau AWS Direct Connect redondantes pour une connectivité hybride hautement disponible.

Figure 4. La passerelle AWS Direct Connect prend en charge la connectivité hybride des centres de données sur site via le compte réseau partagé ASEA jusqu’au compte VMware Cloud sur AWS.

De plus, pour permettre la connectivité multi-régions, une interface virtuelle de transit (Transit VIF) sur AWS Direct Connect relie l’environnement sur site à une passerelle AWS Direct Connect. Cette passerelle AWS Direct Connect est ensuite associée à la passerelle de transit AWS située dans le compte réseau partagé ASEA dans une ou plusieurs régions.

La passerelle de transport AWS est hautement disponible par conception, de sorte que nous n’avons pas besoin de déployer d’autres passerelles de transport en commun pour la redondance. En savoir plus sur AWS Direct Connect et AWS Transit Gateway.

La passerelle de transit AWS Transit Gateway est configurée avec un « peering intra-région » avec le VMware Transit Connect dans la même région afin d’offrir une connectivité sur site. En plus de communiquer avec les charges de travail VMware, vous pouvez utiliser des fonctions HCX telles que HCX Network Extension pour étendre les réseaux de couche 2 de votre centre de données existant au VMware Cloud sur AWS SDDC. Les machines virtuelles qui ont été migrées à l’aide de HCX peuvent alors conserver les adresses IP et l’adresse d’infrastructure (MAC address) permet une transition transparente pour les charges de travail en cours d’exécution vers le nuage.

Il faut prendre soin de ne pas annoncer les mêmes routes sur différentes associations de passerelle avec une seule passerelle AWS Direct Connect. En d’autres termes, le trafic réseau à destination et en provenance de VMware Cloud sur AWS et AWS Transit Gateway doit utiliser la même route lorsque vous communiquez avec votre centre de données.

Chemin 2: VPC connecté au SDDC ASEA au VMware Cloud sur AWS SDDC

Le « SDDC_connected_VPC » de l’ASEA est connecté au SDDC à l’aide d’interfaces 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 exécutées dans le SDDC. Cette liaison à latence élevée et à faible latence est particulièrement importante pour l’intégration de services intensifs de données ou sensibles à la latence comme Amazon FSx, Amazon S3 ou Amazon RDS.

Vous pouvez également utiliser le « SDDC_connected_VPC » pour exécuter des équilibreurs de charge élastiques (ELB) pour l’équilibrage de charge d’entrée d’Internet pour les machines virtuelles VMware dans le SDDC, conformément à l’architecture ASEA. Pour en savoir plus sur l’augmentation des charges de travail VMware Cloud sur AWS grâce aux services AWS natifs.

Voie 3: Connectivité aux services partagés et sortie d’Internet

Outre le trafic vers le « SDDC_connected_VPC » et la connectivité vers votre site via l’intermédiaire de le « peering intra-région » VMware Transit Connect avec le peering ASEA AWS Transit Gateway, l’architecture exige également que tout autre trafic soit envoyé à l’ASEA AWS Transit Gateway par l’intermédiaire du peering intra-région.

Cela comprend le trafic vers tous les services partagés au sein de l’ASEA, tels que les résolveurs de système 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-région. La figure 3 ci-dessus illustre l’architecture de connectivité entre AWS Transit Gateway et VMware Transit Connect. Découvrez comment configurer l’appairage intra-région de VMware Managed Transit Gateway à AWS Transit Gateway dans le blog de VMware, « Mise en route avec VMware Transit Connect Intra-Region Peering pour VMware Cloud sur AWS ».

Il est important de contrôler la propagation des routes pour s’assurer que seul le point de terminaison d’un VPC, ainsi que le compte d’opérations ASEA, peuvent communiquer avec votre environnement VMware Cloud sur AWS SDDC via la passerelle Transit Gateway. Vous devez propager la table de routage pour permettre la communication entre ASEA et VMware Transit Connect. Il est important de noter que VMware Transit Connect ne propage pas ses routes vers la passerelle de transit AWS Transit Gateway ASEA, de sorte qu’une route statique doit être ajoutée pour tous les réseaux du SDDC.

Cette approche garantit que tout le trafic d’entrée et de sortie passe par le pare-feu du compte de périmètre pour y être inspecter. La ligne pointillée orange du diagramme de la figure 3 montre comment toute la connectivité externe de VMware Cloud sur AWS SDDC et ASEA passe toujours par le compte de périmètre à l’aide d’une connexion AWS Transit Gateway ou de tunnels VPN IPsec.

Prise en charge de la confidentialité des communications avec la configuration DNS pour le SDDC

Pour vous assurer que vous disposez de la confidentialité des communications, vous devrez utiliser des points de terminaisons 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 sur AWS vCenter, vous pouvez saisir les adresses IP des résolveurs DNS Amazon Route 53 configurées dans l’ASEA.

Conclusion

Dans cet article de blogue, nous avons décrit l’architecture réseau que vous pouvez utiliser pour déployer votre VMware Cloud sur AWS SDDC, tout en permettant la communication avec les services AWS natifs qui exécutent AWS dans une zone d’accueil ASEA et sur Internet. Grâce à cela, vous pouvez tirer pleinement parti des services natifs AWS, déployer des charges de travail dans deux environnements de calcul distincts et réduire vos coûts généraux opérationnels.