....Comment appairer aux mieux les ressources AWS entre différents VPC..Best Way to Share AWS Resources Between VPCs....

 

....

Comment appairer aux mieux les ressources AWS entre différents VPC

..

Best Way to Share AWS Resources Between VPCs

....

....

Vous êtes-vous déjà demandé quel était le meilleur moyen d’appairer vos ressources sur AWS? Cet article brosse un tableau sur la façon de partager des ressources AWS entre deux VPC ou plus. Bien qu’il existe de nombreuses autres solutions aux différents scénarios décrits ci-dessous, nous mettrons l’accent sur une manière simple et efficace de relier ces ressources entre elles.

Après quelques itérations sur AWS, la plupart des solutions donnent des résultats semblables au schéma ci-dessous. La solution est passée d’un VPC unique à un deuxième VPC, et la connexion à Internet et au centre de données centralisé de l’entreprise est établie. Alors qu’elle présente quelques inconvénients tels que présentés ci-après, cette solution a l’avantage de constituer une assise solide pour toute solution.

Les différents composants sont bien divisés dans des sous-réseaux logiques appropriés et la plupart peuvent communiquer entre eux selon les besoins. Pour les personnes qui connaissent moins bien les composants dans le diagramme ci-dessous, chaque VPC est composé de trois sous-réseaux.

Les composants du sous-réseau public accèdent directement à Internet via l’IGW (l’instance EC2 doit disposer d’une EIP !), le sous-réseau privé accède aux ressources Internet via une passerelle NAT résidant sur le sous-réseau public (doit également être associée à une EIP). La liaison avec les ressources sur site se réalise par Direct Connect (DX ci-dessous).

Cela suppose également que le réseau a été correctement configuré à l’aide du CIDR approprié pour votre organisation; en d’autres termes, il serait bon d’en discuter avec vos ingénieurs de réseau avant de passer au nuage.

..

Have you ever wondered what is the best way to interconnect your resources on AWS? This article will draw a picture from how to share AWS resources between two VPC’s to how you can share resources across multiple VPC’s. While many other solutions exist to resolve the different scenarios described here, we will focus on an efficient yet simple way to connect those resources together.

After a couple iterations on AWS, most solutions end up similar to the diagram below. The solution grew from a single VPC to a second VPC and connection to the Internet and the corporate data center has been established. While this solution has some inconveniences as we will describe below, it has the advantages of being a solid basis for any solution.

The different components are well separated in the right logical subnets and most of the components can talk to each other as needed. For people less familiar with the components in the diagram below, each VPC is composed of 3 subnets.

The public subnet components access the Internet through the IGW directly (EC2 must have an EIP!), the private subnet accesses Internet resources through a NAT gateway which resides in the public subnet (must also have an EIP associated). The connection with the on-prem resources is done through Direct Connect (DX below).

This assumes also that the network configuration has been done correctly using the right CIDR relevant to your organization, in other words, have a chat with your network engineers before jumping on the cloud. 

....

 
 
 

....

ILLUSTRATION 1 — NOUS SOMMES TOUS PASSÉS PAR LÀ . . .

..

Figure 1 - we’ve all been there . . .

....

 

....

Cependant, dans cette solution résident quelques inconvénients majeurs. L’accès aux ressources publiques dans AWS (S3, Kinesis, etc.) s’effectue par le biais d’Internet. Il vous faut donc veiller à ce que les itinéraires vers ces ressources soient disponibles depuis vos sous-réseaux privés via Internet. De plus, bien que les chemins d’accès du réseau se propagent facilement entre le centre de données sur site et chaque VPC, ces derniers ne peuvent communiquer directement entre eux.

..

This solution though has a few major inconveniences. AWS public resources (S3, Kinesis, etc) are accessed through the Internet which means that you must ensure that routes are available from your private subnets to those resources through the Internet. Also, while the network routes are easily propagated between the on-prem and each VPC, the VPC’s cannot talk between each other directly. ....

 

....

L’ACCÈS AUX RESSOURCES PUBLIQUES ET LE PARTAGE DES RESSOURCES VPC..

Accessing Public Resources and Sharing VPC Resources....

....

Le meilleur moyen d’accéder à des ressources publiques, telles que S3, est d’utiliser des points de terminaison d’un VPC. Il existe deux types de points de terminaison, soit d’interface et de passerelle. Un point de terminaison de passerelle crée une cible qui peut être utilisée dans une table de routage.

Pour accéder au point de terminaison via votre VPC, vous devez créer un chemin d’accès utilisant le nom de la ressource publique et le configurer vers le point de terminaison créé. Dans le diagramme ci-dessous, un point de terminaison de passerelle a été créé pour accéder au compartiment S3.

