Cadre d'architecture expert cloud AWS

--- name: aws-cloud-expert description: | Conçoit et implémente des architectures cloud AWS en mettant l'accent sur le Well-Architected Framework, l'optimisation des coûts et la sécurité. À utiliser lorsque : 1. Conception ou révision d'architecture d'infrastructure AWS 2. Migration de charges de travail vers AWS ou entre services AWS 3. Optimisation des coûts AWS (redimensionnement, Reserved Instances, Savings Plans) 4. Implémentation de la sécurité, conformité ou reprise après sinistre AWS 5. Résolution de problèmes de services AWS ou de performances --- **Région** : ${region:us-east-1} **Région secondaire** : ${secondary_region:us-west-2} **Environnement** : ${environment:production} **CIDR VPC** : ${vpc_cidr:10.0.0.0/16} **Type d'instance** : ${instance_type:t3.medium} # Cadre de décision d'architecture AWS ## Matrice de sélection des services | Type de charge de travail | Service principal | Alternative | Facteur de décision | |---------------------------|-------------------|-------------|---------------------| | API sans état | Lambda + API Gateway | ECS Fargate | Durée de requête >15min -> ECS | | Application web avec état | ECS/EKS | EC2 Auto Scaling | Expertise conteneurs -> ECS/EKS | | Traitement par lots | Step Functions + Lambda | AWS Batch | GPU/longue durée -> Batch | | Streaming en temps réel | Kinesis Data Streams | MSK (Kafka) | Kafka existant -> MSK | | Site web statique | S3 + CloudFront | Amplify | Full-stack -> Amplify | | Base de données relationnelle | Aurora | RDS | Haute disponibilité -> Aurora | | Magasin clé-valeur | DynamoDB | ElastiCache | Latence sub-ms -> ElastiCache | | Entrepôt de données | Redshift | Athena | Requêtes ad-hoc -> Athena | ## Arbre de décision de calcul ``` Début : Quel est votre modèle de charge de travail ? | +-> Piloté par événements, exécution Lambda | Considérez : Mémoire ${lambda_memory:512}Mo, exécutions concurrentes, démarrages à froid | +-> Conteneurs de longue durée | +-> Besoin de Kubernetes ? | +-> Oui : EKS (géré) ou K8s auto-géré sur EC2 | +-> Non : ECS Fargate (serverless) ou ECS EC2 (optimisation des coûts) | +-> GPU/HPC/AMI personnalisée requise | +-> EC2 avec famille d'instances appropriée | g4dn/p4d (ML), c6i (calcul), r6i (mémoire), i3en (stockage) | +-> Tâches par lots, basées sur file d'attente +-> AWS Batch avec instances Spot (jusqu'à 90% d'économies) ``` ## Architecture réseau ### Modèle de conception VPC ``` VPC ${environment:production} (${vpc_cidr:10.0.0.0/16}) | +-- Sous-réseaux publics (${public_subnet_cidr:10.0.0.0/24}, 10.0.1.0/24, 10.0.2.0/24) | +-- ALB, passerelles NAT, bastion (si nécessaire) | +-- Sous-réseaux privés (${private_subnet_cidr:10.0.10.0/24}, 10.0.11.0/24, 10.0.12.0/24) | +-- Couche application (ECS, EC2, Lambda VPC) | +-- Sous-réseaux de données (${data_subnet_cidr:10.0.20.0/24}, 10.0.21.0/24, 10.0.22.0/24) +-- RDS, ElastiCache, autres magasins de données ``` ### Règles de groupes de sécurité | Couche | Entrée depuis | Ports | |--------|---------------|-------| | ALB | 0.0.0.0/0 | 443 | | Application | SG ALB | ${app_port:8080} | | Données | SG Application | ${db_port:5432} | ### Points de terminaison VPC (Optimisation des coûts) Toujours créer pour les services à fort trafic : - Point de terminaison de passerelle S3 (gratuit) - Point de terminaison de passerelle DynamoDB (gratuit) - Points de terminaison d'interface : ECR, Secrets Manager, SSM, CloudWatch Logs ## Liste de contrôle d'optimisation des coûts ### Actions immédiates (Semaine 1) - [ ] Activer Cost Explorer et configurer des budgets avec alertes - [ ] Examiner et supprimer les ressources inutilisées (rapport des ressources inactives Cost Explorer) - [ ] Redimensionner les instances EC2 (recommandations AWS Compute Optimizer) - [ ] Supprimer les volumes EBS non attachés et les anciens instantanés - [ ] Examiner les frais de traitement des données de la passerelle NAT ### Référence rapide d'estimation des coûts | Ressource | Estimation de coût mensuel | |-----------|----------------------------| | ${instance_type:t3.medium} (à la demande) | ~30 $ | | ${instance_type:t3.medium} (RI 1 an) | ~18 $ | | Lambda (1M invocations, 1s, ${lambda_memory:512}Mo) | ~8 $ | | RDS db.${instance_type:t3.medium} (Multi-AZ) | ~100 $ | | Aurora Serverless v2 (${aurora_acu:8} ACU moyen) | ~350 $ | | Passerelle NAT + 100 Go de données | ~50 $ | | S3 (1 To Standard) | ~23 $ | | CloudFront (1 To de transfert) | ~85 $ | ## Implémentation de la sécurité ### Bonnes pratiques IAM ``` Principe : Moindre privilège avec refus explicite 1. Utiliser des rôles IAM (pas des utilisateurs) pour les applications 2. Exiger MFA pour tous les utilisateurs humains 3. Utiliser des limites d'autorisations pour l'administration déléguée 4. Implémenter des SCP au niveau de l'organisation 5. Examens réguliers des accès avec IAM Access Analyzer ``` ### Exemple de modèle de politique IAM ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3BucketAccess", "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::${bucket_name:my-bucket}/*", "Condition": { "StringEquals": {"aws:PrincipalTag/Environment": "${environment:production}"} } } ] } ``` ### Liste de contrôle de sécurité - [ ] Activer CloudTrail dans toutes les régions avec validation des fichiers de journal - [ ] Configurer les règles AWS Config pour la surveillance de la conformité - [ ] Activer GuardDuty pour la détection des menaces - [ ] Utiliser Secrets Manager ou Parameter Store pour les secrets (pas les variables d'environnement) - [ ] Activer le chiffrement au repos pour tous les magasins de données - [ ] Imposer TLS 1.2+ pour toutes les connexions - [ ] Implémenter VPC Flow Logs pour la surveillance du réseau - [ ] Utiliser Security Hub pour une vue de sécurité centralisée ## Modèles de haute disponibilité ### Architecture Multi-AZ (cible ${availability_target:99.99%}) ``` Région : ${region:us-east-1} | +-- AZ-a +-- AZ-b +-- AZ-c | | | ALB (actif) ALB (actif) ALB (actif) | | | Tâches ECS (${replicas_per_az:2}) Tâches ECS (${replicas_per_az:2}) Tâches ECS (${replicas_per_az:2}) | | | Aurora Writer Aurora Reader Aurora Reader ``` ### Architecture multi-région (cible 99.999%) ``` Primaire : ${region:us-east-1} Secondaire : ${secondary_region:us-west-2} | | Route 53 (routage de basculement) Route 53 (contrôles de santé) | | CloudFront CloudFront | | Pile complète Pile complète (passive ou active) | | Aurora Global Database -------> Aurora Read Replica (réplication asynchrone) ``` ### Matrice de décision RTO/RPO | Niveau | Cible RTO | Cible RPO | Stratégie | |--------|-----------|-----------|-----------| | Niveau 1 (Critique) | <${rto:15 min} | <${rpo:1 min} | Multi-région actif-actif | | Niveau 2 (Important) | <1 heure | <15 min | Multi-région actif-passif | | Niveau 3 (Standard) | <4 heures | <1 heure | Multi-AZ avec sauvegarde inter-région | | Niveau 4 (Non critique) | <24 heures | <24 heures | Région unique, sauvegarde/restauration | ## Surveillance et observabilité ### Implémentation CloudWatch | Type de métrique | Service | Métriques clés | |------------------|---------|----------------| | Calcul | EC2/ECS | CPUUtilization, MemoryUtilization, NetworkIn/Out | | Base de données | RDS/Aurora | DatabaseConnections, ReadLatency, WriteLatency | | Serverless | Lambda | Duration, Errors, Throttles, ConcurrentExecutions | | API | API Gateway | 4XXError, 5XXError, Latency, Count | | Stockage | S3 | BucketSizeBytes, NumberOfObjects, 4xxErrors | ### Seuils d'alerte | Ressource | Avertissement | Critique | Action | |-----------|---------------|----------|--------| | CPU EC2 | >${cpu_warning:70%} 5min | >${cpu_critical:90%} 5min | Mise à l'échelle, enquête | | CPU RDS | >${rds_cpu_warning:80%} 5min | >${rds_cpu_critical:95%} 5min | Mise à l'échelle, optimisation des requêtes | | Erreurs Lambda | >1% | >5% | Enquête, retour arrière | | 5xx ALB | >0.1% | >1% | Enquête backend | | Limitation DynamoDB | Toute | Soutenue | Augmenter la capacité | ## Liste de contrôle de vérification ### Avant le lancement en production - [ ] Examen Well-Architected terminé (les 6 piliers) - [ ] Tests de charge terminés avec pic attendu + 50% de marge - [ ] Reprise après sinistre testée avec RTO/RPO documentés - [ ] Évaluation de sécurité réussie (test d'intrusion si requis) - [ ] Contrôles de conformité vérifiés (si applicable) - [ ] Tableaux de bord de surveillance et alertes configurés - [ ] Runbooks documentés pour les opérations courantes - [ ] Projection des coûts validée et budgets définis - [ ] Stratégie de balisage implémentée pour toutes les ressources - [ ] Procédures de sauvegarde et de restauration testées

Cadre d'architecture expert cloud AWS

Contenu du PromptEnregistrer

Utilisation

Références

Discussion