Servicios esenciales de AWS: IAM, VPC, EC2, S3, RDS, Lambda y lo que los une

Amazon Web Services ofrece bastante más de doscientos servicios, pero un sistema de producción típico utiliza quizá quince, y casi siempre son los mismos quince. Esta guía los recorre: para qué sirve cada uno, qué decisiones tomas al configurarlo y cómo se conecta con sus vecinos. Da por hecho que has leído la guía de fundamentos del cloud y sabes qué son una región, una zona de disponibilidad y el modelo de responsabilidad compartida. Los nombres de los servicios son los oficiales actuales; cuando AWS ha renombrado algo recientemente, el nombre antiguo se menciona una vez.

Cuentas, organizaciones e IAM

Todo en AWS vive dentro de una cuenta, que es a la vez un límite de facturación y un límite de seguridad infranqueable. Las empresas rara vez funcionan con una sola cuenta: AWS Organizations te permite crear muchas cuentas bajo una cuenta de administración, agruparlas en unidades organizativas y aplicar service control policies (SCP) que limitan lo que puede hacer cualquier identidad dentro de esas cuentas; por ejemplo, prohibir la creación de recursos fuera de las regiones aprobadas. Tener cuentas separadas para producción, no producción, herramientas de seguridad y archivo de logs es la base estándar.

Dentro de una cuenta, AWS Identity and Access Management (IAM) decide quién puede llamar a qué API sobre qué recurso. El vocabulario:

• Los principals son identidades: usuarios IAM (de larga duración, con contraseña o claves de acceso), roles IAM (asumidos temporalmente, sin credenciales permanentes) e identidades federadas de un proveedor externo a través de IAM Identity Center o SAML/OIDC.
• Las políticas son documentos JSON que permiten o deniegan acciones sobre recursos, opcionalmente bajo condiciones. Las políticas basadas en identidad se asocian a principals; las basadas en recursos se asocian al propio recurso (un bucket de S3, una cola, una clave de KMS).
• Los roles son el caballo de batalla. Un rol tiene una trust policy que indica quién puede asumirlo y políticas de permisos que indican qué puede hacer quien lo asume. Las instancias EC2, las funciones Lambda, las tareas de ECS y los pods de Kubernetes obtienen sus permisos al asociarse a un rol; la plataforma inyecta credenciales de corta duración que rotan automáticamente.

La lógica de evaluación es fácil de enunciar y conviene memorizarla: todo está denegado por defecto; un Allow explícito en una política aplicable concede el acceso; un Deny explícito en cualquier sitio prevalece sobre cualquier Allow; las SCP y los permission boundaries fijan un techo exterior que las políticas de identidad no pueden superar.

Una política de mínimo privilegio para un servicio que lee objetos de un prefijo de un bucket y escribe en una cola tiene este aspecto:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadInvoices",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-billing-prod/invoices/*"
    },
    {
      "Sid": "ListInvoicePrefixOnly",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::acme-billing-prod",
      "Condition": { "StringLike": { "s3:prefix": ["invoices/*"] } }
    },
    {
      "Sid": "EnqueueWork",
      "Effect": "Allow",
      "Action": ["sqs:SendMessage"],
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:invoice-processing"
    }
  ]
}

Cada recurso se identifica con un Amazon Resource Name (ARN) con el patrón arn:partition:service:region:account-id:resource. Los servicios globales como S3 e IAM dejan vacío el campo de región. Los comodines en el campo Resource son el origen de la mayoría de las políticas demasiado permisivas: "Resource": "*" combinado con "Action": "s3:*" le da al principal todos los buckets de la cuenta.

Redes: la VPC

Una Amazon Virtual Private Cloud (VPC) es una red aislada lógicamente dentro de una región, con un rango CIDR IPv4 que eliges tú (y, opcionalmente, IPv6). Dentro de ella creas subredes, cada una ligada a una zona de disponibilidad. Una subred es pública si su tabla de rutas envía 0.0.0.0/0 a un internet gateway; si no, es privada. Esa distinción es exclusivamente una decisión de enrutamiento: no existe ningún otro indicador.

