MongoDB Atlas: clusters, seguridad y operación | Nicolás Garzón
Inicio Wiki MongoDB MongoDB Atlas MongoDB
MongoDB Atlas Explica cómo MongoDB Atlas administra clusters, red, backups, monitoring, escalado y seguridad, y qué decisiones siguen siendo responsabilidad del equipo.
Última actualización Actualizada 25 de jul de 2026
MongoDB Atlas es la plataforma administrada de MongoDB. Automatiza gran parte del provisioning, replication, backups, monitoring, upgrades y seguridad de infraestructura, pero no elimina las decisiones de schema, índices, queries, acceso, costes y recuperación.
MongoDB en Docker Nota siguiente Vector Search Texto
Copiar organización
→ proyecto
→ cluster y servicios
→ usuarios, red, backups y observabilidadAtlas es una forma de operar MongoDB, no una base de datos distinta. Algunas capacidades —como Search o Vector Search— pertenecen específicamente a la plataforma y deben distinguirse del servidor self-managed.
La organización agrupa equipos, facturación y políticas. Los proyectos aíslan clusters, usuarios de base, red, alertas y servicios.
desarrollo;
staging;
producción.
No reutilices credenciales, allowlists o proyectos sin necesidad. El aislamiento reduce errores humanos y blast radius.
El tier determina CPU, memoria, storage, IOPS y capacidades. Elegirlo requiere medir:
tamaño de datos e índices;
working set;
throughput;
p95/p99;
crecimiento;
backups;
failover;
servicios adicionales.
Un tier pequeño puede funcionar con datos de prueba y fallar cuando índices y hot data crecen.
Ubica el cluster cerca de la aplicación y usuarios relevantes. La distancia añade latencia a cada round trip.
región del backend;
disponibilidad de servicios;
residencia de datos;
costes de transferencia;
multi-region;
estrategia de disaster recovery.
No distribuyas regiones por marketing si el workload no tolera la latencia o la consistencia resultante.
Atlas administra replica sets y failover según configuración. Aun así, la aplicación necesita:
URI SRV correcta;
retryable behavior;
timeouts;
idempotencia;
graceful handling de elections;
pruebas periódicas.
Un servicio administrado no elimina errores ambiguos ni downtime breve durante failover.
Atlas separa acceso de red y usuarios de base.
Opciones incluyen, según oferta:
IP access lists;
VPC/VNet peering;
private endpoints;
redes privadas y DNS;
acceso administrativo restringido.
Evita 0.0.0.0/0. Una credencial válida debe seguir limitada por red.
Crea usuarios por workload:
API;
worker;
analytics;
migrations;
backup/restore cuando corresponda.
Aplica least privilege y rota secretos. Los roles de Atlas para administrar el proyecto no son lo mismo que los database users que acceden a colecciones.
Las conexiones utilizan TLS. El driver debe validar certificados y hostname. No desactives validación por problemas de configuración.
La URI contiene información sensible; no la registres ni la expongas al frontend.
Atlas ofrece snapshots y, según tier/configuración, point-in-time recovery. Define:
RPO;
RTO;
frecuencia;
retención;
región de copia;
protección contra borrado;
restore tests.
No asumas que “backup enabled” equivale a recuperación verificada. Restaura en otro cluster y prueba la aplicación.
Atlas entrega métricas y alertas para:
conexiones;
CPU;
memoria y cache;
disco;
replication lag;
opcounters;
query targeting;
backups;
storage growth.
Configura alertas accionables con owner y runbook. Los dashboards no sustituyen instrumentación del driver y de la API.
Analiza slow queries y puede sugerir índices. Cada sugerencia debe evaluarse por:
frecuencia;
query shape completa;
índice existente;
write amplification;
tamaño;
multikey;
otras queries.
No apliques recomendaciones automáticamente.
MongoDB Search utiliza índices separados y stages como $search. Es apropiado para relevancia, autocomplete, fuzzy matching, synonyms y facets.
La definición, pricing y disponibilidad dependen de la plataforma. Search no sustituye índices B-tree para CRUD ni autorización multi-tenant.
Permite consultar embeddings mediante índices vectoriales. Requiere diseñar dimensiones, similarity, filtros, chunking, evaluación y actualización. Es una capacidad diferente de la búsqueda textual normal.
Ofertas elásticas pueden simplificar workloads variables, pero debes revisar:
límites;
cold behavior;
conexiones;
pricing por operación;
compatibilidad de features;
latencia;
predictibilidad.
La aplicación debe reutilizar clientes y controlar autoscaling para evitar connection storms.
Puede ampliar storage o compute según políticas. Es una red de seguridad, no una estrategia de optimización. Una query ineficiente puede aumentar costes y seguir incumpliendo SLOs.
Mantén alertas de crecimiento y revisa por qué se escaló.
tier;
storage;
backups;
data transfer;
Search/Vector Search;
regiones;
analytics;
logs y servicios asociados.
Asigna tags, budgets y alertas. Un índice redundante y un pipeline frecuente también son decisiones financieras.
Para mover datos hacia Atlas evalúa:
volumen;
downtime tolerable;
herramientas soportadas;
versiones;
oplog/change capture;
validación;
rollback;
DNS y credenciales.
Prueba con una copia y confirma índices, users, validators y aplicación antes del cutover.
Gestiona proyectos, clusters, users, alerts y red mediante Terraform u otra herramienta compatible cuando el entorno lo justifique.
revisión;
reproducibilidad;
drift detection;
recuperación.
Protege state y secrets; no conviertas IaC en una fuente de passwords expuestos.
Atlas administra gran parte de la infraestructura. El equipo sigue siendo responsable de:
schema;
índices;
queries;
roles;
tenant isolation;
retención;
configuración de backup;
costes;
aplicación;
pruebas de restore.
CRUD y Aggregation core son portables entre despliegues compatibles. Search, Vector Search, triggers y APIs de plataforma pueden aumentar dependencia.
No es necesariamente negativo: documenta el valor, coste de salida y fallback para funciones críticas.
allowlist temporal queda abierta;
usuario de staging accede a producción;
aplicación y cluster están en regiones lejanas;
backup existe pero KMS/credenciales faltan;
autoscaling oculta una regresión;
Search index queda atrasado;
restore trae schema antiguo;
private endpoint funciona en una VPC pero no en CI;
tier no soporta una capacidad esperada.
considerar Atlas “sin operación”;
usar admin para la app;
abrir red globalmente;
no probar restore;
elegir tier solo por precio;
aplicar índices sugeridos sin medir;
mezclar proyectos de entornos;
ignorar egress;
asumir que toda feature de Atlas existe en Community Server.
Revisa proyectos y owners.
Audita red y usuarios.
Confirma región.
Ejecuta failover test.
Rota credencial.
Restaura backup.
Revisa alertas y budgets.
Ejecuta explain de hot paths.
Evalúa dependencia de servicios Atlas.
Documenta responsabilidad compartida.
Atlas automatiza infraestructura y operación repetitiva, pero la calidad del sistema sigue dependiendo de modelado, queries, permisos y recuperación. Diseña proyectos, red, usuarios, backups, observabilidad y costes como parte del producto. Distingue siempre capacidades core de MongoDB de servicios específicos de Atlas.
Comprueba lo aprendido
¿Qué diferencia existe entre project role y database user?
¿Por qué Atlas no elimina idempotencia?
¿Qué debe incluir un restore test?
¿Cómo evaluarías Performance Advisor?
¿Qué costes suelen olvidarse?
¿Qué significa responsabilidad compartida?