Un Virtual Private Cloud (VPC) est un environnement réseau isolé dans AWS.

AWS VPC fournit un contrôle complet de la configuration réseau, y compris :

  • Gammes d'adresses IP
  • Sous-réseaux
  • Tables de routage
  • Passerelles réseau

Pour les déploiements SystemLink Enterprise, un VPC correctement configuré est essentiel pour la sécurité, l’évolutivité et l’isolation du réseau.

Configurez votre VPC pour isoler l'infrastructure de calcul et de stockage sur des sous-réseaux privés, distincts des passerelles et des équilibreurs de charge accessibles par Internet. Cette configuration suit les meilleures pratiques de sécurité du cloud et garantit que les charges de travail sensibles ne sont pas directement accessibles depuis Internet.

Pour une référence générale de l’architecture, reportez-vous au diagramme d'architecture Kubernetes d'AWS SystemLink Enterprise.

Architecture de sous-réseau

Configurez votre VPC avec des sous-réseaux publics et privés pour séparer les composants faisant face à Internet de l'infrastructure interne.

Déployez les composants suivants dans des sous-réseaux privés sans accès Internet direct :

  • Nœuds de cluster EKS : nœuds de machine hébergeant des pods SystemLink Enterprise, y compris des services Web, des applications Web et une infrastructure de support.
  • Bases de données : instances Amazon RDS pour PostgreSQL, ou instances de base de données autogérées.
  • Extrémités VPC pour S3 : utilisez les extrémités de passerelle VPC pour donner aux sous-réseaux privés un accès direct à Amazon S3 sans envoyer de trafic via Internet.

Déployez les composants suivants dans des sous-réseaux publics avec accès à une passerelle Internet :

  • Application Load Balancers (ALB): équilibreurs de charge orientés vers Internet pour le trafic HTTPS vers l'application Web et l'API SystemLink
  • Network Load Balancers (NLB) : équilibreurs de charge TCP pour le trafic Salt Master (ports 4505 et 4506)
  • Passerelles NAT : activez l'accès Internet sortant pour les ressources des sous-réseaux privés.

Planification par blocs CIDR

Planifiez vos blocs CIDR VPC pour garantir des adresses IP suffisantes pour SystemLink Enterprise et la croissance future.

  • Taille de VPC recommandée : le bloc CIDR /16 (65 536 adresses IP) offre une flexibilité de mise à l'échelle
  • Taille minimale du VPC : bloc CIDR /20 (4 096 adresses IP) pour les déploiements de taille plus petite à moyenne

Allouez les sous-réseaux en fonction des considérations suivantes :

  • Sous-réseaux privés pour les nœuds EKS : taille basée sur le nombre maximal de nœuds attendu. Chaque nœud EKS requiert une adresse IP du sous-réseau CIDR.
  • Sous-réseaux privés pour pods : si vous utilisez un réseau personnalisé ou le mode personnalisé VPC CNI, allouez des sous-réseaux supplémentaires pour les adresses IP de pod. Chaque pod requiert sa propre adresse IP.
    • Commencez par la configuration CNI VPC par défaut où les pods partagent des sous-réseaux de nœuds, sauf si vous avez des exigences spécifiques pour l'isolation réseau au niveau des pods.
    • Surveillez attentivement l'utilisation de l'IP. Chaque nœud peut consommer entre 10 et 100 adresses IP selon le type d'instance EC2.
    • Planifier la croissance. Assurez-vous que le redimensionnement du sous-réseau peut supporter une mise à l'échelle importante de votre charge de travail.
  • Sous-réseaux publics : une allocation plus petite, telle que /24, est suffisante pour les répartiteurs de charge et les passerelles NAT.
  • Déploiement multi-AZ : créez des paires de sous-réseaux (public/privé) dans au moins deux zones de disponibilité pour une haute disponibilité.
Tableau 53. Exemple d'allocation CIDR (VPC Using 10.0.0.0/16)
Type de sous-réseau Zone de disponibilité Bloc CIDR IP disponibles
Privé (nœuds EKS) us-est-1a 10.0.0.0/19 8,192
Privé (nœuds EKS) us-est-1b 10.0.32.0/19 8,192
Privé (bases de données) us-est-1a 10.0.64.0/24 256
Privé (bases de données) us-est-1b 10.0.65.0/24 256
Public us-est-1a 10.0.128.0/24 256
Public us-est-1b 10.0.129.0/24 256
Remarque AWS réserve les quatre premières adresses IP et la dernière adresse IP de chaque sous-réseau. Planifiez en conséquence lors du calcul des adresses disponibles.

Meilleures pratiques de sécurité

Respectez les bonnes pratiques de sécurité suivantes lorsque vous configurez votre VPC pour SystemLink Enterprise :

  • Pas d'accès Internet direct pour le calcul et le stockage : tous les nœuds, bases de données et services internes EKS doivent résider dans des sous-réseaux privés sans route de passerelle Internet.
  • Isolation du flux de trafic: le trafic Internet passe par Internet, l'ALB/NLB public, le contrôleur d'entrée Kubernetes privé (sous-réseau privé), puis les services SystemLink privés.
  • Internet sortant via NAT : utilisez des passerelles NAT dans des sous-réseaux publics pour fournir un accès Internet sortant aux ressources de sous-réseaux privés. Déployez une passerelle NAT par zone de disponibilité pour une haute disponibilité.
  • Extrémités VPC : utilisez des extrémités VPC pour les services AWS (S3) pour éviter le routage Internet et réduire les coûts de transfert de données.
  • Groupes de sécurité : configurez les groupes de sécurité pour n'autoriser que le trafic nécessaire entre les composants. Utilisez le principe du moindre privilège.

Considérations relatives à la zone de disponibilité

Déployez SystemLink Enterprise sur plusieurs zones de disponibilité pour une haute disponibilité et une tolérance aux pannes :

  • Déploiement minimum : utilisez au moins deux zones de disponibilité avec des paires de sous-réseaux dans chaque zone.
  • Groupes de nœuds EKS : répartissez les nœuds de machinerie sur les zones de disponibilité.
  • Database Multi-AZ : activez les déploiements Multi-AZ pour RDS PostgreSQL et DocumentDB.
  • Distribution de l'équilibreur de charge : configurez ALB et NLB pour répartir le trafic sur des sous-réseaux dans plusieurs zones de disponibilité.