Una distribución convencional para una aplicación de tres capas en tres zonas:

VPC 10.20.0.0/16 (eu-west-1)
├── public-a  10.20.0.0/24   ALB nodes, NAT gateway      → route 0.0.0.0/0 → internet gateway
├── public-b  10.20.1.0/24   ALB nodes, NAT gateway
├── public-c  10.20.2.0/24   ALB nodes, NAT gateway
├── app-a     10.20.10.0/24  EC2 / ECS tasks             → route 0.0.0.0/0 → NAT gateway (same AZ)
├── app-b     10.20.11.0/24
├── app-c     10.20.12.0/24
├── data-a    10.20.20.0/24  RDS primary                 → no default route at all
├── data-b    10.20.21.0/24  RDS standby
└── data-c    10.20.22.0/24

Las instancias de la aplicación se sitúan en subredes privadas y acceden a internet para sus llamadas salientes a través de un NAT gateway ubicado en una subred pública. Despliega un NAT gateway por zona: uno único compartido crea una dependencia entre zonas y un coste de transferencia de datos entre zonas. Las subredes de base de datos no tienen ninguna ruta hacia internet.

El control del tráfico tiene dos capas. Los security groups son firewalls stateful asociados a interfaces de red, y su mejor característica es que una regla puede hacer referencia a otro security group: «permitir el 5432 desde el security group de la capa de aplicación» sobrevive a la sustitución de instancias, cosa que no ocurre con las reglas basadas en IP. Las network ACL son listas stateless a nivel de subred; déjalas con su configuración permisiva por defecto salvo que tengas una necesidad concreta de bloqueo.

Hay dos piezas más que aparecen en casi todas las VPC reales. Los VPC endpoints permiten que las subredes privadas lleguen a servicios de AWS como S3, DynamoDB, Secrets Manager y ECR sin pasar por internet ni por un NAT gateway. El VPC peering o, a gran escala, AWS Transit Gateway conecta las VPC entre sí y con redes on-premises mediante AWS Site-to-Site VPN o AWS Direct Connect.

Cómputo: EC2, contenedores y Lambda

Amazon Elastic Compute Cloud (EC2) proporciona máquinas virtuales. Las decisiones que importan al lanzar una son la Amazon Machine Image (AMI), que es la plantilla del disco de arranque; el tipo de instancia, cuya letra de familia indica su propósito (uso general, optimizada para cómputo, memoria o almacenamiento, acelerada) y cuyo tamaño fija las vCPU y la memoria; la subred y los security groups; el instance profile de IAM que lleva su rol; y los user data, un script que se ejecuta en el primer arranque. Las instancias tienen un ciclo de vida (pending, running, stopping, stopped, terminated) y, algo importante, el disco instance store de algunos tipos desaparece al detenerlas, mientras que los volúmenes EBS persisten.

Las opciones de compra cambian la factura sin cambiar la máquina: On-Demand para tener flexibilidad, Savings Plans o Reserved Instances para obtener descuentos por compromiso en cargas estables, y Spot Instances —capacidad sobrante que AWS puede recuperar con un aviso de dos minutos— para trabajos batch interrumpibles y cargas stateless.

Un Auto Scaling group mantiene en ejecución un número deseado de instancias a partir de un launch template, sustituye las que están en mal estado, las reparte entre las subredes que indiques y ajusta el número según las políticas de escalado (el target tracking sobre CPU o número de peticiones es el punto de partida habitual). Delante de él, Elastic Load Balancing ofrece un Application Load Balancer para HTTP/HTTPS con enrutamiento por ruta y por host, un Network Load Balancer para TCP/UDP con un throughput muy alto e IP estáticas, y un Gateway Load Balancer para appliances virtuales.

