Compétences multi-cloud-architecture
☁️

multi-cloud-architecture

Sûr

Concevoir des architectures multi-cloud sur AWS, Azure et GCP

Également disponible depuis: wshobson

Éviter la dépendance aux fournisseurs et construire des systèmes cloud résilients. Cette compétence fournit un cadre décisionnel pour la sélection et l'intégration de services sur plusieurs fournisseurs cloud.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "multi-cloud-architecture". Comparer les options de calcul serverless entre les clouds

Résultat attendu:

AWS Lambda: Fonctions pilotées par les événements avec timeout de 15 minutes, intégrations étendues. Azure Functions: Intégration étroite avec l'écosystème Microsoft, Durable Functions pour les workflows avec état. GCP Cloud Functions: Tarification simple, intégration native BigQuery. Recommandation: Utiliser Lambda pour les workflows d'événements complexes, Azure Functions pour les piles Microsoft, Cloud Functions pour les pipelines de données.

Utilisation de "multi-cloud-architecture". Concevoir une architecture géodistribuée pour les utilisateurs mondiaux

Résultat attendu:

Architecture: Utiliser GCP Cloud CDN pour les actifs statiques, AWS CloudFront pour le contenu dynamique, Azure Front Door pour la passerelle API. Déployer des services sans état sur GKE, AKS et EKS dans les régions les plus proches. Utiliser Cloud Spanner ou Cosmos DB pour les données distribuées à l'échelle mondiale. Router le trafic via le geo-routing basé sur DNS avec vérifications de santé et basculement automatique.

Audit de sécurité

Sûr
v1 • 2/25/2026

All static analyzer findings are false positives. The SKILL.md file is pure documentation containing markdown tables, text descriptions, and architecture diagrams. No executable code or command injection vectors exist. External command references are documentation text pointing to other files, not actual shell execution.

1
Fichiers analysés
192
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Stratégie multi-cloud d'entreprise

Concevoir une stratégie cloud qui distribue les charges de travail sur AWS, Azure et GCP pour réduire la dépendance aux fournisseurs et améliorer le pouvoir de négociation avec les fournisseurs.

Planification de migration cloud

Planifier et exécuter la migration d'un fournisseur cloud à un autre tout en minimisant les temps d'arrêt et en maintenant la qualité du service.

Architecture de reprise après sinistre

Construire des systèmes résilients avec des capacités de reprise après sinistre sur plusieurs fournisseurs cloud pour la continuité des activités.

Essayez ces prompts

Comparer les services cloud pour une charge de travail 
Je dois déployer une application web haute disponibilité avec mise à l'échelle automatique. Comparer les services équivalents sur AWS, Azure et GCP pour le calcul, le stockage, la base de données et la mise en réseau. Recommander la meilleure option pour chaque catégorie en fonction des coûts et des fonctionnalités.
Concevoir une architecture cloud-agnostique 
Concevoir une architecture cloud-agnostique pour une application de microservices qui peut s'exécuter sur n'importe quel fournisseur cloud. Inclure des technologies spécifiques pour l'orchestration du calcul, le stockage de données, la messagerie et la surveillance qui fonctionnent de manière cohérente sur AWS, Azure et GCP.
Plan de reprise après sinistre multi-cloud 
Créer une architecture de reprise après sinistre en utilisant AWS comme primaire et Azure comme secondaire. Inclure la stratégie de réplication de base de données, l'automatisation du basculement, les objectifs RTO/RPO et les procédures de récupération étape par étape.
Plan d'exécution de migration cloud 
Nous migrons d'AWS vers GCP sur 6 mois. Créer un plan de migration détaillé utilisant l'approche en quatre phases. Inclure les critères d'évaluation des charges de travail, la sélection des pilotes, la séquence de migration, l'atténuation des risques et les métriques de succès pour chaque phase.

Bonnes pratiques

  • Utiliser l'infrastructure en tant que code (Terraform) pour gérer les ressources de manière cohérente sur tous les fournisseurs cloud
  • Concevoir pour l'échec en supposant qu'une seule région ou fournisseur cloud peut devenir indisponible
  • Implémenter une surveillance complète avec des outils cloud-agnostiques comme Prometheus et Grafana

Éviter

  • Construire des architectures fortement couplées qui dépendent de services cloud propriétaires sans couches d'abstraction
  • Ignorer les coûts de transfert de données entre les fournisseurs cloud qui peuvent rapidement faire grimper les dépenses
  • Tenter le multi-cloud sans l'expertise appropriée de l'équipe dans chaque fournisseur menant à une complexité opérationnelle

Foire aux questions

Quand dois-je utiliser le multi-cloud plutôt qu'un cloud unique ?
Utilisez le multi-cloud lorsque vous avez besoin d'atténuation des risques fournisseurs, de conformité réglementaire entre régions, des meilleurs services ou d'un pouvoir de négociation amélioré. Le cloud unique est plus simple et souvent suffisant pour les startups ou les applications sans exigences strictes de disponibilité.
Quel est le plus grand défi des architectures multi-cloud ?
La complexité opérationnelle est le défi principal. Les équipes ont besoin d'expertise sur plusieurs plateformes, la surveillance devient fragmentée et le débogage des problèmes entre les clouds nécessite des outils et processus supplémentaires.
Comment éviter la dépendance aux fournisseurs lors de l'utilisation de services cloud natifs ?
Utilisez des couches d'abstraction comme Kubernetes pour le calcul, les bases de données compatibles PostgreSQL, les API de stockage compatibles S3 et l'infrastructure en tant que code. Évitez les services propriétaires sauf si leurs avantages dépassent clairement les risques de dépendance.
Quel est le pattern de reprise après sinistre recommandé pour le multi-cloud ?
Pattern Primaire Secondaire : Exécuter la production dans un cloud avec réplication asynchrone vers un cloud secondaire. Utiliser des vérifications de santé automatisées et des procédures de basculement. Tester le basculement trimestriellement pour s'assurer que les objectifs de récupération sont atteints.
Quelles économies de coûts puis-je attendre du multi-cloud ?
Les économies directes varient considérablement mais se situent généralement entre 10 et 30% grâce à la tarification compétitive et à l'optimisation des charges de travail. La valeur réelle est souvent l'atténuation des risques et le pouvoir de négociation plutôt que la réduction directe des coûts.
Dois-je commencer par le multi-cloud ou migrer plus tard ?
Concevez une architecture cloud-agnostique dès le départ en utilisant des technologies portables, mais déployez initialement sur un seul cloud. Ajoutez des fournisseurs supplémentaires lorsque les besoins métier justifient la complexité et la surcharge opérationnelle ajoutées.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/multi-cloud-architecture

Réf

main

Structure de fichiers

📄 SKILL.md