Créez une zone AWS d'atterrissage qui inclut MongoDB Atlas - Recommandations AWS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Créez une zone AWS d'atterrissage qui inclut MongoDB Atlas

Igor Alekseev, Amazon Web Services

Récapitulatif

Ce modèle décrit comment créer une zone AWS d'atterrissage intégrée à un cluster MongoDB Atlas. L'infrastructure est automatiquement déployée à l'aide d'un script Terraform.

Un AWS environnement multi-comptes bien structuré, appelé zone d'atterrissage, offre évolutivité et sécurité, en particulier pour les entreprises. Il sert de base au déploiement rapide des charges de travail et des applications, et contribue à garantir la confiance dans la sécurité et l'infrastructure. La création d'une zone d'atterrissage nécessite un examen attentif des facteurs techniques et commerciaux, notamment la structure du compte, le réseau, la sécurité et la gestion des accès. Ces considérations doivent être alignées sur la croissance future et les objectifs commerciaux de votre organisation.

Les cas d'utilisation de ce modèle sont les suivants.

  • Plateformes SaaS et PaaS d'entreprise : les applications logicielles en tant que service (SaaS) mutualisées et les plateformes de plate-forme en tant que service (PaaS) qui s'exécutent AWS peuvent utiliser cette configuration pour fournir un accès privé et sécurisé à MongoDB Atlas sans exposer les données sur Internet public.

  • Secteurs hautement réglementés : les charges de travail des banques, des services financiers, des soins de santé et des administrations qui nécessitent un strict respect de normes telles que la Health Insurance Portability and Accountability Act (HIPAA), la norme de sécurité des données du secteur des cartes de paiement (PCI DSS), le System and Organization Controls 2 (SOC2) et le règlement général sur la protection des données (RGPD) bénéficient de :

    • Connectivité privée cryptée via AWS PrivateLink

    • Haute disponibilité multi-AZ des ensembles de répliques MongoDB

  • AI/ML Charges de travail sécurisées : les pipelines de formation ou d'inférence d'Amazon Bedrock, d'Amazon SageMaker AI ou de modèles d'IA personnalisés peuvent récupérer et stocker des données en toute sécurité dans MongoDB Atlas over. PrivateLink

  • Reprise après sinistre et continuité des activités : la conception multi-AZ garantit qu'aucune défaillance d'une seule zone de disponibilité ne perturbe les charges de travail. Une réplique d'Atlas répartie sur plusieurs zones de disponibilité garantit un basculement automatique. Cela est essentiel pour les services permanents tels que les applications de technologie financière (fintech), les services bancaires numériques ou le suivi des soins de santé.

Conditions préalables et limitations

Prérequis

  • Accès du propriétaire de l'organisation à MongoDB Atlas afin que vous puissiez créer des clés d'API Atlas. Pour plus d'informations sur cette exigence, consultez la section Gérer l'accès à l'organisation dans la documentation de MongoDB.

  • Un actif Compte AWS.

  • Terraform, installé et configuré.

  • Un cluster MongoDB Atlas, créé avec MongoDB version 6.0 ou ultérieure.

  • Connaissance de MongoDB et de MongoDB Atlas. Pour plus d'informations, consultez la documentation de l'Atlas MongoDB.

Limites

Architecture

Le schéma d'architecture de référence suivant illustre la configuration de déploiement pour une zone d' AWS atterrissage intégrée à un point de terminaison privé MongoDB Atlas. Cette architecture de référence montre comment établir une zone d' AWS atterrissage sécurisée, évolutive et hautement disponible intégrée à MongoDB Atlas. En combinant les AWS meilleures pratiques telles que le déploiement multi-AZ, les contrôles de sécurité basés sur le moindre privilège et la connectivité privée, cette conception permet aux entreprises de fournir un environnement robuste pour les applications modernes.

Architecture multi-AZ pour la zone de landing zone AWS intégrée à MongoDB Atlas.

Cette architecture comprend les éléments suivants :

