Crea una AWS landing zone che includa MongoDB Atlas - Prontuario AWS

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

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.

Architettura Multi-AZ per le landing zone di AWS integrata con MongoDB Atlas.

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 Zone.AWS GitHub

Epiche

AttivitàDescrizioneCompetenze 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:

  • Amministratori di database () DBAs

  • DevOps ingegneri

  • sviluppatori di applicazioni

  • Architetti di applicazioni

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àDescrizioneCompetenze richieste

Clonare il repository.

Clona il codice dal GitHub repository eseguendo il comando:

git clone https://github.com/mongodb-partners/AWS-MongoDB-Atlas-Landing-Zone
Sviluppatore di app, ingegnere DevOps

Ottieni l'ID della tua organizzazione Atlas.

  1. Se non disponi di un account MongoDB Atlas, registrane uno.

  2. Segui i passaggi nella documentazione di MongoDB per creare un'organizzazione.

  3. Copia l'ID dell'organizzazione.

DBA

Genera chiavi API Atlas a livello di organizzazione.

Per generare le tue chiavi API a livello di organizzazione in Atlas, segui le istruzioni nella documentazione di MongoDB.

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àDescrizioneCompetenze richieste

Modifica lo script Terraform.

Nella copia locale del GitHub repository, aggiorna il nome segreto nel modules/mongodb-atlas/mainfile.tf (riga 12), in modo che Terraform possa recuperare le credenziali da Secrets Manager durante la distribuzione.

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. AdministratorAccess

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 in modo che corrispondano al nome e alla regione del bucket che hai creato nel passaggio precedente e specifica un key prefix. Per esempio:

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

Per questo esempio, puoi configurare Terraform per utilizzare il key network/dev prefix per organizzare il file di stato Terraform. È possibile modificare il valore in prod o in modo che staging corrisponda all'ambiente che si desidera creare. Per informazioni sull'utilizzo di più ambienti, consulta l'ultimo passaggio di questa sezione.

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. È possibile impostare i valori delle variabili nel environments/development/terraformfile.tfvars. Configura queste variabili come descritto nel file Readme per il repository. GitHub

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:

  • AWS_ACCESS_KEY_ID: ID della chiave di AWS accesso

  • AWS_SECRET_ACCESS_KEY: chiave di accesso AWS segreta

  • AWS_DEFAULT_REGION: Regione AWS

  • TF_LOG: livello di registro Terraform (DEBUGoINFO)

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. GitHub

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. GitHub Per informazioni sul monitoraggio delle risorse tramite tag per costi, utilizzo e così via, consultate Attivazione dei tag di allocazione dei costi definiti dall'utente nella documentazione. AWS Billing

DevOps ingegnere

Usa più ambienti.

Il GitHub repository fornisce una cartella di development ambiente. È inoltre possibile aggiungere i propri ambienti nella cartella environment.

Per aggiungere un ambiente, copia la development cartella in una nuova cartella (ad esempio, prod ostaging) sottoenvironments. È quindi possibile aggiornare il terraform.tfvars file con il nuovo valore.

DevOps ingegnere
AttivitàDescrizioneCompetenze richieste

Inizializza la directory di lavoro di Terraform.

Per inizializzare la directory di lavoro e scaricare i pacchetti necessari, esegui il comando:

terraform init
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:

terraform plan
DevOps ingegnere

Implementa le modifiche.

Per implementare le modifiche all'infrastruttura come descritto nel codice, esegui il comando:

terraform apply
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àDescrizioneCompetenze richieste

Elimina.

Al termine del test, esegui il seguente comando per distruggere le risorse distribuite da Terraform nella tua infrastruttura:

terraform destroy
DevOps ingegnere

Risorse correlate

Scoperta e valutazione

Configurazione di MongoDB Atlas e degli ambienti AWS

Implementazione della landing zone