Maîtriser le Développement Web sur AWS : Déploiement, Scalabilité et Services Cloud
Maîtriser le Développement Web sur AWS : Déploiement, Scalabilité et Services Cloud 
# Mise en Réseau Avancée et Sécurité de l'Infrastructure sur AWS

## Introduction

Bienvenue dans cette leçon dédiée à la mise en réseau avancée et à la sécurité de l'infrastructure sur AWS. Dans le cadre de notre cours "Maîtriser le Développement Web sur AWS : Déploiement, Scalabilité et Services Cloud", il est fondamental de comprendre que la performance, la résilience et surtout la sécurité de vos applications web dépendent intrinsèquement d'une architecture réseau bien conçue et sécurisée.

Alors que les leçons précédentes ont couvert les bases du déploiement d'applications web et la gestion des services fondamentaux, cette session plonge plus profondément dans les mécanismes qui permettent de :
*   **Connecter des réseaux complexes** sur AWS et avec vos infrastructures existantes.
*   **Optimiser les flux de trafic** pour de meilleures performances et une meilleure disponibilité.
*   **Protéger vos applications** contre les menaces courantes et sophistiquées.
*   **Gérer vos secrets et clés** de manière sécurisée.

Une infrastructure réseau robuste et sécurisée n'est pas un luxe, mais une nécessité absolue pour toute application web moderne souhaitant prospérer dans le cloud.

## 1. Mise en Réseau Avancée sur AWS

Au-delà des Virtual Private Clouds (VPC) et des subnets que nous connaissons déjà, AWS offre des outils puissants pour construire des architectures réseau plus complexes et interconnectées.

### 1.1. Interconnexion de VPC : VPC Peering et AWS Transit Gateway

Lorsqu'une application grandit ou que vous adoptez une architecture de microservices, il est courant d'avoir plusieurs VPC. Comment les faire communiquer de manière sécurisée et efficace sans exposer les ressources à l'internet public ?

#### 1.1.1. VPC Peering

Le VPC Peering permet de connecter deux VPC, qu'ils soient dans le même compte AWS ou dans des comptes différents, pour qu'ils puissent communiquer comme s'ils se trouvaient sur le même réseau privé.

*   **Fonctionnement :** Une connexion de peering est une connexion réseau un-à-un et non transitive. Cela signifie que si VPC A est peeré avec VPC B, et VPC B est peeré avec VPC C, VPC A ne peut pas communiquer directement avec VPC C via VPC B.
*   **Cas d'usage pour le web :**
    *   Connecter un VPC de développement à un VPC de production pour l'accès aux services partagés (ex: bases de données de test, systèmes de surveillance).
    *   Permettre à une application front-end (dans un VPC) d'accéder à un service backend (dans un autre VPC).
*   **Limites :** Non-transitif, ce qui rend la gestion complexe pour un grand nombre de VPC. Chaque paire de VPC nécessite une connexion de peering distincte.

#### 1.1.2. AWS Transit Gateway

Pour des topologies réseau plus complexes impliquant de nombreux VPC, AWS Transit Gateway est la solution privilégiée. C'est un *routeur cloud* centralisé qui simplifie la connectivité.

*   **Fonctionnement :** Il agit comme un hub central auquel tous vos VPC (et même vos réseaux on-premises via VPN ou Direct Connect) se connectent. La communication entre les VPC est transitive, ce qui signifie que chaque VPC n'a besoin que d'une seule connexion à la Transit Gateway pour communiquer avec n'importe quel autre VPC connecté.
*   **Avantages :**
    *   **Simplification :** Réduit le nombre de connexions de peering point-à-point.
    *   **Scalabilité :** Facilite l'ajout de nouveaux VPC.
    *   **Contrôle :** Permet une gestion centralisée des routages et des politiques de sécurité.
