Les security groups pour le filtrage gratuit des couches 3 et 4 sur chaque interface réseau, AWS WAF pour les attaques de couche 7 visant vos endpoints HTTP publics, et AWS Network Firewall pour l'inspection à l'échelle du VPC et le contrôle des domaines sortants. Ces services ne sont pas concurrents : chacun se place à un point différent du chemin réseau et voit un trafic que les autres ne verront jamais. La plupart des stacks en production ont besoin des security groups et de WAF ; Network Firewall se justifie quand le filtrage sortant ou la conformité l'exigent.
Que bloquent réellement les security groups et les NACL ?
Les security groups filtrent le trafic par plage IP, port et protocole au niveau de l'interface réseau, en mode stateful : le trafic retour d'une connexion autorisée passe automatiquement. Les network ACL font le même travail à la frontière du subnet, en mode stateless, chaque sens exigeant une règle explicite. Les deux sont gratuits, opèrent aux couches 3 et 4, et ne lisent jamais le contenu.
Ce dernier point est celui que les équipes oublient. Un security group qui autorise le port 443 depuis Internet laissera passer une injection SQL, un bot de credential stuffing et un scraper : vus de la couche 4, ce ne sont que des connexions TCP valides vers un port ouvert. Traitez les security groups comme votre socle de refus par défaut, gardez-les stricts, et acceptez qu'ils répondent à « qui peut parler à qui », jamais à « que se disent-ils ». La référence officielle : la documentation des security groups VPC.
Qu'apporte AWS Network Firewall en plus ?
AWS Network Firewall est un point d'inspection managé à l'intérieur du VPC qui couvre les couches 3 à 7 : groupes de règles stateful, signatures compatibles Suricata pour la détection d'intrusion, filtrage par domaine ou par SNI TLS. Point décisif : c'est le seul service de ce trio capable d'empêcher une instance compromise d'appeler le domaine d'un attaquant sur le port 443.
Il se déploie sous forme d'endpoints de pare-feu, un par zone de disponibilité à protéger, vers lesquels les tables de routage dirigent le trafic. La forme du coût en découle : une facturation horaire par endpoint plus un tarif au Go de trafic inspecté, dus même en l'absence de trafic. C'est donc un mauvais choix pour un petit VPC isolé, et un choix raisonnable pour un VPC d'inspection mutualisé entre plusieurs workloads. Les détails sont sur la page de tarification de Network Firewall.
Où se situe AWS WAF ?
AWS WAF inspecte les requêtes HTTP là où votre application rencontre Internet : il s'attache aux distributions CloudFront, aux Application Load Balancers, à API Gateway et à AppSync. Il bloque ce que les couches inférieures ne voient pas : injection SQL, cross-site scripting, taux de requêtes abusifs, bots connus. Il ne voit jamais le TCP brut et ignore les protocoles non HTTP.
En pratique, on démarre avec les groupes de règles managés d'AWS (core rule set, known bad inputs, réputation IP), on ajoute des règles à seuil de débit par client ou par chemin, et on ne déploie Bot Control que si la pression des bots justifie son coût additionnel. La forme du coût : un montant mensuel fixe par web ACL et par règle, plus une facturation par million de requêtes ; voir la page de tarification de WAF. Ces règles à seuil se combinent naturellement avec les quotas par partenaire décrits dans notre article sur les SLA d'API partenaires.
Vous hésitez sur les couches qui manquent à votre stack ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Shield Standard suffit-il, ou faut-il Advanced ?
Shield Standard est gratuit, automatique et déjà actif : il absorbe les attaques DDoS courantes des couches 3 et 4 (SYN flood, réflexion UDP) pour tous les clients AWS. Shield Advanced est un abonnement payant avec engagement de longue durée : équipe de réponse dédiée, détection plus fine, et protection financière contre les factures de scaling provoquées par une attaque.
Pour la plupart des produits, Standard plus des règles WAF à seuil de débit constitue une base saine. Advanced mérite discussion quand l'indisponibilité se mesure en pénalités contractuelles, quand vous êtes une cible visible, ou quand la direction financière veut plafonner le coût d'une attaque. Les inclusions exactes évoluent : vérifiez les conditions en vigueur avant de vous engager.
Qui protège une stack serverless, et qui contrôle le trafic sortant ?
Pour une stack serverless, WAF est la couche qui compte : API Gateway, CloudFront et AppSync sont ses points d'attache natifs, et le trafic vers Lambda ou DynamoDB ne traverse aucun subnet que vous contrôlez. Y déployer Network Firewall est en général inutile : sans chemin de données dans un VPC, il n'a rien à inspecter.
Le trafic sortant est l'image inverse. Les security groups restreignent la sortie par IP et par port, mais pas par domaine ; WAF ne voit que les requêtes entrantes vers vos propres endpoints. Quand un auditeur vous demande de prouver qu'un workload ne peut appeler que trois API externes nommées, Network Firewall (ou un proxy explicite) est la seule réponse native AWS. Ordonner correctement ces couches fait partie de nos missions d'architecture AWS.
Tableau comparatif : couche, point d'attache, menaces, coût
Un tableau, trois services, cinq questions. Lisez d'abord la dernière ligne : « quand il gagne » est celle qui tranche la plupart des débats, car elle rend explicite que ces outils se complètent au lieu de se disputer le même rôle. Une stack mature en exploite généralement au moins deux sur trois.
| Security groups / NACL | AWS Network Firewall | AWS WAF | |
|---|---|---|---|
| Couche OSI | L3/L4 | L3 à L7 | L7 (HTTP/HTTPS) |
| Point d'attache | Interface réseau (SG), subnet (NACL) | Endpoints de pare-feu par AZ, via tables de routage | CloudFront, ALB, API Gateway, AppSync |
| Menaces typiques | Ports indésirables, mouvement latéral | Intrusions, sorties malveillantes, callbacks C2 | SQLi, XSS, bots, pics de requêtes |
| Forme du coût | Gratuit | Horaire par endpoint et par AZ, plus au Go inspecté | Mensuel par web ACL et par règle, plus par million de requêtes |
| Quand il gagne | Toujours actif : première ligne partout, à coût nul | Allowlists de sortie, IDS/IPS, conformité dans les parcs riches en VPC | Endpoints HTTP publics et stacks serverless |
Checklist de décision
- Security groups stricts et en refus par défaut partout : gratuit, non négociable, commencez ici.
- Endpoint HTTP public (ALB, CloudFront, API Gateway) ? Ajoutez WAF avec les règles managées et au moins une règle à seuil de débit.
- Stack serverless ? WAF oui, Network Firewall presque certainement non.
- Besoin de contrôler les domaines externes que vos workloads peuvent appeler ? Network Firewall : rien d'autre dans cette liste ne le fait.
- DDoS : Shield Standard est déjà actif ; ne chiffrez Shield Advanced que face à un risque d'indisponibilité contractuel.
- Revérifiez les points d'attache après chaque évolution d'architecture : un nouvel ALB arrive sans WAF par défaut.