VPC

  • Un seul cloud privé virtuel (VPC) couvre trois zones de disponibilité.

  • Le VPC est subdivisé en sous-réseaux alignés sur chaque zone de disponibilité. Ces sous-réseaux distribuent les charges de travail pour une haute disponibilité.

Accès à Internet

  • Une passerelle Internet fournit une connectivité Internet sortante aux ressources qui en ont besoin, telles que les hôtes d'applications ou de bastions.

  • Les sous-réseaux publics peuvent héberger des passerelles NAT, qui permettent aux charges de travail des sous-réseaux privés de télécharger des mises à jour, des correctifs et d'autres packages requis sans les exposer directement à l'Internet public.

Sous-réseaux privés et tables de routage

  • Les composants d'application, les microservices ou les autres ressources sensibles résident généralement dans des sous-réseaux privés.

  • Des tables de routage dédiées contrôlent les flux de trafic. Achemine le trafic sortant direct des sous-réseaux privés vers les passerelles NAT pour un accès Internet sécurisé réservé aux sorties.

  • Les demandes entrantes provenant d'Internet transitent par des équilibreurs de charge élastiques ou des hôtes bastions (s'ils sont utilisés) dans des sous-réseaux publics, puis sont acheminées de manière appropriée vers les ressources de sous-réseaux privés.

Connectivité MongoDB Atlas via PrivateLink

  • L'architecture permet PrivateLink (via un point de terminaison VPC) de se connecter en toute sécurité à MongoDB Atlas sans exposer vos données à l'Internet public.

  • Les demandes restent sur le AWS réseau principal. Les données en transit bénéficient du PrivateLink chiffrement et ne sont jamais acheminées via l'Internet public.

  • Le VPC dédié MongoDB Atlas héberge vos nœuds principaux et secondaires et fournit un environnement sécurisé et isolé pour votre cluster de bases de données géré.

déploiement multi-AZ

  • Les composants d'infrastructure critiques (tels que les passerelles NAT et les sous-réseaux d'applications) sont répartis sur au moins trois zones de disponibilité. En cas de panne d'une zone de disponibilité, cette architecture garantit que les charges de travail des zones de disponibilité restantes restent opérationnelles.

  • Par défaut, MongoDB Atlas offre une haute disponibilité grâce à des ensembles de répliques et garantit que votre couche de base de données reste tolérante aux pannes. Les infrastructures critiques sont réparties sur au moins trois zones de disponibilité pour garantir leur résilience.

Outils

Services AWS

  • AWS Secrets Managervous permet de remplacer les informations d'identification codées en dur dans votre code, y compris les mots de passe, par un appel d'API pour récupérer le secret par programmation.

Autres produits et outils

  • MongoDB Atlas est une base de données en tant que service (DBaaS) entièrement gérée pour le déploiement et la gestion des bases de données MongoDB dans le cloud.

  • Terraform est un outil d'infrastructure en tant que code (IaC) HashiCorp qui vous aide à créer et à gérer des ressources sur site et dans le cloud. Dans ce modèle, vous utilisez Terraform pour exécuter un script afin de faciliter le déploiement des ressources requises sur AWS MongoDB Atlas.

Référentiel de code

Le code de ce modèle est disponible dans le référentiel AWS MongoDB Atlas Landing Zone GitHub .

Épopées

TâcheDescriptionCompétences requises

Identifiez les principales parties prenantes.

Identifiez toutes les parties prenantes clés et les membres de l'équipe impliqués dans votre projet de zone d'atterrissage. Cela peut inclure des rôles tels que :

  • Administrateurs de base de données (DBAs)

  • DevOps ingénieurs

  • Développeurs d'applications

  • Architectes d'applications

Responsable de la migration

Créez un plan structurel.

Créez un plan qui décrit la structure souhaitée pour votre zone d'atterrissage AWS et celle compatible avec MongoDB Atlas.

Responsable de la migration

Créez un plan d'architecture.

