Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Crea una AWS landing zone che includa MongoDB Atlas
Igor Alekseev, Amazon Web Services
Riepilogo
Questo modello descrive come creare una AWS landing zone integrata con un cluster MongoDB Atlas. L'infrastruttura viene implementata automaticamente utilizzando uno script Terraform.
Un AWS ambiente ben strutturato e multi-account, chiamato landing zone, offre scalabilità e sicurezza, in particolare per le aziende. Serve come base per una rapida implementazione di carichi di lavoro e applicazioni e contribuisce a garantire la fiducia nella sicurezza e nell'infrastruttura. La costruzione di una landing zone richiede un'attenta considerazione dei fattori tecnici e commerciali, tra cui la struttura degli account, il networking, la sicurezza e la gestione degli accessi. Queste considerazioni devono essere allineate agli obiettivi aziendali e di crescita futuri dell'organizzazione.
I casi d'uso di questo modello includono quanto segue.
Piattaforme SaaS e PaaS aziendali: le applicazioni software as a service (SaaS) multitenant e le piattaforme platform as a service (PaaS) che funzionano su AWS possono utilizzare questa configurazione per fornire un accesso privato e sicuro a MongoDB Atlas senza esporre i dati sulla rete Internet pubblica.
Settori altamente regolamentati: i carichi di lavoro bancari, finanziari, sanitari e governativi che richiedono una stretta conformità a standard come Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry Data Security Standard (PCI DSS), System and Organization Controls 2 () e General Data Protection Regulation (GDPRSOC2) beneficiano di:
Connettività privata crittografata tramite AWS PrivateLink
Alta disponibilità Multi-AZ di set di repliche MongoDB
AI/ML Carichi di lavoro sicuri: le pipeline di formazione o inferenza in Amazon Bedrock, SageMaker Amazon AI o modelli di intelligenza artificiale personalizzati possono recuperare e archiviare dati in modo sicuro in MongoDB Atlas over. PrivateLink
Disaster recovery e continuità aziendale: il design Multi-AZ garantisce che nessun guasto in una singola zona di disponibilità interrompa i carichi di lavoro. Una replica Atlas impostata su tutte le zone di disponibilità garantisce il failover automatico. Questo è fondamentale per servizi sempre attivi come le app di tecnologia finanziaria (fintech), il digital banking o il monitoraggio sanitario.
Prerequisiti e limitazioni
Prerequisiti
Accesso del proprietario dell'organizzazione a MongoDB Atlas in modo da poter creare chiavi API Atlas. Per informazioni su questo requisito, consulta Gestire l'accesso all'organizzazione
nella documentazione di MongoDB. Un attivo. Account AWS
Terraform
, installato e configurato. Un cluster MongoDB Atlas, creato con MongoDB versione 6.0 o successiva.
Familiarità con MongoDB e MongoDB Atlas. Per ulteriori informazioni, consulta la documentazione di MongoDB Atlas
.
Limitazioni
Alcuni Servizi AWS non sono disponibili in tutti. Regioni AWS Per la disponibilità per regione, vedi Servizi AWS per regione
. Per endpoint specifici, consulta Endpoints and quotas del servizio e scegli il link relativo al servizio.
Architettura
Il seguente diagramma dell'architettura di riferimento illustra la configurazione dell'implementazione per una AWS landing zone integrata con un endpoint privato MongoDB Atlas. Questa architettura di riferimento dimostra come stabilire una AWS landing zone sicura, scalabile e ad alta disponibilità integrata con MongoDB Atlas. Combinando le AWS migliori pratiche come l'implementazione Multi-AZ, i controlli di sicurezza con privilegi minimi e la connettività privata, questo design consente alle organizzazioni di fornire un ambiente robusto per le applicazioni moderne.

