En la lección anterior conocimos a MercadoFresco y decidimos que su futuro está en AWS. Hoy Marta da el primer paso real: crear la cuenta. Parece un trámite administrativo, pero no lo es. Las decisiones que se toman en los primeros veinte minutos de vida de una cuenta —qué correo se usa, cómo se protege el usuario root, con qué identidad se trabaja a diario, qué alarmas de gasto se configuran— determinan si dentro de un año la cuenta será una plataforma sólida o un problema.

Esta lección es deliberadamente meticulosa. Una cuenta mal configurada es la causa número uno de los dos desastres más frecuentes en AWS: la factura sorpresa y la cuenta comprometida. Al terminar tendrás una cuenta creada, protegida, con la facturación vigilada y una lista de comprobación que podrás reutilizar cada vez que abras una cuenta nueva en tu vida profesional.

1. Antes de empezar: qué necesitas a mano
2. El proceso de registro paso a paso
3. El usuario root: qué es y por qué no se usa
4. Cómo blindar el usuario root
5. La identidad de trabajo diaria: IAM Identity Center y el usuario administrador
6. Activar el acceso a facturación para usuarios IAM
7. La capa gratuita en detalle
8. Primera red de seguridad económica: alarma y presupuesto
9. Región por defecto y elección inicial
10. Lista de comprobación de una cuenta recién creada

Marta reúne cuatro cosas antes de abrir el navegador. Ten en cuenta que el registro no se puede completar a medias: si te falta la tarjeta, tendrás que empezar de nuevo.

Marta está tentada de usar [email protected]. Es un error. El correo del usuario root es la llave maestra de la cuenta: quien controla ese buzón puede recuperar la contraseña y tomar el control total. Si Marta se va de la empresa o pierde el acceso a su buzón, MercadoFresco pierde su cuenta de AWS.

La práctica correcta es usar una lista de distribución de empresa que reciban varias personas y que no dependa de ningún empleado concreto:

Y aplica la misma lógica al teléfono: mejor un número corporativo que el móvil personal de alguien.

El alta se hace en https://portal.aws.amazon.com/billing/signup y tiene cinco pasos.

Introduces la dirección de correo del root y un nombre de cuenta (por ejemplo, MercadoFresco Produccion). AWS envía un código de verificación al correo. El nombre de cuenta es descriptivo y podrás cambiarlo después; el correo es mucho más incómodo de cambiar.

Genera una contraseña larga y aleatoria con un gestor de contraseñas y guárdala ahí. No la vas a teclear casi nunca, así que no importa que sea imposible de recordar: al contrario, es deseable.

Eliges entre Empresarial (Business) y Personal. MercadoFresco marca Empresarial e introduce razón social, dirección y NIF. Este dato afecta a cómo se emite la factura y al tratamiento del IVA, así que conviene ponerlo bien desde el principio.

Introduces la tarjeta. AWS realiza un cargo temporal de verificación (alrededor de 1 dólar) que se devuelve. A continuación, verificación por teléfono: recibes un SMS o una llamada automatizada con un código de cuatro dígitos.

Es el último paso y suele generar dudas. Estos son los planes:

Marta elige Basic. Es gratis y se puede subir a Business el día que la tienda dependa de AWS para facturar; ese día, además, el 10 % del gasto será una cifra razonable y proporcional.

Tras confirmar, la cuenta tarda entre unos minutos y unas horas en activarse. Recibirás un correo de bienvenida.

Cuando creas una cuenta de AWS obtienes una identidad especial: el usuario root (raíz), que es literalmente "la persona que se registró con ese correo". No es un usuario IAM, no se le pueden aplicar políticas de permisos y no se le puede restringir: puede hacer absolutamente todo, incluido cerrar la cuenta.

La regla profesional es inequívoca: el root se usa para crear el primer administrador y después se guarda bajo llave. Solo un puñado de tareas lo exigen:

