En mi rol en DoiT, trabajo a diario con startups que recién están comenzando su camino en la nube.
Y veo los mismos errores una y otra vez.
Comparto algunos aquí con la esperanza de que puedas evitarlos antes de que se vuelvan costosos, dolorosos o difíciles de corregir:
1\. La cuenta de AWS se abre con el correo personal de un fundador
Es muy frecuente que la primera cuenta de AWS se cree con la dirección personal de Gmail de un fundador.
En ese escenario, la cuenta pertenece legal y operativamente a una persona, no a la empresa.
Si el fundador se va, hay un conflicto o (en el peor de los casos) le ocurre algo, la titularidad se convierte en un riesgo serio para el negocio.
A esto se suma que el correo personal suele ser menos seguro que un buzón corporativo: sin MFA obligatorio, sin auditoría centralizada, con una gobernanza de identidad más débil y un obstáculo enorme a la hora de pasar una auditoría de certificación.
Si el correo del fundador se ve comprometido, normalmente eso significa control total sobre el entorno de AWS de la empresa.
Esto también genera un punto único de falla.
Buena práctica:
Crea un buzón compartido de grupo, por ejemplo: [email protected]
Suma al menos a dos personas del equipo (siempre hay alguien enfermo, de vacaciones o en una conferencia) y usa plus-addressing para separar entornos en distintas cuentas de AWS:
2\. Crear recursos en la Management Account
Una startup arranca con una sola cuenta de AWS donde vive todo: producción, desarrollo, demos y el playground de algún developer.
A medida que la empresa crece, hace falta separar entornos. La salida más fácil parece ser convertir esa única cuenta en la Management Account de AWS Organizations y crear nuevas cuentas miembro desde la organización.
El problema: la management account es la única cuenta que no se puede gobernar con controles a nivel de organización.
Documentación de Service Control Policies de AWS Organizations
Políticas típicas que vas a querer aplicar:
- Todos los volúmenes EBS de EC2 deben estar cifrados.
- No se pueden crear recursos en regiones no autorizadas.
- Los tipos de instancia costosos (GPU) están restringidos.
- Se prohíben los usuarios IAM (solo se permiten roles).
Ninguna de estas reglas aplica a la Management Account, que en este caso también es la cuenta de producción.
Peor todavía: AWS no permite convertir una Management Account en Member Account.
Una vez que la cuenta de producción es además la management account, la única salida es una migración organizacional completa: rearmar la organización, recrear las políticas, reconfigurar los permisos y volver a registrar a cada empleado en un nuevo endpoint de Single Sign On (SSO).
Si hoy estás en una etapa en la que todo corre en una sola cuenta de AWS y quieres empezar a separar entornos, crea una nueva cuenta de AWS independiente, configúrala como Management Account vía AWS Organizations e invita a la cuenta de producción actual a sumarse como cuenta miembro a la nueva organización.
3\. Postergar el cumplimiento normativo
Si tu plan es venderle a clientes enterprise, tarde o temprano te van a pedir cumplimiento normativo:
- SOC 2 / ISO 27001 para SaaS B2B
- HIPAA para el sector salud
- PCI DSS para fintech y pagos
Adaptar un producto y una organización ya en marcha a nuevos requisitos de cumplimiento es extremadamente difícil.
No solo impacta en la arquitectura en la nube, sino también en los flujos de desarrollo, el control de accesos e incluso los contratos laborales (titularidad de la propiedad intelectual, confidencialidad, gestión de dispositivos, etc.).
Ajustar la infraestructura en la nube es retador, pero se logra. Cambiar contratos y procesos organizacionales más adelante es mucho más complicado. Por eso, sumar un partner de asesoría en cumplimiento desde las primeras líneas de código de tu producto simplifica enormemente el camino.
4\. Todos los huevos en la misma canasta
AWS te permite gestionar el registro de dominios, su renovación y el DNS dentro de Route 53; es cómodo y peligroso a la vez.
Si la cuenta de AWS queda suspendida (por un problema de facturación, un incidente de seguridad o una clave IAM filtrada), tu dominio también puede verse afectado.
Cuando el correo deja de funcionar, se vuelve muy difícil comunicarse con AWS Support para resolver el problema.
publicaciones de r/aws en Reddit.com
Buena práctica:
Mantén el dominio principal de la empresa fuera de la cuenta principal de producción de AWS, ya sea en un proveedor distinto como GoDaddy o NameCheap, o en una cuenta de AWS dedicada. Si pierdes el acceso a tu cuenta de producción, todavía vas a poder mantener los registros DNS con el otro proveedor o la otra cuenta.
5\. Lleva un calendario de vencimientos para no perder fechas críticas de renovación
Incluso durante el primer año, una startup acumula rápidamente:
- Contratos
- API keys
- Tarjetas de crédito
Lo que todos tienen en común es una fecha de vencimiento.
Los desenlaces no deseados suelen ser:
- Cuentas de AWS bloqueadas por falta de pago.
- Caídas inesperadas de servicios por una API key vencida.
- Negociaciones de renovación de contratos a las apuradas por fechas vencidas o muy próximas.
Un calendario compartido con recordatorios automáticos ("La tarjeta de crédito 3344 vence en 30 días", "Renovación del contrato con el proveedor MAP en 45 días") ayuda a prevenir estos problemas.
Reflexión final
Hay muchos retos por delante. Recomiendo encarecidamente buscar un mentor que ya haya sido fundador y haya liderado varias startups. El consejo de quien tiene experiencia vale oro.
Si quieres construir tu nube como corresponde desde el día uno, DoiT aporta la tecnología, el conocimiento y años de experiencia ayudando tanto a startups como a empresas globales a evitar justamente estos errores, y muchos más.
Convirtamos tu nube en un motor de crecimiento, no en un factor de riesgo.