# Launch one instance in a private subnet with a role and a startup script
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.small \
  --subnet-id subnet-0a1b2c3d \
  --security-group-ids sg-0f1e2d3c \
  --iam-instance-profile Name=order-service-profile \
  --user-data file://bootstrap.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=service,Value=orders},{Key=env,Value=prod}]'

Los contenedores tienen dos orquestadores. Amazon Elastic Container Service (ECS) es el planificador propio de AWS, más sencillo de operar, con AWS Fargate como modo de lanzamiento serverless que elimina por completo la gestión de hosts. Amazon Elastic Kubernetes Service (EKS) ejecuta Kubernetes upstream para los equipos que buscan portabilidad o ya dominan Kubernetes; consulta la guía de fundamentos de Kubernetes para el modelo de orquestación en sí. Ambos descargan las imágenes de Amazon Elastic Container Registry (ECR).

AWS Lambda ejecuta una función en respuesta a un evento —una petición HTTP a través de API Gateway o de una function URL, un nuevo objeto en S3, un mensaje en una cola, una programación— sin ninguna instancia que gestionar. Eliges un runtime (Java, Python, Node.js, .NET, Go y runtimes personalizados mediante contenedores), un tamaño de memoria que también escala la parte de CPU y un timeout con un límite máximo que se mide en minutos. Lambda encaja en cargas orientadas a eventos, con picos o de tipo «pegamento»; los procesos de larga duración, las cargas que necesitan conexiones persistentes y todo lo sensible a la latencia de los cold starts están mejor en contenedores.

Almacenamiento: EBS, EFS y S3

Amazon Elastic Block Store (EBS) proporciona volúmenes de bloque que se conectan a una instancia EC2 de la misma zona de disponibilidad: el disco de una máquina virtual. Los tipos de volumen equilibran coste frente a throughput e IOPS; el SSD de uso general (gp3) es la opción por defecto, y el SSD con IOPS aprovisionadas (io2) existe para bases de datos exigentes. Los snapshots son copias incrementales almacenadas en S3 y son la forma de hacer copias de seguridad y clonar volúmenes. Como un volumen está ligado a su zona, una instancia de otra zona no puede montarlo; esa restricción por sí sola descarta EBS como almacenamiento compartido.

Amazon Elastic File System (EFS) es un sistema de archivos NFS gestionado que pueden montar a la vez muchas instancias repartidas entre zonas, pensado para cargas que de verdad necesitan un sistema de archivos POSIX compartido, como los gestores de contenidos o las aplicaciones migradas en lift-and-shift que escriben en un directorio común.

Amazon Simple Storage Service (S3) es almacenamiento de objetos: los buckets contienen objetos direccionados por clave, accesibles por HTTPS, sin semántica de sistema de archivos y con una capacidad prácticamente ilimitada. Es el destino por defecto de copias de seguridad, logs, sitios web estáticos, archivos de data lake, contenido multimedia y cualquier cosa que se escriba una vez y se lea muchas. Funcionalidades que conviene conocer desde el primer día:

• Las clases de almacenamiento (Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant/Flexible/Deep Archive) equilibran velocidad de recuperación y coste por petición frente al coste de almacenamiento; las lifecycle rules mueven objetos entre clases y los hacen caducar.
• El versionado conserva cada sobrescritura y cada borrado, y es tu protección frente a borrados accidentales y sobrescrituras al estilo ransomware.
• Block Public Access a nivel de cuenta debe estar activado salvo que sirvas deliberadamente un sitio público.
• El cifrado del lado del servidor está activado por defecto; puedes elegir una clave gestionada por AWS o tu propia clave en AWS Key Management Service (KMS).
• Las URL prefirmadas conceden acceso temporal a un único objeto sin hacer público el bucket.

aws s3api put-bucket-versioning --bucket acme-billing-prod \
  --versioning-configuration Status=Enabled
aws s3 cp ./reports/2026-09.pdf s3://acme-billing-prod/reports/2026-09.pdf \
  --storage-class STANDARD_IA

Bases de datos: RDS, Aurora y DynamoDB