• Cambiar el correo, el nombre o la contraseña de la propia cuenta root.
• Cambiar el plan de soporte o el método de pago.
• Cerrar la cuenta de AWS.
• Restaurar permisos de IAM si alguien se ha bloqueado a sí mismo.
• Registrarse como vendedor en el Marketplace y algunos trámites fiscales.
• Cambiar la política de un bucket S3 que se ha dejado inaccesible para todos.

Si te sorprendes usando el root para lanzar una instancia, para hacer un despliegue o para mirar métricas, algo va mal en tu configuración.

Con el root comprometido, un atacante puede lanzar cientos de instancias de minería de criptomonedas, borrar todas tus copias de seguridad y bloquearte fuera de tu propia cuenta. No existe un "modo seguro" que te proteja: el root está por encima de todo control.

Marta hace estas cuatro cosas el mismo día que crea la cuenta, antes de nada más.

Es la medida más importante de toda la lección. Con MFA, conocer la contraseña no basta: hace falta también un código temporal generado por un dispositivo físico o una aplicación.

Ruta: inicia sesión como root → menú de la cuenta (arriba a la derecha) → Security credentials → sección Multi-factor authentication (MFA) → Assign MFA device.

MercadoFresco usa una aplicación TOTP dentro del gestor de contraseñas de la empresa, para que el código sea recuperable por más de una persona. AWS permite registrar hasta 8 dispositivos MFA en el root: registra al menos dos (por ejemplo, el gestor de la empresa y una llave física guardada en la caja fuerte de la oficina). Así, perder un dispositivo no significa perder la cuenta.

Cuando guardes los códigos de recuperación de la app TOTP, imprímelos y guárdalos físicamente. No los dejes en la misma cuenta de correo que sirve para recuperar el acceso.

En la misma pantalla de Security credentials verás la sección Access keys. Deja esa sección vacía. Una clave de acceso del root es una credencial permanente con poder total: si acaba en un repositorio de Git, en un fichero de configuración o en el portátil de alguien, la cuenta está perdida. Si ya existe alguna clave heredada de otra época, elimínala.

Ya lo hemos hecho al registrarnos. Verifica que el correo del root sea la lista de distribución y no el buzón de una persona.

En Account settings puedes definir contactos alternativos de Facturación, Operaciones y Seguridad. Rellénalos con direcciones de empresa: AWS los usará para avisos de abuso, brechas o problemas de pago. Sin ellos, un aviso crítico puede quedarse en un buzón que nadie mira.

Con el root a salvo, necesitamos una identidad para trabajar día a día. Hay dos caminos, y conviene que conozcas ambos aunque en este curso usemos el segundo para simplificar.

Recomendación profesional: usa IAM Identity Center desde el primer día si vas a tener varias personas o varias cuentas. Es gratis, y evita para siempre el problema de las claves permanentes. En MercadoFresco Marta lo activará más adelante, cuando entren Luis y Sara y aparezcan las cuentas de desarrollo y producción (el gobierno multicuenta se ve en la lección 09-04).

Para el resto del curso trabajaremos con un usuario administrador IAM llamado mercadofresco-admin, porque es la forma más sencilla de seguir los ejemplos con una sola cuenta.

Iniciando sesión como root, ve a IAM → Users → Create user:

1. Nombre de usuario: mercadofresco-admin.
2. Marca Provide user access to the AWS Management Console y elige contraseña personalizada; desmarca la opción de obligar a cambiarla si vas a guardarla en el gestor.
3. En la pantalla de permisos, elige Attach policies directly y adjunta la política gestionada por AWS AdministratorAccess.
4. Crea el usuario y guarda el enlace de inicio de sesión que AWS te muestra. Tiene esta forma:

Ese 111122223333 es el ID de cuenta (12 dígitos). Anótalo: lo usarás constantemente.

5. Activa MFA también en este usuario. Un administrador sin MFA es casi tan peligroso como un root sin MFA.

Sobre las políticas: AdministratorAccess concede permiso sobre casi todo. Es aceptable para el único administrador de una cuenta de aprendizaje, pero no es lo que se hace en una empresa madura, donde cada persona recibe el mínimo privilegio necesario. Cómo se escriben esas políticas con precisión es el tema de la lección 04-01 (IAM); aquí no entramos en el detalle.