*   **Cas d'usage pour le web :**
    *   Architecture de microservices complexe où de nombreux VPC doivent communiquer.
    *   Environnements multi-comptes AWS ou hybrides où une passerelle centrale gère tout le trafic.
    *   Partage de services centralisés (ex: annuaire d'entreprise, outils de monitoring) avec tous les VPC de votre organisation.

### 1.2. Connectivité Hybride : AWS Direct Connect et AWS VPN

Pour les entreprises qui maintiennent des infrastructures sur site (on-premises) et veulent les connecter à leurs ressources AWS, Direct Connect et VPN sont essentiels.

*   **AWS Site-to-Site VPN :** Crée un tunnel VPN sécurisé entre votre réseau on-premises et votre VPC AWS via l'internet public. C'est une solution rentable pour démarrer ou pour des charges de travail moins critiques.
*   **AWS Direct Connect :** Établit une connexion réseau physique *dédiée* entre votre infrastructure on-premises et AWS. Il offre une bande passante plus élevée, une latence plus faible et une expérience réseau plus cohérente et fiable. Idéal pour les applications nécessitant un débit élevé ou une faible latence, comme la synchronisation de bases de données ou l'accès à des systèmes ERP on-premises.

### 1.3. Optimisation du Trafic et Performances Globales

#### 1.3.1. AWS Global Accelerator

Alors que les Application Load Balancers (ALB) dirigent le trafic vers les ressources *au sein d'une région*, AWS Global Accelerator est conçu pour améliorer la disponibilité et la performance des applications pour des utilisateurs *globaux*.

*   **Fonctionnement :** Il utilise le réseau mondial d'AWS (le "backbone" d'AWS) pour acheminer le trafic de vos utilisateurs vers le point d'entrée AWS le plus proche, puis vers votre application. Il fournit deux adresses IP statiques anycast qui agissent comme des points d'entrée fixes pour vos utilisateurs.
*   **Avantages :**
    *   **Performances :** Le trafic traverse le réseau AWS optimisé, réduisant la latence.
    *   **Disponibilité :** Améliore la résilience en acheminant automatiquement le trafic vers la ressource saine la plus proche en cas de panne régionale.
    *   **IP Statiques :** Simplifie la configuration DNS.
*   **Cas d'usage pour le web :** Applications web mondiales où chaque milliseconde compte, services d'API distribués.

#### 1.3.2. Routage Avancé avec Amazon Route 53

Route 53 n'est pas qu'un simple service DNS ; il offre des fonctionnalités de routage avancées pour améliorer la disponibilité et la performance.

*   **Politiques de routage :**
    *   **Weighted :** Distribue le trafic en fonction de poids spécifiés (ex: 80% vers la région A, 20% vers la région B). Utile pour les tests A/B ou les déploiements progressifs.
    *   **Latency :** Acheminera le trafic vers la ressource offrant la latence la plus faible pour l'utilisateur final.
    *   **Failover :** Bascule automatiquement le trafic vers une ressource secondaire en cas de défaillance de la ressource principale. Crucial pour la haute disponibilité.
    *   **Geolocation :** Route le trafic en fonction de la localisation géographique de l'utilisateur. Utile pour la conformité ou pour servir du contenu localisé.
*   **Private Hosted Zones :** Permet de gérer des noms de domaine DNS internes pour vos ressources AWS, accessibles uniquement depuis vos VPC. Essentiel pour la découverte de services dans des architectures complexes de microservices sans exposer les noms de domaines internes.

## 2. Sécurité de l'Infrastructure sur AWS