Pour davantage d’informations sur les points de terminaison de passerelle, suivre ce lien.

..

The best way to access public resources such as S3 is to use VPC Endpoints. There are two types of endpoints, Gateway and Interface endpoints. A gateway endpoint creates a target which can be used as part of a routing table.

To access the endpoint through your VPC, you need to create a route which uses the name of the public resource and map it to the endpoint that was created.  In the diagram below, a gateway endpoint was created to access the S3 bucket.

More on Gateway endpoints can be found here.

....

 
 
 

....

ILLUSTRATION 2 — RESTREINDRE L’ACCÈS PUBLIC À VOS S3

..

Figure 2 - No more public access to S3

....

 

....

Un point de terminaison d’interface permet d’établir une connexion TCP, à condition qu’elle soit précédée d’un équilibreur de charge réseau qui sera relié à un VPC en créant une interface réseau dans un sous-réseau spécifique. L’exemple ci-dessous décrit une instance de serveur SQL s’exécutant dans une instance RDS sur un VPC.  

Pour créer un point de terminaison d’interface, vous devez placer un équilibreur de charge réseau devant la base de données, créant ainsi une interface réseau sur le deuxième VPC. La base de données est alors directement accessible à l’aide de l’IP de l’interface réseau. Pour fins de sécurité, en ce qui a trait aux points de terminaison d’interface, les pratiques de groupe de sécurité habituelles s’appliquent puisqu’elles créent une interface réseau.

..

An Interface endpoint allows for any TCP connection, as long as it is fronted by a network load balancer to be linked to a VPC by create a network interface in a specific subnet. The example below describes a SQL Server instance running in RDS in a VPC.

To create an interface endpoint, we must front the database by a network load balancer which creates a network interface on the second VPC. The database can then be access directly using the network interface IP. For security purposes, for interface endpoints, since they create a network interface, standard security group practices apply. ....

 
 
 

....

Figure 3 - Interface Endpoint

..

ILLUSTRATION 3 — POINT DE TERMINAISON D’INTERFACE

....

 

....

UNE NOUVELLE TECHNOLOGIE AWS POUR RELIER PLUSIEURS VPC !

..

How to connect multiple VPC’s? New AWS tech! ....

....

Alors que le scénario ci-dessus offre une excellente solution pour accéder à des ressources spécifiques entre plusieurs VPC, elle ne résout pas le problème où plusieurs ressources VPC doivent pouvoir communiquer entre elles. Dans le scénario suivant, la création d’interfaces entre les VPC est relativement simple, mais dans le cas de solutions utilisant 100 ou 1 000 VPC, il est difficile de la faire évoluer.

Différentes solutions réseau, telles que la configuration d’un réseau en étoile, peuvent résoudre ce type de scénario qui, jusqu’à présent, était impossible à créer sur AWS. Lors de la conférence re:Invent, AWS a annoncé qu’une nouvelle passerelle de transit avait été créée pour résoudre ce problème.

La passerelle de transit permet de connecter les différents VPC et les ressources sur site (en utilisant VPN IPSEC pour le moment, Direct Connect à venir). La passerelle de transit crée une interface réseau dans chacun des VPC et propage les chemins d’accès entre les participants du réseau.

Cela permet de créer un modèle de réseau simplifié comme celui-ci :

..

While the solution above provides a solid solution to access specific resources across VPC, it doesn’t resolve the issue where multiple VPC’s resources must be able to talk with each other. In the scenario above, it is simple enough to create interfaces between VPC’s but for solutions using 100’s or 1000’s of VPC’s, it cannot be scaled easily.

Different network solutions such as building a hub-and-spoke network can resolve such scenarios, but until now there were no ways to build this out-of-the-box on AWS. AWS announced at Re:invent that a new Transit Gateway was created to solve this issue.

The Transit Gateway allows to connect the different VPC’s and on-prem (using IPSEC VPN for now, Direct Connect coming in the future). The Transit Gateway creates a network interface in each of the VPC and propagates the routes to each of the network participants.

This allows for a simplified network pattern such as the following:

....

 
 
 

....

ILLUSTRATION 4 – L’UTILISATION DE LA PASSERELLE DE TRANSIT

..

Figure 4 - Using Transit Gateway

....

 

....

Voici un article de blogue d’AWS qui fournit plus de détails. En espérant que cet article pour aidera à construire une meilleure infrastructure réseau sur AWS et que cette solution simplifiée vous évitera bien des maux de tête ! ..

Here’s a blog post from AWS that provides more detail. Hopefully this has helped you build a better network infrastructure on AWS and prevented some headaches caused by overcomplicating the solution! ....


....

ARTICLES DE BLOG RÉCENTS… ..

RECENT POSTS… ....


 
FR
EN