Table of contents
Considérations
Lors de la conception d'un VPC, l'une des premières choses que vous devez décider est la plage d'adresses IP que la VPC utilisera à l'avance.
- Quelle taille devrait avoir la VPC ?
Vous devez prendre en compte les autres réseaux (sur site, partenaires et fournisseurs) que vous utiliserez afin d'éviter les chevauchements, ce qui compliquerait la communication.
- Essayez de prévoir l'avenir
Il est nécessaire de considérer la structure de la VPC ; définissez des tiers (web
, applications
, bases de données
).
connaître les limites de la VPC :
VPC min /28
(16 IPs),VPC max /16
(65536 IPs).Essayez d'éviter les plages courantes (pour éviter les problèmes futurs)
Concevoir notre VPC
Pour décider quelle taille de VPC utiliser, il y a deux questions importantes :
Combien de sous-réseaux aurez-vous besoin ?
Combien d'adresses IP aurez-vous besoin au total ? Combien par sous-réseau ?
Pour décider combien de sous-réseaux utiliser, voici une méthode que j'utilise tout le temps :
Un sous-réseau est situé dans une seule zone de disponibilité
(AZ), vous devez donc définir combien de AZ votre VPC utilisera. Cette décision impactera la haute disponibilité (HA) et la résilience.
En plus des AZs à l'intérieur du VPC, vous avez également des niveaux (tiers) ; différents types d'infrastructures qui fonctionnent à l'intérieur de votre VPC.
Dans mon cas, voici mes considérations :
4 zones de disponibilité (AZ) (3 pour l'utilisation actuelle et 1 pour une utilisation future).
4 niveaux : Web, Application, Base de données et Tampon (Buffer).
Remarque: Dans le schéma ci-dessus je n’ai pas ajouté le AZ réservé à une éventuelle future utilisation, ni les sous-réseaux du tier réservé.
Implémentation
On pourrait faire l’implémentation via la console, le CLI ou mieux encore via un outil IaC (Infrastructure as Code). Dans notre cas nous allons utiliser terraform.
Vous pouvez directement vous référer à ce repo pour le code source.