Questa architettura è composta da quanto segue:
VPC
Un singolo cloud privato virtuale (VPC) si estende su tre zone di disponibilità.
Il VPC è suddiviso in sottoreti allineate a ciascuna zona di disponibilità. Queste sottoreti distribuiscono i carichi di lavoro per garantire un'elevata disponibilità.
Accesso a Internet
Un gateway Internet fornisce connettività Internet in uscita per le risorse che ne hanno bisogno, come applicazioni o host bastion.
Le sottoreti pubbliche possono ospitare gateway NAT, che consentono ai carichi di lavoro di sottoreti private di scaricare aggiornamenti, patch e altri pacchetti necessari senza esporli direttamente alla rete Internet pubblica.
Sottoreti private e tabelle di routing
I componenti delle applicazioni, i microservizi o altre risorse sensibili risiedono in genere in sottoreti private.
Le tabelle di routing dedicate controllano i flussi di traffico. Instrada il traffico in uscita dalle sottoreti private ai gateway NAT per un accesso Internet sicuro e solo in uscita.
Le richieste in entrata da Internet fluiscono attraverso sistemi di bilanciamento del carico elastici o host bastion (se utilizzati) nelle sottoreti pubbliche, quindi vengono indirizzate in modo appropriato verso le risorse di sottorete private.
Connettività MongoDB Atlas tramite PrivateLink
L'architettura utilizza PrivateLink (tramite un endpoint VPC) la connessione sicura a MongoDB Atlas senza esporre i dati alla rete Internet pubblica.
Le richieste rimangono sulla rete dorsale. AWS I dati in transito traggono vantaggio dalla PrivateLink crittografia e non vengono mai instradati sulla rete Internet pubblica.
Il VPC dedicato MongoDB Atlas ospita i nodi primari e secondari e fornisce un ambiente sicuro e isolato per il cluster di database gestito.
Multi-AZ deployment (Implementazione Multi-AZ)
I componenti critici dell'infrastruttura (come i gateway NAT e le sottoreti delle applicazioni) sono distribuiti su almeno tre zone di disponibilità. Se in una zona di disponibilità si verifica un'interruzione, questa architettura garantisce che i carichi di lavoro nelle restanti zone di disponibilità rimangano operativi.
MongoDB Atlas, per impostazione predefinita, offre un'elevata disponibilità tramite set di repliche e garantisce che il livello di database rimanga tollerante ai guasti. L'infrastruttura critica è distribuita su almeno tre zone di disponibilità per garantire la resilienza.
Strumenti
Servizi AWS
AWS Secrets Managerti aiuta a sostituire le credenziali codificate nel codice, comprese le password, con una chiamata API per recuperare il segreto a livello di codice.
Altri prodotti e strumenti
MongoDB
Atlas è un database as a service (DBaaS) completamente gestito per l'implementazione e la gestione di database MongoDB nel cloud. Terraform
è uno strumento di infrastruttura come codice (IaC) HashiCorp che ti aiuta a creare e gestire risorse cloud e locali. In questo modello, si utilizza Terraform per eseguire uno script per facilitare la distribuzione delle risorse richieste su MongoDB AWS Atlas.
Archivio di codice
Il codice per questo pattern è disponibile nel repository MongoDB Atlas Landing
Epiche
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Identifica le principali parti interessate. | Identifica tutte le principali parti interessate e i membri del team coinvolti nel tuo progetto di landing zone. Ciò potrebbe includere ruoli come:
| Responsabile della migrazione |
Crea un progetto strutturale. | Crea un modello che delinei la struttura desiderata della tua landing zone e di quella abilitata per AWS MongoDB Atlas. | Responsabile della migrazione |
Crea un piano di architettura. | Collabora con gli architetti delle applicazioni per analizzare i requisiti e progettare un'architettura resiliente e tollerante ai guasti. Questo modello fornisce un modello di architettura iniziale come riferimento. È possibile personalizzare questo modello per soddisfare le esigenze di sicurezza e infrastruttura dell'organizzazione. | Architetto del cloud |
Pianifica la configurazione e l'implementazione. | Determina, con tutte le parti interessate, come verrà implementata l'architettura, come verranno implementate le misure di sicurezza e qualsiasi altro aspetto per garantire l'allineamento con gli interessi dell'organizzazione e del team richiedente. | Responsabile della migrazione, ingegnere, DBA DevOps |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Clonare il repository. | Clona il codice dal GitHub repository
| Sviluppatore di app, ingegnere DevOps |
Ottieni l'ID della tua organizzazione Atlas. |
| DBA |
Genera chiavi API Atlas a livello di organizzazione. | DBA | |
Crea un segreto in AWS Secrets Manager. | Archivia le chiavi API MongoDB Atlas generate nel passaggio precedente come segreto chiave-valore in Secrets Manager. Per istruzioni, consulta la documentazione di Secrets Manager. | DevOps ingegnere |
Seleziona il livello del cluster Atlas. | Per selezionare il livello di cluster Atlas corretto, segui le istruzioni nella documentazione di MongoDB | DBA |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Modifica lo script Terraform. | Nella copia locale del GitHub repository, aggiorna il nome segreto nel modules/mongodb-atlas/mainfile.tf | DevOps ingegnere |
Crea un ID chiave di AWS accesso e una chiave segreta. | Per creare l'ID della chiave di AWS accesso e la chiave segreta, segui le istruzioni contenute nell'articolo AWS Re:post Come posso creare una chiave di AWS accesso È consigliabile assegnare le politiche con i privilegi minimi necessari, ma in questo caso, selezionare la politica. Dopo aver creato la chiave di accesso, consulta le best practice di sicurezza in IAM per conoscere le migliori pratiche per la gestione delle chiavi di accesso. | DevOps ingegnere |
Alloca indirizzi IP elastici. | Alloca almeno due indirizzi IP elastici. IDs Per istruzioni, consulta la documentazione di Amazon Virtual Private Cloud (Amazon VPC). | DevOps ingegnere |
Crea un bucket S3. | Crea un bucket S3 per archiviare lo stato della tua implementazione Terraform seguendo le istruzioni nella documentazione di Amazon Simple Storage Service (Amazon S3). | DevOps ingegnere |
Aggiorna il bucket S3 per l'archiviazione. | Aggiorna le informazioni sul bucket S3 nella tua versione locale di environments/development/main.tf
Per questo esempio, puoi configurare Terraform per utilizzare il key Per ulteriori informazioni sui prefissi chiave di Amazon S3, consulta Organizzazione degli oggetti utilizzando i prefissi nella documentazione di Amazon S3. | DevOps ingegnere |
Imposta le variabili Terraform. | La landing zone di esempio definisce i valori delle variabili di input utilizzando i file di definizione variabile Terraform Il file variabile si trova in environments/development/variables.tf. | DevOps ingegnere |
Imposta le variabili di ambiente. | Se hai intenzione di eseguire lo script Terraform sul tuo computer locale, imposta le seguenti variabili di ambiente:
Per ulteriori informazioni sull'impostazione delle variabili di ambiente, consulta la documentazione AWS Command Line Interface (AWS CLI). | DevOps ingegnere |
Controlla le configurazioni del VPC. | Per seguire le migliori pratiche consigliate da AWS, configura le impostazioni per VPC e sottorete CIDRs, gateway NAT, percorsi e tabelle di routing nello script Terraform per soddisfare le esigenze della tua organizzazione. Per informazioni specifiche, consulta il file Readme per il repository. | DevOps ingegnere |
Aggiunta di tag alle risorse . | Puoi taggare AWS le tue risorse per monitorarle quando vengono distribuite dallo script Terraform. Per esempi, consulta il file Readme per il repository | DevOps ingegnere |
Usa più ambienti. | Il GitHub repository fornisce una cartella di Per aggiungere un ambiente, copia la | DevOps ingegnere |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Inizializza la directory di lavoro di Terraform. | Per inizializzare la directory di lavoro e scaricare i pacchetti necessari, esegui il comando:
| DevOps ingegnere |
Crea un piano di esecuzione. | Per creare un piano di esecuzione e visualizzare le modifiche che Terraform apporterà alla tua infrastruttura, esegui il comando:
| DevOps ingegnere |
Implementa le modifiche. | Per implementare le modifiche all'infrastruttura come descritto nel codice, esegui il comando:
| DevOps ingegnere |
Convalida la distribuzione. | Convalida i componenti che Terraform ha creato o modificato nella tua infrastruttura. Per testare la configurazione, esegui il provisioning di una risorsa di calcolo (ad esempio, un' EC2 istanza o una AWS Lambda funzione Amazon) all'interno o collegata al VPC. | DevOps ingegnere, sviluppatore di app |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Elimina. | Al termine del test, esegui il seguente comando per distruggere le risorse distribuite da Terraform nella tua infrastruttura:
| DevOps ingegnere |
Risorse correlate
Scoperta e valutazione
Suggerimenti amministrativi per la configurazione delle landing zone (AWS Control Tower documentazione)
Aspettative per la configurazione delle landing zone (AWS Control Tower documentazione)
Procedure consigliate per gli aggiornamenti delle landing zone (AWS Control Tower documentazione)
Configurazione di MongoDB Atlas e degli ambienti AWS
Ottenere MongoDB Atlas (
)Marketplace AWS Memoria
(documentazione MongoDB Atlas) Esempio di dimensionamento con set di dati di esempio Atlas
(documentazione MongoDB Atlas) Esempio di dimensionamento per applicazioni mobili (documentazione
MongoDB Atlas) Traffico di rete
(documentazione MongoDB Atlas) Auto-scaling del cluster
(documentazione MongoDB Atlas) Modello di dimensionamento Atlas
(documentazione MongoDB Atlas) Configurare una connessione peering di rete (documentazione
MongoDB Atlas) Endpoint privati in Atlas (documentazione
MongoDB Atlas) Crittografia a livello di campo lato client
(documentazione del database MongoDB) Crittografia automatica
(documentazione del database MongoDB) Selezione di un livello di cluster
(documentazione MongoDB Atlas)
Implementazione della landing zone
Terraform on AWS (CI/CD per reti 5G su white paper) AWS
Atlante MongoDB con Terraform (
documentazione MongoDB)