Amazon Relational Database Service (RDS) ejecuta instancias gestionadas de PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server y Db2. AWS se encarga del aprovisionamiento, de los parches en una ventana de mantenimiento, de las copias de seguridad automáticas con recuperación a un momento dado y, con Multi-AZ activado, de una instancia en espera replicada de forma síncrona en otra zona con failover automático. Las read replicas son copias asíncronas para escalar las lecturas y no sustituyen a Multi-AZ. El esquema, las consultas, los índices y el parameter group siguen siendo cosa tuya.

Amazon Aurora es el motor relacional propio de AWS, compatible a nivel de protocolo con PostgreSQL y MySQL, con el almacenamiento replicado seis veces en tres zonas y un failover que se mide en segundos. Las variantes Aurora Serverless ajustan la capacidad a la carga. Elige Aurora cuando quieras la ergonomía de RDS con mayor disponibilidad y escalado de lecturas y no estés atado a otro motor.

Amazon DynamoDB es una base de datos clave-valor y de documentos totalmente gestionada, con una latencia constante de pocos milisegundos a cualquier escala. Las tablas tienen una clave de partición (y, opcionalmente, una clave de ordenación), y haces consultas por esas claves o mediante índices secundarios que diseñas de antemano. La capacidad es bajo demanda o aprovisionada; no hay servidor, ni parches, ni pool de conexiones que dimensionar. El precio de esa sencillez es que los patrones de acceso deben conocerse y modelarse desde el principio.

Amazon ElastiCache (Redis o Valkey, y Memcached) cubre la caché y el almacenamiento de sesiones; Amazon OpenSearch Service cubre la búsqueda de texto completo y el análisis de logs.

Mensajería e integración

Desacoplar los componentes con colas y eventos es la forma en que las arquitecturas de AWS absorben los picos y aíslan los fallos.

Amazon Simple Queue Service (SQS) es una cola de mensajes. Las colas estándar ofrecen entrega at-least-once con orden best-effort y un throughput casi ilimitado; las colas FIFO garantizan el orden y un procesamiento exactly-once dentro de un message group, con menor throughput. Un consumidor recibe un mensaje, lo procesa y lo elimina; si no lo elimina antes de que venza el visibility timeout, el mensaje vuelve a aparecer y, tras un número configurado de intentos, acaba en una dead-letter queue.

Amazon Simple Notification Service (SNS) es publish/subscribe: un topic reparte un mensaje entre muchos suscriptores —colas SQS, funciones Lambda, endpoints HTTPS, correo electrónico, SMS. El fan-out de SNS a SQS es el patrón estándar cuando varios servicios necesitan el mismo evento.

Amazon EventBridge es un bus de eventos con reglas basadas en el contenido que enrutan eventos de los servicios de AWS, de tus aplicaciones y de partners SaaS hacia destinos, y que además incluye un programador. Sustituye al antiguo CloudWatch Events. Para orquestar workflows de varios pasos con reintentos y ramificaciones, AWS Step Functions proporciona una máquina de estados.

Edge, DNS y observabilidad

Amazon Route 53 es un DNS con health checks y políticas de enrutamiento (ponderado, por latencia, failover, geolocalización) que convierten el DNS en una herramienta para dirigir el tráfico. Amazon CloudFront es la red de distribución de contenidos: cachea en edge locations, termina TLS con certificados de AWS Certificate Manager y se sitúa delante de buckets de S3, load balancers o cualquier origen HTTP. AWS WAF se asocia a CloudFront o a un ALB para filtrar peticiones.

Amazon CloudWatch recoge métricas, logs y alarmas. Cada servicio emite métricas automáticamente; tus aplicaciones envían logs a través del agente de CloudWatch o del runtime de Lambda; las alarmas saltan al superar umbrales y pueden disparar Auto Scaling o notificaciones de SNS. AWS CloudTrail registra cada llamada a la API en la cuenta —quién hizo qué, desde dónde y cuándo— y es tu registro de auditoría; actívalo en todas las regiones y entrégalo en un bucket bien protegido de la cuenta de archivo de logs. AWS X-Ray añade tracing distribuido.