Recordar 111122223333 es incómodo. En IAM → panel principal → Account Alias → Create, pon mercadofresco. A partir de ese momento el enlace de acceso es mucho más legible:

El alias debe ser único en todo AWS, así que puede que necesites añadir un sufijo.

Termina cerrando la sesión del root y volviendo a entrar como mercadofresco-admin. A partir de aquí, todo el curso se hace con este usuario.

Aquí hay una trampa que sorprende a casi todo el mundo. Por defecto, solo el usuario root puede ver la consola de facturación, aunque otro usuario tenga AdministratorAccess. Si Marta no lo cambia, entrará como administradora, pulsará en Billing y verá un error de acceso denegado.

Para activarlo hay que hacerlo como root, una sola vez:

1. Inicia sesión como root.
2. Menú de la cuenta (arriba a la derecha) → Account.
3. Baja hasta IAM user and role access to Billing Information.
4. Pulsa Edit, marca Activate IAM Access y Update.

Esta es una de las poquísimas tareas legítimas del root. Hazla ahora y no tendrás que volver a entrar como root en semanas.

La capa gratuita (Free Tier) tiene tres modalidades distintas, y confundirlas es una fuente habitual de facturas inesperadas.

Cuatro advertencias que ahorran dinero de verdad:

• La cuota es por cuenta, no por recurso. Las 750 horas mensuales de EC2 son el total: dos instancias encendidas todo el mes son ~1 460 horas, así que la segunda se factura.
• El tipo de instancia importa. Una t3.micro puede entrar en la capa gratuita; una t3.small se factura íntegra desde el primer segundo.
• La capa gratuita no cubre todo lo asociado. Un balanceador de carga, una IP elástica sin asociar o una instantánea grande se facturan aunque tu instancia sea gratuita.
• Vigila el mes 13. Marca en el calendario la fecha del alta más un año. Ese día, todo lo que seguía encendido "porque era gratis" empieza a costar dinero.

AWS ofrece un panel en Billing and Cost Management → Free tier donde ves tu consumo frente a cada cuota. Revísalo la primera semana de cada mes.

Nunca debes tener una cuenta de AWS sin vigilancia de gasto. Vamos a montar dos capas mínimas. La gestión avanzada de presupuestos es la lección 11-04; aquí ponemos solo lo imprescindible.

En Billing and Cost Management → Billing preferences, activa:

• Receive AWS Free Tier alerts, con el correo [email protected].
• Receive PDF invoice by email, para que la factura llegue al buzón de administración.

Con esto AWS te avisa cuando superas el 85 % de alguna cuota gratuita. Es gratis y tarda diez segundos.

Marta crea un presupuesto de 10 $ al mes, cifra deliberadamente baja: cualquier desviación saltará pronto. Ruta: Billing and Cost Management → Budgets → Create budget → Cost budget.

La tercera alerta es la más valiosa: te avisa cuando AWS proyecta que vas a superar el presupuesto a fin de mes, no cuando ya lo has superado. Si el día 4 dejas encendido algo caro, esa alerta salta el día 5, no el día 30.

Los dos primeros presupuestos son gratuitos; a partir del tercero cuestan unos céntimos al día.

Es la alternativa clásica y sigue siendo útil porque puede disparar acciones (por ejemplo, un aviso a un canal de chat). Requiere dos cosas importantes:

• La métrica de facturación solo existe en la región us-east-1 (Norte de Virginia), aunque tus recursos estén en Europa. Es una de las rarezas de AWS.
• Debes activar Receive Billing Alerts en Billing preferences antes de que la métrica aparezca.

Pasos: cambia a la región US East (N. Virginia) → CloudWatch → Alarms → Create alarm → Select metric → Billing → Total Estimated Charge → moneda USD → condición Greater than 10 → crea un tema de SNS con tu correo → confirma la suscripción desde el correo que recibas (si no confirmas, no llegarán las alertas).