La sécurité est une responsabilité partagée entre AWS et vous. AWS sécurise le *cloud* (l'infrastructure sous-jacente), et vous êtes responsable de la sécurité *dans le cloud* (vos données, vos applications, la configuration de votre réseau).

### 2.1. Protection au Niveau Réseau : Security Groups et Network ACLs (NACLs)

Ces deux services sont les premières lignes de défense au niveau réseau.

*   **Security Groups (Groupes de Sécurité) :**
    *   **Fonctionnement :** Agissent comme des *pare-feu virtuels* au niveau de l'instance ou de l'interface réseau. Ils contrôlent le trafic entrant et sortant pour une ressource spécifique (ex: une instance EC2, un RDS).
    *   **Nature :** *Stateful*. Cela signifie que si vous autorisez le trafic entrant, le trafic de réponse sortant est automatiquement autorisé, et vice versa.
    *   **Règles :** Fonctionnent sur un principe d'*autorisation*. Vous spécifiez ce qui est autorisé ; tout le reste est implicitement refusé.
*   **Network Access Control Lists (NACLs) :**
    *   **Fonctionnement :** Agissent comme des pare-feu *sans état* au niveau du subnet. Ils contrôlent le trafic entrant et sortant pour *tout* le subnet.
    *   **Nature :** *Stateless*. Cela signifie que si vous autorisez le trafic entrant, vous devez *explicitement* autoriser le trafic de réponse sortant.
    *   **Règles :** Fonctionnent sur un principe d'*autorisation et de refus explicite*. Les règles sont évaluées dans l'ordre numérique, et la première règle qui correspond est appliquée. Une règle implicite de refus tout (deny all) est présente à la fin.
*   **Meilleure pratique :** Utiliser les Security Groups pour un contrôle fin au niveau de l'instance, et les NACLs pour une couche de sécurité supplémentaire et plus large au niveau du subnet, souvent pour bloquer explicitement certains types de trafic malveillant.

### 2.2. Protection des Applications Web : AWS WAF et AWS Shield

#### 2.2.1. AWS WAF (Web Application Firewall)

AWS WAF est un pare-feu applicatif qui vous aide à protéger vos applications web ou vos API contre les exploits web courants qui pourraient affecter la disponibilité, compromettre la sécurité ou consommer des ressources excessives.

*   **Fonctionnement :** Vous configurez des règles WAF pour filtrer le trafic HTTP/S. WAF s'intègre avec Amazon CloudFront (pour les applications distribuées), les Application Load Balancers (ALB) et les API Gateways.
*   **Menaces ciblées :**
    *   Injections SQL.
    *   Cross-Site Scripting (XSS).
    *   Requêtes de bot et web scrapers.
    *   Attaques par déni de service (DDoS) au niveau applicatif (couche 7).
    *   Tentatives d'accès non autorisé.
*   **Règles :** Vous pouvez utiliser des ensembles de règles gérés par AWS (ex: règles pour OWASP Top 10), des règles gérées par des vendeurs, ou créer vos propres règles personnalisées basées sur des conditions (adresses IP, en-têtes HTTP, corps de requête, URL, etc.).
*   **Actions :** Bloquer, autoriser, ou compter les requêtes.

#### 2.2.2. AWS Shield

AWS Shield fournit une protection contre les attaques par déni de service distribué (DDoS).

*   **Shield Standard :** Est activé par défaut pour tous les clients AWS, sans coût supplémentaire. Il offre une protection contre les attaques DDoS les plus courantes et les plus fréquentes (SYN/UDP floods, attaques par réflexion).
*   **Shield Advanced :** Un service payant offrant une protection DDoS plus robuste, notamment :
    *   Détection et atténuation améliorées.
    *   Protection contre les attaques complexes au niveau applicatif.
    *   Accès à l'équipe AWS DDoS Response Team (DRT) 24/7.
    *   Protection contre les pics de facturation causés par les attaques DDoS sur certains services (EC2, ELB, CloudFront, Route 53, Global Accelerator).
*   **Meilleure pratique :** Combiner WAF et Shield pour une protection complète contre les menaces DDoS et les exploits web. Shield Advanced protège les couches inférieures (3 et 4), tandis que WAF cible la couche applicative (7).

### 2.3. Gestion des Clés et Secrets : AWS KMS et AWS Secrets Manager

La gestion sécurisée des identifiants, clés d'API et autres secrets est primordiale pour toute application.

#### 2.3.1. AWS Key Management Service (KMS)

KMS est un service géré qui facilite la création et le contrôle des clés de chiffrement utilisées pour chiffrer vos données.

*   **Fonctionnement :** Permet de générer, stocker et gérer des clés cryptographiques, y compris les *Customer Master Keys (CMK)*. Ces clés peuvent être utilisées par d'autres services AWS (S3, RDS, EBS, Lambda, etc.) pour chiffrer vos données au repos ou en transit.
*   **Avantages :**
    *   **Contrôle centralisé :** Vous avez le contrôle total sur l'accès et l'utilisation de vos clés.
    *   **Intégration :** S'intègre nativement avec de nombreux services AWS, simplifiant le chiffrement.
    *   **Audit :** Toutes les opérations sur les clés sont enregistrées dans AWS CloudTrail.
*   **Cas d'usage :** Chiffrer les disques de vos instances EC2, les bases de données RDS, les objets S3, les messages SQS, etc.

#### 2.3.2. AWS Secrets Manager

Secrets Manager vous aide à protéger l'accès à vos applications, services et ressources en vous permettant de remplacer les informations d'identification codées en dur dans votre code par un appel d'API vers Secrets Manager.

*   **Fonctionnement :** Stocke vos secrets (identifiants de base de données, clés API, jetons OAuth) et peut les *faire pivoter (rotate)* automatiquement selon un calendrier ou un événement.
*   **Avantages :**
    *   **Rotation automatique :** Réduit le risque de compromission des secrets.
    *   **Intégration :** Facilement intégré dans votre code applicatif via SDK AWS.
    *   **Granularité :** Contrôle précis de l'accès aux secrets via IAM.
    *   **Audit :** Les accès et rotations sont enregistrés dans CloudTrail.
*   **Cas d'usage pour le web :** Stocker les mots de passe de bases de données (RDS, DocumentDB), les clés API de services tiers (ex: Stripe, Twilio), les identifiants pour des microservices.

### 2.4. Gestion des Identités et des Accès (IAM) Avancée

AWS Identity and Access Management (IAM) est la pierre angulaire de la sécurité sur AWS. Au-delà des bases, voici quelques aspects avancés :

*   **Principe du moindre privilège :** Toujours accorder aux utilisateurs et aux rôles uniquement les permissions nécessaires pour effectuer leurs tâches, et rien de plus. Évitez les permissions larges comme `*` ou `admin`.
*   **Rôles IAM pour les applications :** Plutôt que de stocker des identifiants AWS sur vos instances EC2 ou dans votre code Lambda, attribuez un *rôle IAM* à la ressource. Cela permet à la ressource d'obtenir des identifiants temporaires et sécurisés d'AWS STS (Security Token Service) pour accéder aux autres services AWS. C'est la meilleure pratique pour la sécurité.
*   **Authentification Multi-Facteurs (MFA) :** Activez toujours le MFA pour les utilisateurs racine et tous les utilisateurs IAM avec des privilèges élevés.
*   **AWS Organizations et Service Control Policies (SCPs) :** Pour les grandes organisations avec plusieurs comptes AWS, les SCPs permettent d'appliquer des garde-fous de sécurité au niveau de l'organisation, restreignant les permissions maximales que les utilisateurs peuvent avoir dans les comptes membres.
*   **IAM Access Analyzer :** Un outil qui identifie les ressources (buckets S3, rôles IAM, clés KMS, etc.) qui sont accessibles à des entités externes à votre compte, vous aidant à renforcer la sécurité.

## 3. Exemples Pratiques

Voici quelques exemples concrets pour illustrer les concepts abordés.

### 3.1. Configuration de VPC Peering via AWS CLI

Imaginons que vous avez deux VPC :
*   `vpc-0a1b2c3d4e5f67890` (MonVPC-App) avec CIDR `10.0.0.0/16`
*   `vpc-0f1e2d3c4b5a67890` (MonVPC-Data) avec CIDR `10.1.0.0/16`

Vous voulez que les instances de `MonVPC-App` puissent communiquer avec les bases de données dans `MonVPC-Data`.

```bash
# 1. Requête de la connexion de peering depuis MonVPC-App vers MonVPC-Data
# Remplacez <REGION> par votre région AWS (ex: eu-west-1)
# Remplacez <ACCOUNT_ID_DATA_VPC> par l'ID du compte propriétaire de MonVPC-Data
aws ec2 create-vpc-peering-connection \
    --vpc-id vpc-0a1b2c3d4e5f67890 \
    --peer-vpc-id vpc-0f1e2d3c4b5a67890 \
    --peer-owner-id <ACCOUNT_ID_DATA_VPC> \
    --region <REGION> \
    --tag-specifications 'ResourceType=vpc-peering-connection,Tags=[{Key=Name,Value=App-to-Data-Peering}]'

# Le résultat affichera un ID de connexion de peering, ex: pcx-0123456789abcdef0

# 2. Accepter la connexion de peering (peut être fait depuis le compte de MonVPC-Data si différent)
# Utilisez l'ID de connexion obtenu à l'étape 1
aws ec2 accept-vpc-peering-connection \
    --vpc-peering-connection-id pcx-0123456789abcdef0 \
    --region <REGION>

# 3. Mettre à jour les tables de routage (nécessaire dans les deux VPC)

# Pour MonVPC-App (table de routage de subnet où se trouve l'application)
# Ajoutez une route pour le CIDR de MonVPC-Data pointant vers la connexion de peering
# Trouvez votre table de routage principale ou spécifique au subnet
# aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-0a1b2c3d4e5f67890" --region <REGION>
aws ec2 create-route \
    --route-table-id rtb-0fedcba9876543210 \
    --destination-cidr-block 10.1.0.0/16 \
    --vpc-peering-connection-id pcx-0123456789abcdef0 \
    --region <REGION>

# Pour MonVPC-Data (table de routage de subnet où se trouve la base de données)
# Ajoutez une route pour le CIDR de MonVPC-App pointant vers la connexion de peering
# aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-0f1e2d3c4b5a67890" --region <REGION>
aws ec2 create-route \
    --route-table-id rtb-0abcdef1234567890 \
    --destination-cidr-block 10.0.0.0/16 \
    --vpc-peering-connection-id pcx-0123456789abcdef0 \
    --region <REGION>

# N'oubliez pas de mettre à jour les Security Groups des instances dans les deux VPC
# pour autoriser le trafic entrant/sortant entre les CIDR des VPC peerés.

Explication du code : Ce bloc de code AWS CLI montre les étapes fondamentales pour établir une connexion VPC Peering :

  1. create-vpc-peering-connection : Demande la création de la connexion de peering. Vous spécifiez les ID des deux VPC impliqués et l'ID du compte propriétaire du VPC "pair" si c'est un autre compte.
  2. accept-vpc-peering-connection : Accepte la connexion de peering. Cette étape est cruciale pour que la connexion devienne active.
  3. create-route : Mise à jour des tables de routage. C'est l'étape la plus souvent oubliée. Chaque VPC doit avoir une route dans sa table de routage qui indique que le trafic destiné au CIDR de l'autre VPC doit passer par la connexion de peering (pcx-...). Enfin, n'oubliez pas d'ajuster les Security Groups des ressources dans chaque VPC pour autoriser le trafic spécifique (ports, protocoles) entre les plages d'adresses IP des VPC.

3.2. Configuration d'une Règle AWS WAF pour bloquer une IP malveillante (CloudFormation)

Voici un exemple de modèle CloudFormation pour créer une Web ACL AWS WAFv2 et y ajouter une règle simple pour bloquer une adresse IP spécifique.

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS WAFv2 WebACL pour protéger une application web en bloquant une IP spécifique.

Parameters:
  WebACLName:
    Type: String
    Default: MyWebAppWAF
    Description: Nom de la WebACL WAF.
  Scope:
    Type: String
    Default: REGIONAL
    AllowedValues:
      - CLOUDFRONT
      - REGIONAL
    Description: >
      Portée de la WebACL. CLOUDFRONT pour une distribution CloudFront, REGIONAL pour ALB/API Gateway.
  BadIpAddress:
    Type: String
    Default: 1.2.3.4/32 # Exemple d'IP à bloquer
    Description: Adresse IP ou plage CIDR à bloquer.

Resources:
  MyWebACL:
    Type: AWS::WAFv2::WebACL
    Properties:
      Name: !Ref WebACLName
      Scope: !Ref Scope # CLOUDFRONT ou REGIONAL
      DefaultAction:
        Allow: {} # Par défaut, autoriser le trafic
      VisibilityConfig:
        CloudWatchMetricsEnabled: true
        MetricName: !Sub "${WebACLName}-Metric"
        SampledRequestsEnabled: true
      Rules:
        - Name: BlockSpecificIPRule
          Priority: 1
          Action:
            Block: {} # Bloquer les requêtes qui correspondent à cette règle
          Statement:
            IpSetReferenceStatement:
              Arn: !GetAtt MyIpSet.Arn # Référence à l'IpSet créé ci-dessous
          VisibilityConfig:
            CloudWatchMetricsEnabled: true
            MetricName: BlockSpecificIPMetric
            SampledRequestsEnabled: true

  MyIpSet:
    Type: AWS::WAFv2::IPSet
    Properties:
      Name: !Sub "${WebACLName}-BadIPs"
      Scope: !Ref Scope
      Addresses:
        - !Ref BadIpAddress
      IPAddressVersion: IPV4 # Ou IPV6 si nécessaire

Outputs:
  WebACLArn:
    Description: ARN de la WebACL créée.
    Value: !GetAtt MyWebACL.Arn
  WebACLId:
    Description: ID de la WebACL créée.
    Value: !Ref MyWebACL

Explication du code : Ce modèle CloudFormation déploie une Web ACL AWS WAFv2 avec une règle pour bloquer une IP spécifique :

  1. MyIpSet : Crée un IPSet qui est une liste d'adresses IP (ou de plages CIDR) que vous souhaitez gérer. Ici, nous définissons une seule adresse IP (BadIpAddress) par défaut.
  2. MyWebACL : Définit la Web ACL principale.
    • Scope : Indique où la Web ACL sera déployée (soit CLOUDFRONT pour une distribution CloudFront, soit REGIONAL pour un ALB ou une API Gateway).
    • DefaultAction : Spécifie l'action par défaut si aucune des règles ne correspond. Ici, c'est Allow, ce qui signifie que le trafic est autorisé par défaut.
    • Rules : Une liste des règles à appliquer. Notre règle BlockSpecificIPRule est la suivante :
      • Priority: 1 : Les règles sont évaluées dans l'ordre de priorité (plus le chiffre est bas, plus la priorité est élevée).
      • Action: Block : Si la condition de cette règle est remplie, la requête est bloquée.
      • Statement : C'est la condition de la règle. Ici, nous utilisons un IpSetReferenceStatement qui fait référence à notre MyIpSet. Cela signifie que toute requête provenant d'une adresse IP présente dans MyIpSet sera bloquée.
  3. VisibilityConfig : Active les métriques CloudWatch et les requêtes échantillonnées pour une meilleure visibilité et un meilleur débogage.

Pour lier cette Web ACL à votre Application Load Balancer, vous devriez ajouter une propriété WebAclArn à votre ressource AWS::ElasticLoadBalancingV2::LoadBalancer ou utiliser l'interface de gestion AWS.

4. Bonnes Pratiques et Considérations de Conception

  • Défense en profondeur : Ne vous fiez pas à une seule couche de sécurité. Combinez Security Groups, NACLs, WAF, Shield, IAM et chiffrement pour une protection multicouche.
  • Infrastructure as Code (IaC) : Utilisez CloudFormation, Terraform ou d'autres outils IaC pour définir et gérer vos ressources réseau et de sécurité. Cela garantit la cohérence, permet le versionnement et facilite l'audit.
  • Surveillance et journalisation : Activez et configurez CloudWatch Logs, VPC Flow Logs et AWS CloudTrail.
    • VPC Flow Logs : Enregistrez tous les flux de trafic IP vers et depuis les interfaces réseau dans votre VPC. Indispensable pour l'audit et le dépannage réseau et de sécurité.
    • CloudTrail : Suivez toutes les actions API effectuées dans votre compte AWS. Essentiel pour la conformité et la détection d'activités suspectes.
    • CloudWatch : Collectez les métriques et les logs pour surveiller l'état et la performance de votre infrastructure. Créez des alarmes pour être notifié des événements critiques.
  • Audits de sécurité réguliers : Utilisez des services comme AWS Security Hub, Amazon GuardDuty et Amazon Inspector pour évaluer et améliorer continuellement votre posture de sécurité.
  • Rotation des identifiants : Automatisez la rotation des secrets et des clés whenever possible, idéalement avec AWS Secrets Manager.
  • Plan de réponse aux incidents : Préparez-vous aux incidents de sécurité en ayant un plan clair sur la manière de détecter, de réagir et de récupérer.

Conclusion

La mise en réseau avancée et la sécurité de l'infrastructure sur AWS sont des domaines vastes et cruciaux pour le succès de toute application web dans le cloud. En maîtrisant des concepts tels que le VPC Peering, AWS Transit Gateway, WAF, Shield, KMS et Secrets Manager, vous êtes en mesure de construire des architectures plus complexes, plus performantes et, surtout, plus résilientes aux menaces.

Gardez à l'esprit que la sécurité n'est pas un état, mais un processus continu. Une veille technologique constante, des audits réguliers et une adhésion stricte aux bonnes pratiques sont indispensables pour maintenir un environnement AWS robuste et sécurisé pour vos applications web. Vous avez maintenant les outils et la compréhension nécessaires pour aller au-delà des configurations de base et bâtir des infrastructures de pointe sur AWS.