Collaborez avec vos architectes d'applications pour analyser les exigences et concevoir une architecture résiliente et tolérante aux pannes. Ce modèle fournit un modèle d'architecture de démarrage à titre de référence. Vous pouvez personnaliser ce modèle pour répondre aux besoins de sécurité et d'infrastructure de votre organisation.

Architecte du cloud

Planifiez la configuration et le déploiement.

Déterminez, avec toutes les parties prenantes, comment l'architecture sera déployée, comment les mesures de sécurité seront mises en œuvre et tout autre aspect garantissant l'alignement avec les intérêts de l'organisation et de l'équipe demandeuse.

Responsable de la migration, DevOps ingénieur, DBA
TâcheDescriptionCompétences requises

Pour cloner le référentiel.

Clonez le code depuis le GitHub dépôt en exécutant la commande suivante :

git clone https://github.com/mongodb-partners/AWS-MongoDB-Atlas-Landing-Zone
Développeur d'applications, DevOps ingénieur

Obtenez l'identifiant de votre organisation Atlas.

  1. Si vous n'avez pas de compte MongoDB Atlas, créez-en un.

  2. Suivez les étapes de la documentation MongoDB pour créer une organisation.

  3. Copiez l'identifiant de l'organisation.

DBA

Générez des clés d'API au niveau de l'organisation Atlas.

Pour générer les clés d'API au niveau de votre organisation dans Atlas, suivez les instructions de la documentation MongoDB.

DBA

Créez un secret dans AWS Secrets Manager.

Stockez les clés d'API MongoDB Atlas générées à l'étape précédente sous forme de code secret clé-valeur dans Secrets Manager. Pour obtenir des instructions, consultez la documentation de Secrets Manager.

DevOps ingénieur

Sélectionnez le niveau du cluster Atlas.

Pour sélectionner le niveau de cluster Atlas approprié, suivez les instructions de la documentation MongoDB.

DBA
TâcheDescriptionCompétences requises

Modifiez le script Terraform.

Dans votre copie locale du GitHub référentiel, mettez à jour le nom du secret dans le fichier modules/mongodb-atlas/main.tf (ligne 12), afin que Terraform puisse récupérer les informations d'identification auprès de Secrets Manager lors du déploiement.

DevOps ingénieur

Créez un identifiant de clé d' AWS accès et une clé secrète.

Pour créer votre identifiant de clé d' AWS accès et votre clé secrète, suivez les instructions de l'article AWS Re:Post How do I create an AWS access key ?

Il est recommandé d'attribuer des politiques avec le moins de privilèges nécessaires, mais dans ce cas, sélectionnez la AdministratorAccess stratégie.

Après avoir créé votre clé d'accès, consultez les meilleures pratiques de sécurité dans IAM pour en savoir plus sur les meilleures pratiques en matière de gestion des clés d'accès.

DevOps ingénieur

Allouez des adresses IP élastiques.

Allouez au moins deux adresses IP élastiques IDs. Pour obtenir des instructions, consultez la documentation Amazon Virtual Private Cloud (Amazon VPC).

DevOps ingénieur

Créez un compartiment S3.

Créez un compartiment S3 pour stocker l'état de votre déploiement Terraform en suivant les instructions de la documentation Amazon Simple Storage Service (Amazon S3).

DevOps ingénieur

Mettez à jour le compartiment S3 pour le stockage.

Mettez à jour les informations du compartiment S3 dans votre version locale de environments/development/main.tf pour qu'elles correspondent au nom et à la région du compartiment que vous avez créé à l'étape précédente, et spécifiez un préfixe de clé. Par exemple :

terraform { ... backend "s3" { bucket = "startup-name-product-terraform" key = "network/dev" region = "ap-southeast-1" } }

Pour cet exemple, vous pouvez configurer Terraform pour utiliser le network/dev préfixe key pour organiser le fichier d'état Terraform. Vous pouvez modifier la valeur en prod fonction staging de l'environnement que vous souhaitez créer. Pour plus d'informations sur l'utilisation de plusieurs environnements, consultez la dernière étape de cette section.