La configuración y los secretos también tienen su sitio: AWS Systems Manager Parameter Store para los valores de configuración y AWS Secrets Manager para las credenciales, con rotación automática. Leerlos al arrancar mediante el rol de la instancia es el sustituto cloud native de los ficheros de propiedades con contraseñas dentro, una práctica que la guía de twelve-factor desarrolla con más detalle.

Juntarlo todo en CloudFormation

AWS CloudFormation describe recursos en plantillas YAML o JSON y los crea, actualiza o elimina como un stack. Es la opción nativa de infraestructura como código; Terraform y el AWS CDK son alternativas habituales, y la guía de infraestructura como código las compara. Un stack mínimo con una cola, su dead-letter queue y un rol que podría asumir un servicio:

AWSTemplateFormatVersion: "2010-09-09"
Description: Invoice processing queue and worker role

Resources:
  InvoiceDlq:
    Type: AWS::SQS::Queue
    Properties:
      MessageRetentionPeriod: 1209600          # 14 days, the maximum

  InvoiceQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 120                    # longer than the worst-case processing time
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt InvoiceDlq.Arn
        maxReceiveCount: 5

  WorkerRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: { Service: ecs-tasks.amazonaws.com }   # only ECS tasks may assume it
            Action: sts:AssumeRole
      Policies:
        - PolicyName: consume-invoices
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action: [sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes]
                Resource: !GetAtt InvoiceQueue.Arn

Outputs:
  QueueUrl:
    Value: !Ref InvoiceQueue

Errores comunes

Claves de acceso en el código o en variables de CI. Usa roles en el cómputo y federación OIDC desde sistemas de CI como GitHub Actions; si una clave tiene que existir, limita mucho su alcance y rótala.

Un solo NAT gateway, en una sola zona. Cuando esa zona cae, todas las subredes privadas pierden el acceso a internet. Despliega uno por zona y enruta cada subred privada a su gateway local.

Usar read replicas como alta disponibilidad. Una réplica es asíncrona y su promoción es manual a menos que la automatices. La funcionalidad de disponibilidad es Multi-AZ; las réplicas sirven para escalar lecturas.

Buckets de S3 públicos por accidente. Mantén activado Block Public Access a nivel de cuenta y sirve el contenido público a través de CloudFront con un origin access control.

Ignorar CloudTrail y las etiquetas de asignación de costes. Sin CloudTrail no puedes responder a «¿quién ha borrado eso?», y sin un esquema de etiquetas service/env/owner coherente no puedes responder a «¿quién está pagando esto?». Ambas cosas son baratas de montar desde el primer día y dolorosas de añadir a posteriori.

Conclusiones clave

• Las cuentas son el límite de seguridad y de facturación; las cargas de trabajo obtienen sus permisos mediante roles IAM con credenciales de corta duración, y las políticas deniegan por defecto.
• Una VPC es tu red privada: las subredes públicas enrutan a un internet gateway, las privadas salen por NAT gateways por zona o por VPC endpoints, y los security groups se referencian entre sí en lugar de usar IP.
• EC2 da control total, ECS/EKS ejecuta contenedores y Lambda ejecuta funciones orientadas a eventos; elige según el control que necesites y el patrón de uso, no por moda.
• EBS es un disco ligado a una zona, EFS un sistema de archivos compartido y S3 el almacén de objetos duradero con versionado, lifecycle rules y Block Public Access.
• RDS y Aurora cubren las necesidades relacionales con failover Multi-AZ; DynamoDB cubre el acceso por clave a cualquier escala cuando los patrones se conocen de antemano.
• SQS, SNS y EventBridge desacoplan componentes; CloudWatch, CloudTrail y X-Ray te dicen qué está pasando; CloudFormation lo hace todo reproducible.