2.3 - Conception applicative sécurisée et découplée (WAF, Secrets Manager, VPC endpoints)
L'objectif 2.3 de l'AWS Solutions Architect Professional couvre la conception de solutions neuves sécurisées, serverless et découplées. Tu exécutes des conteneurs sans gérer d'hôtes sur le launch type AWS Fargate, tu laisses des utilisateurs mobiles authentifiés téléverser directement vers S3 via un identity pool Cognito qui émet des identifiants temporaires cadrés, et tu protèges une API REST publique avec une web ACL AWS WAF plus des usage plans et clés d'API pour le throttling par client. Un microservice récupère un mot de passe de base au runtime depuis AWS Secrets Manager avec rotation automatique, et une appli dans un sous-réseau privé sans route Internet atteint S3 et DynamoDB via des VPC gateway endpoints. Le chiffrement de bout en bout utilise un listener HTTPS qui transfère vers un target group HTTPS, la charge relationnelle en pics convient à Aurora Serverless v2, un pipeline IoT associe Firehose pour la livraison S3 tamponnée à Kinesis Data Streams pour la relecture multi-lecture, et le routage geolocation fixe les utilisateurs allemands sur eu-central-1. Attends-toi à des mises en situation sur les conteneurs serverless, les secrets au runtime ou l'accès privé aux services, et à choisir la bonne conception sécurisée.
Conteneurs sans hôtes à gérer = AWS Fargate. Récupérer et faire tourner auto un mot de passe de base au runtime = rotation Secrets Manager. Sous-réseau privé qui atteint S3/DynamoDB sans route Internet = VPC gateway endpoints.
Questions d'entraînement
1. Des microservices dans un VPC doivent appeler Amazon S3 et DynamoDB sans qu'aucun trafic ne quitte le réseau AWS et sans coûts de NAT. Que doit utiliser l'architecte ?
- Des interface VPC endpoints (PrivateLink) avec une Elastic IP chacun
- Une NAT gateway par AZ avec des routes vers S3 et DynamoDB
- Des gateway VPC endpoints pour S3 et DynamoDB (bonne réponse)
- Une flotte de proxys qui signent les requêtes et les relaient publiquement
S3 et DynamoDB s'atteignent en privé via des gateway VPC endpoints, qui ajoutent des routes de prefix-list sans frais horaires/données ni NAT. Les interface endpoints existent pour beaucoup de services, mais S3/DynamoDB utilisent spécifiquement les gateway endpoints ; la NAT ferait sortir le trafic et coûterait.
2. Une nouvelle application web publique tourne derrière un Application Load Balancer. Les architectes veulent imposer de façon centralisée un jeu de règles WAF commun sur celui-ci et sur tous les futurs ALB et distributions CloudFront de l'organisation, automatiquement. Quel service la conception doit-elle utiliser ?
- Une seule web ACL AWS WAF que chaque équipe doit attacher manuellement à chaque ressource
- Des listes de menaces Amazon GuardDuty exportées vers chaque compte et référencées par les security groups
- Des politiques AWS Firewall Manager appliquées sur les comptes membres d'AWS Organizations (bonne réponse)
- Une règle AWS Config qui signale tout load balancer créé sans web ACL attachée
Firewall Manager applique et auto-remédie des web ACL WAF à l'échelle de l'organisation, y compris sur les ressources créées ensuite, depuis une seule politique. L'attache manuelle ne passe pas à l'échelle et s'oublie ; les listes GuardDuty servent à la détection, pas au filtrage en ligne ; une règle Config ne fait que détecter et signaler la dérive, sans imposer les règles.
3. Une nouvelle API de jeu sur un Network Load Balancer est une cible probable de DDoS. Objectifs de conception : absorber d'importants flots de couche 3/4, disposer d'une équipe d'intervention dédiée et bénéficier d'une protection des coûts liés à la mise à l'échelle causée par une attaque. Que doit inclure l'architecture ?
- Seulement les protections permanentes qu'AWS Shield Standard offre par défaut à tous les clients
- AWS Shield Advanced activé sur l'endpoint avec l'équipe SRT mobilisée et la protection des coûts (bonne réponse)
- Un type d'instance NLB plus grand avec drainage des connexions et timeouts d'inactivité généreux
- Un parc de NAT gateways devant le NLB pour absorber et limiter le débit du trafic de flood entrant
Shield Advanced ajoute une atténuation renforcée en couche 3/4, l'accès à la Shield Response Team (SRT) et une protection des coûts qui rembourse les frais de mise à l'échelle d'une attaque couverte. Shield Standard n'a ni SRT ni protection des coûts ; un NLB n'a pas de type d'instance à redimensionner ; les NAT gateways servent au trafic sortant et n'absorbent pas un DDoS entrant.
4. Une équipe conteneurise une API web et veut l'exécuter sur Amazon ECS sans provisionner, corriger ni mettre à l'échelle d'hôtes EC2, en ne payant que le vCPU et la mémoire consommés par chaque tâche. Quel type de lancement convient ?
- Le type de lancement EC2 avec un Auto Scaling group géré d'instances de conteneurs
- Le type de lancement EC2 avec une AMI optimisée ECS et des capacity providers de cluster
- Un type de lancement externe exécutant les tâches sur des serveurs sur site enregistrés
- Le type de lancement AWS Fargate exécutant les tâches en mode serverless (bonne réponse)
Fargate exécute les tâches ECS sans hôte EC2 à gérer et facture par vCPU et mémoire de tâche, ce qui répond au besoin sans serveur et paiement à la tâche. Toutes les options de lancement EC2 imposent de posséder et mettre à l'échelle les instances sous-jacentes, et le type externe vise votre propre matériel.
5. Une organisation a beaucoup investi dans l'outillage Kubernetes et veut cet écosystème sur AWS, mais son équipe plateforme refuse de gérer des worker nodes pour un ensemble de jobs courts et à pics. Quelle approche respecte les deux contraintes ?
- Exploiter un cluster Kubernetes auto-géré sur EC2 réparti sur plusieurs zones de disponibilité
- Utiliser Amazon EKS avec des profils Fargate pour que ces pods s'exécutent sans nœuds gérés (bonne réponse)
- Sortir totalement les jobs de Kubernetes et les réécrire en simples scripts batch EC2
- Utiliser Amazon ECS sur EC2 avec un Auto Scaling group de cluster pour les jobs à pics
EKS conserve l'API et l'outillage Kubernetes dont l'équipe dépend, et les profils Fargate planifient les pods correspondants sur une capacité serverless, donc aucun worker node à gérer pour ces jobs à pics. Un cluster auto-géré ou ECS-sur-EC2 implique toujours des nœuds, et abandonner Kubernetes jette l'investissement existant.
6. Une charge batch ECS tolère les pannes et est sensible au coût, mais une petite portion de tâches doit toujours rester active pour servir des requêtes sensibles à la latence. L'équipe veut qu'ECS place la plupart des tâches sur de la capacité interruptible bon marché et une base sur de la capacité stable. Que doit-elle configurer ?
- Uniquement de la capacité Fargate Spot pour chaque tâche afin de minimiser la facture de calcul totale
- Uniquement des instances EC2 On-Demand pour qu'aucune tâche ne soit jamais interrompue
- Un unique achat de Reserved Instance couvrant toute la flotte de batch
- Une stratégie de capacity provider mêlant Fargate Spot avec une base Fargate à la demande (bonne réponse)
Une stratégie de capacity provider permet de définir une base de Fargate à la demande pour les tâches critiques toujours actives et un poids qui envoie le gros vers du Fargate Spot moins cher, équilibrant coût et fiabilité. Tout en Spot risque d'interrompre la base critique, tout en On-Demand gaspille, et une seule RI ne pilote pas le placement des tâches ECS.