Coste: una alarma de CloudWatch está dentro de la capa gratuita (10 alarmas al mes). El tema de SNS y unos pocos correos también. Este montaje no debería costarte nada.

CloudWatch a fondo (métricas, logs, paneles y alarmas complejas) es la lección 05-01.

Cada vez que creas un recurso en AWS, lo creas dentro de una región concreta. La consola tiene un selector de región arriba a la derecha, y lo que crees quedará en la que estuviera seleccionada.

MercadoFresco elige eu-west-1 (Irlanda) como región principal. Los tres motivos, en corto:

1. Latencia: está cerca de sus clientes españoles.
2. Catálogo y precio: es una de las regiones europeas más completas y económicas.
3. Residencia del dato: está en la Unión Europea, lo cual encaja con el RGPD.

Los criterios completos de elección de región, junto con las alternativas eu-south-2 (España) y eu-west-3 (París), se analizan en detalle en la lección 01-03. Por ahora, quédate con dos reglas prácticas:

• Fija tu región y compruébala siempre antes de crear algo. Crear recursos dispersos por regiones distintas es el error más común de los principiantes (lo veremos en 01-04).
• Excepción conocida: las alarmas de facturación viven en us-east-1, como acabamos de ver.

Guarda esta lista. Es aplicable a cualquier cuenta de AWS que abras en tu carrera profesional.

• Registrar la cuenta con el correo personal de un empleado. Cuando esa persona se marche, recuperar el control puede convertirse en un proceso largo con el soporte de AWS. Usa siempre un alias corporativo.
• Posponer el MFA del root "para mañana". Las cuentas nuevas se escanean activamente. Actívalo en los primeros minutos, no después del primer despliegue.
• Crear claves de acceso para el root porque "es más rápido para probar la CLI". Es la forma más eficaz de perder una cuenta. En la lección 01-05 configuraremos la CLI con las credenciales del usuario administrador, nunca con las del root.
• Trabajar como root porque "así no hay problemas de permisos". Además de peligroso, impide aprender IAM y hace que CloudTrail registre todo bajo la misma identidad, arruinando la auditoría (CloudTrail se ve en 05-03).
• Sorprenderse porque el administrador no ve la facturación. Recuerda: hay que activarlo explícitamente desde el root.
• Confiar en que "la capa gratuita me protege". No es un límite de gasto: es un descuento. Si superas la cuota, se factura sin bloquear nada. La protección real son las alertas.
• Consejo: guarda en el gestor de contraseñas de la empresa una ficha con el ID de cuenta, el alias, la URL de acceso, el correo del root y dónde están los dispositivos MFA. El día que haya una urgencia, esa ficha vale su peso en oro.
• Consejo: si vas a hacer el curso completo, plantéate desde ya que en una empresa real habrá varias cuentas (desarrollo, producción). Ese diseño se aborda en la lección 09-04.

Crea tu propia cuenta de AWS siguiendo la lección y completa los puntos 1 a 9 de la lista de comprobación. Después responde por escrito:

• ¿Qué correo has usado y por qué?
• ¿Qué tipo de dispositivo MFA has elegido para el root y qué harías si lo perdieras?
• ¿Cuál es tu ID de cuenta y tu URL de acceso como administrador?

Coste: el registro es gratuito. Solo verás un cargo temporal de verificación de ~1 $ que AWS devuelve. No crees ningún recurso todavía.

Configura, en tu cuenta:

1. Las alertas de capa gratuita y la recepción de la factura en PDF.
2. Un presupuesto mensual de 5 USD con tres alertas: 50 % real, 100 % real y 100 % previsto.
3. Explica en dos frases por qué la alerta sobre el importe previsto es más útil que la del importe real para reaccionar a tiempo.

MercadoFresco contrata a Luis (desarrollador) y a Sara (analista de negocio). Marta te pregunta cómo deberían acceder a AWS. Responde justificando:

1. ¿Debería Marta compartir con ellos las credenciales de mercadofresco-admin? ¿Por qué?
2. ¿Qué opción de identidad recomendarías (usuarios IAM o IAM Identity Center) y con qué argumento?
3. Sara solo necesita ver informes de costes y algunas métricas. ¿Qué principio de seguridad debe guiar sus permisos y en qué lección del curso se desarrolla?
4. El nuevo contable pide acceso solo a las facturas. ¿Qué paso previo hay que haber dado en la cuenta para que eso sea siquiera posible?

Solución 1

Respuestas modelo:

• Correo: un alias de empresa tipo [email protected] que reenvía a varias personas. Motivo: el correo del root es la vía de recuperación de la cuenta; no debe depender de una persona que pueda irse o perder el acceso.
• MFA: una aplicación TOTP dentro del gestor de contraseñas corporativo, más una llave física de respaldo registrada como segundo dispositivo. Si se pierde uno, se entra con el otro. Si se perdieran ambos, habría que iniciar el proceso de recuperación con el soporte de AWS verificando identidad, correo y teléfono, lo que puede tardar días: por eso se registran dos.
• ID de cuenta y URL: los 12 dígitos que aparecen en el menú superior y la URL https://<alias>.signin.aws.amazon.com/console.

Solución 2

1. En Billing and Cost Management → Billing preferences, marcar Receive AWS Free Tier alerts y Receive PDF invoice by email, indicando el correo de alertas.
2. En Budgets → Create budget → Cost budget: período mensual recurrente, importe 5 USD, y tres alertas: Actual > 50 %, Actual > 100 % y Forecasted > 100 %, todas notificando por correo.
3. La alerta de importe real te informa de un gasto que ya se ha producido y no puedes deshacer. La alerta de importe previsto se dispara cuando la tendencia de consumo indica que superarás el límite a fin de mes, lo que te da días de margen para apagar el recurso culpable antes de que el gasto ocurra.

Solución 3

1. No. Compartir credenciales rompe la trazabilidad: CloudTrail registraría todas las acciones bajo la misma identidad y sería imposible saber quién hizo qué. Además obliga a rotar la contraseña cada vez que alguien deja el equipo, y concede a todo el mundo permisos de administrador que no necesita.
2. IAM Identity Center, porque emite credenciales temporales en lugar de claves permanentes, centraliza altas y bajas en un único sitio, permite asignar distintos conjuntos de permisos a cada persona y escala sin dolor cuando aparezcan las cuentas separadas de desarrollo y producción.
3. El principio de mínimo privilegio: cada identidad recibe únicamente los permisos que necesita para su trabajo, ni uno más. Para Sara, permisos de lectura sobre facturación y métricas. Se desarrolla en la lección 04-01 (IAM).
4. Haber activado el acceso de usuarios y roles IAM a la información de facturación desde el usuario root (Account → IAM user and role access to Billing Information). Sin ese paso, ninguna identidad distinta del root puede ver la facturación, por muchos permisos que se le concedan.

MercadoFresco ya tiene una cuenta de AWS, y —lo que es más importante— la tiene bien puesta. Has visto el proceso de registro completo, has entendido por qué el usuario root es una llave maestra que se protege con MFA y se guarda bajo llave, y has creado la identidad mercadofresco-admin con la que trabajaremos el resto del curso. Has activado el acceso a facturación para usuarios IAM, comprendido las tres modalidades de capa gratuita y montado la primera red de seguridad económica con alertas y un presupuesto que te avisará antes de que la factura se dispare. Y tienes una lista de comprobación reutilizable para cualquier cuenta futura.

Queda una decisión pendiente que hemos dejado apuntada: la región. Elegimos eu-west-1 casi de palabra, pero esa decisión merece entenderse bien, porque condiciona la latencia de tus clientes, el precio de cada servicio, qué servicios tienes disponibles y dónde residen legalmente tus datos.

En la siguiente lección, 01-03 «Infraestructura global de AWS», abrimos el capó: qué es exactamente una región, qué es de verdad una zona de disponibilidad, cómo se sobrevive a la caída de un centro de datos completo y cómo razonar la elección de región para una tienda con clientes en España.