Guía para empezar con AWS en 2026: los servicios que usamos en Arena
Por dónde empezar con AWS: los servicios esenciales
AWS tiene más de 200 servicios, pero un proyecto real se sostiene sobre unos pocos. En Arena desplegamos productos para entidades financieras, como SmartConverter, y siempre volvemos a los mismos seis: VPC, IAM, EKS con ECR, RDS, S3 con Secrets Manager y KMS, y CloudWatch.
Esta guía no repite la documentación oficial. Cuenta para qué sirve cada servicio, cómo lo usamos nosotros y qué errores conviene evitar desde el primer día.
La nube no es automáticamente más barata que un centro de datos propio. Lo es cuando se paga solo por lo que se usa y se controla el gasto. Lo que sí cambia siempre es el tiempo: un entorno que antes tardaba semanas en montarse hoy se levanta en minutos, y en Arena lo hacemos desde código, como contamos en nuestro artículo sobre Terraform y Jenkins en SmartConverter.
En banca hay dos condiciones más: los datos deben quedarse donde exige el cliente y cada acceso debe quedar registrado. Por eso desplegamos en la región de AWS en España (eu-south-2) y cada decisión de esta guía tiene en cuenta la seguridad desde el principio.
Cómo se integran los servicios de AWS en una arquitectura cloud
Antes de ver cada servicio por separado, este es el esquema que repetimos en nuestros productos.
Figura 1 · Cómo encajan los seis servicios en un producto de Arena
Las peticiones entran solo por el balanceador y llegan a las aplicaciones en EKS. Estas leen sus imágenes de ECR y sus credenciales de Secrets Manager, y guardan los datos en RDS y S3. IAM y CloudWatch abarcan todo el conjunto, controlando los accesos y la monitorización.
Amazon VPC: cómo configurar una red privada y segura en AWS
Antes de lanzar ningún servicio hay que decidir qué puede hablar con qué. Para eso existe Amazon VPC (Virtual Private Cloud): una red privada y aislada dentro de AWS donde se despliega todo lo demás. Dentro se definen subredes públicas (alcanzables desde internet) y privadas (solo desde dentro), y las reglas de tráfico entre ellas.
Cómo utilizamos Amazon VPC en ARENA
Nuestras VPC se reparten en tres zonas de disponibilidad, para que la caída de un centro de datos no detenga el servicio. En la subred pública solo están el balanceador, que recibe las peticiones, y la salida a internet (NAT). Las aplicaciones y las bases de datos viven en subredes privadas. Delante de todo lo que se expone a internet hay un firewall de aplicaciones (WAF).
Figura 2 · VPC de Arena · una subred pública y dos privadas
AWS IAM: gestión de identidades, accesos y permisos en la nube
AWS Identity and Access Management (IAM) controla quién puede hacer qué dentro de una cuenta de AWS. Cada persona, aplicación o servicio accede a través de un rol con permisos definidos explícitamente.
El principio que lo sostiene es el de mínimo privilegio: cada uno tiene acceso solo a lo que necesita para su función, ni un permiso más.
Cómo gestionamos los permisos de acceso en ARENA
Definimos cuatro perfiles de acceso, siempre desde Terraform:
Administración de plataforma: acceso completo, solo para aplicar cambios de infraestructura. No es el rol de trabajo diario de nadie.
DevOps: despliega y opera, pero no puede tocar permisos ni modificar las bases de datos.
Desarrollo: lectura general y despliegue solo en los entornos de desarrollo.
Desarrollo ampliado: lo mismo que desarrollo, más la gestión de usuarios de la aplicación.
Las aplicaciones no usan claves de acceso. Cada microservicio recibe un rol propio (EKS Pod Identity) con los permisos justos para lo que hace, y AWS renueva sus credenciales automáticamente. Cada llamada queda registrada en CloudTrail.
Figura 3 · Perfiles de acceso de las personas y rol propio de cada microservicio
Error común: guardar claves de acceso en el código, en un fichero de configuración o en variables de entorno. Una clave filtrada en un repositorio da acceso a la cuenta a cualquiera que la encuentre.
Amazon EKS y ECR: despliegue y gestión de aplicaciones con contenedores
El primer servicio que casi todo el mundo prueba es Amazon EC2: servidores virtuales bajo demanda. Sigue siendo la base de casi todo, pero gestionar máquinas sueltas escala mal cuando un producto tiene decenas de microservicios.
Por eso en ARENA empaquetamos cada servicio en un contenedor. Amazon ECR (Elastic Container Registry) es el registro donde se guardan esas imágenes, con su versión. Amazon EKS (Elastic Kubernetes Service) es el servicio gestionado de Kubernetes que las ejecuta: reparte la carga, reinicia lo que falla y añade capacidad cuando sube el tráfico.
Las máquinas EC2 siguen ahí, pero en modo Auto Mode es EKS quien las crea y las retira.
Cómo desplegamos microservicios con EKS y ECR en ARENA
Un único clúster sirve a los entornos de desarrollo y preproducción, separados por espacios de nombres (namespaces) con cuotas de recursos y reglas de red que aíslan unos productos de otros.
Nuestro pipeline de Jenkins compila cada servicio, publica la imagen en ECR y la despliega en EKS.
Figura 4 · Del código al clúster: Jenkins, ECR y EKS
Error común: acumular imágenes antiguas sin límite. Una política de ciclo de vida en ECR conserva solo las últimas versiones y evita pagar por almacenamiento que nadie usa.
Amazon RDS: bases de datos gestionadas y alta disponibilidad en AWS
Amazon RDS (Relational Database Service) ofrece bases de datos relacionales gestionadas (PostgreSQL, MySQL, SQL Server, entre otras).
AWS se encarga de instalarlas, aplicar parches y hacer copias de seguridad; el equipo se ocupa del esquema y de las consultas.
Incluye réplicas de lectura y alta disponibilidad Multi-AZ: una instancia secundaria en otra zona que toma el relevo si la principal falla.
Cómo gestionamos las bases de datos en ARENA
Trabajamos con PostgreSQL, y con Aurora en SmartConverter. Ajustamos la configuración a cada entorno:
Desarrollo: una sola instancia, porque aquí una caída no afecta a nadie fuera del equipo.
Preproducción: Multi-AZ con réplica, para validar la alta disponibilidad antes de producción.
Fuera de producción: las bases de datos se apagan solas de 21:00 a 07:00 entre semana. Nadie las usa a esas horas y el ahorro es directo.
Los datos se cifran con claves propias y las credenciales viven en Secrets Manager, nunca en el código.
Figura 5 · Configuración de RDS por entorno y horario de apagado
Error común: poner la base de datos en una subred pública «para conectarse más fácil». Debe vivir en la subred privada y aceptar conexiones solo de las aplicaciones que la usan.
Amazon S3, Secrets Manager y KMS: almacenamiento y seguridad de datos en AWS
Estos tres servicios protegen lo más sensible de una aplicación: sus archivos, sus contraseñas y las claves que cifran ambos.
Amazon S3: almacenamiento seguro de archivos en la nube
Amazon S3 almacena objetos: ficheros, copias de seguridad, logs. Cada archivo vive en un bucket y AWS lo replica automáticamente entre varias ubicaciones, así que perder un dato es prácticamente imposible. Hay distintas clases de almacenamiento, más rápidas o más baratas según la frecuencia de acceso.
AWS Secrets Manager: gestión segura de credenciales
AWS Secrets Manager guarda las credenciales (de la base de datos, de servicios externos) fuera del código. Las aplicaciones las piden en tiempo de ejecución, solo si su rol lo permite.
AWS KMS: cifrado y protección de la información
AWS Key Management Service (KMS) gestiona las claves de cifrado. Una clave propia es también la forma de revocar el acceso: si se desactiva, lo que cifra deja de poder leerse.
Cómo protegemos los datos y las credenciales en ARENA
Todos nuestros buckets tienen bloqueado el acceso público, con cifrado y versionado activados. En uno de ellos guardamos el estado de Terraform, que describe toda nuestra infraestructura.
Usamos tres claves KMS separadas: una para datos, otra para secretos y otra para logs. Así, revocar el acceso a los datos no borra la trazabilidad de lo que pasó.
Figura 6 · Una clave KMS distinta para datos, secretos y logs
Error común: dejar un bucket abierto a internet. Es una de las causas más frecuentes de fugas de datos en la nube, y se evita activando el bloqueo de acceso público desde el primer momento.
Amazon CloudWatch: monitorización y observabilidad de aplicaciones en AWS
Amazon CloudWatch es el sistema de monitorización de AWS: recoge métricas (CPU, memoria, tráfico), centraliza logs y lanza alarmas cuando algo se sale de lo normal.
Sirve para detectar un problema antes de que lo note un usuario y para reconstruir después qué pasó y cuándo.
Cómo monitorizamos nuestras aplicaciones en ARENA
Tenemos alarmas sobre las bases de datos y enviamos a CloudWatch los logs del firewall de aplicaciones (WAF) que protege nuestras consolas, con los datos sensibles ocultos.
Para las métricas de las aplicaciones lo complementamos con un stack open source de Prometheus y Grafana, del que hablaremos en otro artículo de CreArena.
Error común: recoger logs sin fijar cuánto tiempo se guardan ni quién puede leerlos. Acaban costando dinero y, en banca, pueden contener datos que no deberían estar a la vista de todo el equipo.
6 errores comunes al configurar servicios de AWS y cómo evitarlos
Error frecuente | Cómo lo evitamos en ARENA |
|---|---|
Cambiar la infraestructura a mano desde la consola | Todo se define en Terraform y se aplica desde el pipeline. |
Claves de acceso en el código o en variables de entorno | Roles por servicio (EKS Pod Identity) y secretos en Secrets Manager. |
Aplicaciones y bases de datos en la subred pública | Solo el balanceador y la salida a internet son públicos. |
Buckets de S3 abiertos a internet | Bloqueo de acceso público, cifrado y versionado en todos. |
Entornos de pruebas encendidos 24/7 | Bases de datos apagadas de noche y una sola salida a internet en desarrollo. |
Recursos sin etiquetas | Etiquetas obligatorias de cliente, proyecto y entorno para saber qué cuesta cada cosa. |
Claves para desplegar aplicaciones seguras y eficientes en AWS
Con seis servicios se cubre casi todo lo que necesita una aplicación en producción: cómo se conecta (VPC), quién accede (IAM), dónde corre (EKS y ECR), dónde viven los datos (RDS y S3), cómo se protegen (Secrets Manager y KMS) y cómo se vigila (CloudWatch).
No hace falta dominar los 200 servicios de AWS para empezar. Hace falta configurar bien estos fundamentos desde el primer día, porque corregir un error de red o de permisos con el producto en producción cuesta mucho más.
A partir de ahí, cada proyecto suma servicios más específicos según lo que necesite de verdad, no al revés.