Pour plus d'informations sur les préfixes clés Amazon S3, consultez la section Organisation des objets à l'aide de préfixes dans la documentation Amazon S3.

DevOps ingénieur

Définissez les variables Terraform.

L'exemple de zone d'atterrissage définit les valeurs des variables d'entrée à l'aide de fichiers de définition de variables Terraform.

Le fichier de variables se trouve dans le fichier environments/development/variables.tf. Vous pouvez définir les valeurs des variables dans le environments/development/terraformfichier .tfvars. Configurez ces variables comme décrit dans le fichier Readme du GitHub référentiel.

DevOps ingénieur

Configurez les variables d'environnement.

Si vous envisagez d'exécuter le script Terraform sur votre machine locale, configurez les variables d'environnement suivantes :

  • AWS_ACCESS_KEY_ID: ID de clé d' AWS accès

  • AWS_SECRET_ACCESS_KEY: clé d'accès AWS secrète

  • AWS_DEFAULT_REGION: Région AWS

  • TF_LOG: niveau du journal Terraform (ou) DEBUG INFO

Pour plus d'informations sur la configuration des variables d'environnement, consultez la documentation AWS Command Line Interface (AWS CLI).

DevOps ingénieur

Vérifiez les configurations VPC.

Pour suivre les meilleures pratiques recommandées par AWS, configurez les paramètres du VPC et du sous-réseau CIDRs, des passerelles NAT, des routes et des tables de routage dans le script Terraform afin de répondre aux besoins de votre organisation. Pour plus de détails, consultez le fichier Readme du GitHub référentiel.

DevOps ingénieur

Baliser des ressources .

Vous pouvez étiqueter vos AWS ressources pour les surveiller lorsqu'elles sont déployées par le script Terraform. Pour des exemples, consultez le fichier Readme du GitHub référentiel. Pour plus d'informations sur la surveillance des ressources par le biais de balises de coût, d'utilisation, etc., consultez la section Activation des balises de répartition des coûts définies par l'utilisateur dans la AWS Billing documentation.

DevOps ingénieur

Utilisez plusieurs environnements.

Le GitHub référentiel fournit un dossier d'developmentenvironnement. Vous pouvez également ajouter vos propres environnements dans le dossier d'environnement.

Pour ajouter un environnement, copiez le development dossier dans un nouveau dossier (par exemple, prod oustaging) situé sousenvironments. Vous pouvez ensuite mettre à jour le terraform.tfvars fichier avec la nouvelle valeur.

DevOps ingénieur
TâcheDescriptionCompétences requises

Initialisez le répertoire de travail Terraform.

Pour initialiser le répertoire de travail et télécharger les packages nécessaires, exécutez la commande suivante :

terraform init
DevOps ingénieur

Créez un plan d'exécution.

Pour créer un plan d'exécution et visualiser les modifications que Terraform apportera à votre infrastructure, exécutez la commande :

terraform plan
DevOps ingénieur

Déployez les modifications.

Pour implémenter les modifications apportées à votre infrastructure comme décrit dans le code, exécutez la commande suivante :

terraform apply
DevOps ingénieur

Validez le déploiement.

Validez les composants créés ou modifiés par Terraform dans votre infrastructure.

Pour tester la configuration, provisionnez une ressource de calcul (par exemple, une EC2 instance ou une AWS Lambda fonction Amazon) dans le VPC ou attachée à celui-ci.

DevOps ingénieur, développeur d'applications
TâcheDescriptionCompétences requises

Nettoyer.

Lorsque vous avez terminé les tests, exécutez la commande suivante pour détruire les ressources déployées par Terraform dans votre infrastructure :

terraform destroy
DevOps ingénieur

Ressources connexes

Découverte et évaluation

Configuration de l'atlas et des environnements MongoDB AWS

Déploiement de la zone d'atterrissage