AWS Básico — Servicios Core para Desarrolladores

Resumen

Amazon Web Services (AWS) es la plataforma cloud más adoptada, con más de 200 servicios — y ese es exactamente el problema para quien empieza. Nadie necesita los 200. Lo que necesitas es el conjunto de trabajo sobre el que se construye casi cualquier app en producción: cómputo, almacenamiento, una base de datos, un límite de red e identidad. Esta guía cubre ese conjunto — EC2, Lambda, S3, EBS, RDS, DynamoDB, VPC, IAM — con los comandos y los gotchas que encontrarás en tu primer despliegue real, y cómo encajan las piezas en una arquitectura que de verdad lanzarías.

Cuándo Usar

Lee esta guía cuando:

• Estás migrando una carga de trabajo de on-premises a la nube y necesitas el mapa de lo que existe
• Necesitas cómputo preparado para escalar sin gestionar hardware
• Quieres bases de datos y almacenamiento gestionados en lugar de Postgres autoalojada en una VM
• Estás construyendo arquitecturas serverless o de microservicios
• Estás configurando la cuenta AWS de un equipo nuevo y necesitas la línea base segura por defecto

Sáltatela si ya conoces los servicios core y necesitas profundidad en uno — ve directo a la receta o guía específica.

Versiones ejecutables de cada comando y snippet de esta guía (script CLI, handler Lambda, política IAM, ejemplo DynamoDB): recursos companion. Para el equivalente en Azure, consulta Azure Básico — Servicios Core para Desarrolladores; para networking práctico, la receta de Terraform para VPC en AWS construye la capa de red descrita abajo.

Cómputo — EC2 y Lambda

EC2 (Elastic Compute Cloud)

Servidores virtuales en la cloud con control total del SO.

# Lanzar una instancia vía CLI
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --count 1 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-123456 \
  --subnet-id subnet-123456

Familia de Instancia	Caso de Uso
T3/T4g	General purpose, burst (dev/test)
M6i/M6g	General purpose, cargas sostenidas
C6i/C6g	Intensivo en compute (APIs, batch)
R6i/R6g	Intensivo en memoria (caches, analytics)

Elige la familia por el cuello de botella, no por familiaridad con el nombre: T3 hace burst y se estrangula bajo carga sostenida, M es el default seguro, C para trabajo intensivo en CPU, R cuando tu working set no cabe en RAM. Empieza un tamaño por debajo de lo que crees necesitar — redimensionar después es un reinicio; sobredimensionar es una factura.

Lambda

Funciones serverless que ejecutan en respuesta a eventos. Pagas por invocación y duración.

import json

def handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Hello from Lambda'})
    }

Lambda se integra con S3, API Gateway, SQS, SNS, DynamoDB streams y CloudWatch Events.

Dos límites moldean los diseños reales: las funciones se cortan a los 15 minutos por invocación, y un cold start añade desde ~100 ms (Python/Node) hasta varios segundos (JVM) en la primera request tras estar inactiva. Para endpoints de cara al usuario que no toleran cold starts, usa provisioned concurrency — o acepta que Lambda cambia el coste always-on por latencia ocasional.

Almacenamiento — S3 y EBS

S3 (Simple Storage Service)

Almacenamiento de objetos para archivos, backups, assets estáticos y data lakes.

# Crear un bucket
aws s3 mb s3://my-app-bucket

# Subir un archivo
aws s3 cp app.zip s3://my-app-bucket/builds/

# Hacer público (con precaución)
aws s3api put-object-acl --bucket my-app-bucket --key app.zip --acl public-read

Clase de Storage	Caso de Uso	Recuperación
Standard	Acceso frecuente	Inmediata
Intelligent-Tiering	Patrones de acceso desconocidos	Inmediata
Glacier	Archivos a largo plazo	Minutos a horas
Deep Archive	Backups de compliance	12-48 horas

Las clases de almacenamiento son donde se esconde el dinero. Una regla de lifecycle que mueva objetos a Intelligent-Tiering o Glacier tras 30–90 días suele recortar el gasto de S3 más que cualquier otro cambio — y cuesta un JSON de política. Y ojo: no pagas por meter datos en S3, pagas por sacarlos — las lecturas y el egress entre regiones suman más rápido que el propio almacenamiento.

EBS (Elastic Block Store)

Storage de bloque persistente para instancias EC2. Como un disco duro virtual.

# Crear y adjuntar un volumen
aws ec2 create-volume --size 100 --region us-east-1 --availability-zone us-east-1a --volume-type gp3
aws ec2 attach-volume --volume-id vol-12345 --instance-id i-12345 --device /dev/sdf

Usa gp3 para casi todo — es más barato que gp2 y te permite configurar IOPS y throughput independientemente del tamaño. io2 solo merece la pena para bases de datos que de verdad necesiten >16k IOPS.

Bases de Datos — RDS y DynamoDB

RDS (Relational Database Service)

PostgreSQL, MySQL, MariaDB, SQL Server u Oracle gestionados.

# Crear una instancia PostgreSQL
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --master-username admin \
  --manage-master-user-password \  # deja que RDS lo guarde en Secrets Manager — nunca en línea
  --allocated-storage 20

Dos interruptores de producción que conviene conocer antes de lanzar: MultiAZ te da un standby síncrono para failover (cuesta ~2x, lo vale para cualquier cosa que importe), y las read replicas descargan el tráfico de reporting — pero las réplicas son asíncronas, así que las lecturas pueden ir segundos por detrás de las escrituras.

DynamoDB

Base de datos NoSQL gestionada con latencia de milisegundos de un solo dígito.

import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Users')

table.put_item(Item={'id': 'user-1', 'name': 'Alice', 'email': 'alice@example.com'})
response = table.get_item(Key={'id': 'user-1'})

Elige facturación on-demand hasta que tengas meses de datos de tráfico — la capacidad provisionada solo gana cuando tu carga es estable y predecible. Y diseña primero tu partition key: una partición caliente (una clave que absorbe la mayoría de las escrituras) te estrangula por mucha capacidad que compres.

Red — VPC

Virtual Private Cloud aisla tus recursos y controla el tráfico.

┌─────────────────────────────────────────────┐
│                    VPC                        │
│  ┌─────────────┐    ┌─────────────────────┐ │
│  │ Public Subnet│    │   Private Subnet    │ │
│  │  ┌───────┐  │    │  ┌───────┐ ┌─────┐ │ │
│  │  │  ALB  │  │    │  │  EC2  │ │ RDS │ │ │
│  │  └───┬───┘  │    │  └───┬───┘ └──┬──┘ │ │
│  │      │      │    │      │        │    │ │
│  │  Internet    │    │   NAT Gateway      │ │
│  │  Gateway     │    │   (egress only)    │ │
│  └──────────────┘    └────────────────────┘ │
└─────────────────────────────────────────────┘

Componentes clave:

• Subnets: Públicas (con ruta IGW) vs Privadas (sin internet directo)
• Security Groups: Firewall stateful a nivel de instancia
• NACLs: Firewall stateless a nivel de subnet
• NAT Gateway: Permite a instancias privadas alcanzar internet

Vigila el NAT Gateway: es la partida sorpresa clásica (~$0.045/GB procesado además del coste por hora). Si las subnets privadas solo necesitan APIs de AWS, un VPC endpoint a S3 es gratis y evita el salto por el NAT por completo.

Seguridad — IAM

Identity and Access Management controla quién puede hacer qué.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*",
      "Condition": {
        "StringEquals": {"aws:RequestedRegion": "us-east-1"}
      }
    }
  ]
}

El modelo mental: los usuarios son personas, los roles son identidades que los servicios asumen, y las políticas son los documentos JSON que dicen qué está permitido. Tu instancia EC2 debería asumir un rol con solo los permisos de S3 de arriba — si la caja se ve comprometida, el atacante obtiene credenciales temporales que caducan, no una clave de larga vida en un archivo de configuración.

Lo que funciona:

• Usa roles, no access keys de largo plazo
• Aplica least privilege — concede las acciones específicas sobre los recursos específicos y amplía solo cuando algo se rompa
• Habilita MFA para root y usuarios admin
• Usa condiciones de IAM policy (aws:RequestedRegion, aws:SourceIp) como defensa en profundidad

Observabilidad — Fundamentos de CloudWatch

CloudWatch es donde AWS muestra lo que hacen tus recursos, y es la mitad de cada respuesta a “por qué está roto”:

• Métricas automáticas por servicio: CPU en EC2, invocaciones y errores en Lambda, conexiones en RDS. Las métricas custom (profundidad de cola, contadores de negocio) van por la API PutMetricData o el agente CloudWatch en EC2.
• Alarmas convierten métricas en avisos. Dos importan desde el día uno: la alarma de facturación (AWS/Billing, us-east-1) y una alarma de CPU/errores por recurso en producción.
• Logs recogen de Lambda (automático), EC2 (agente) y salida de la app. Configura un período de retención — el default es “guardar para siempre”, que te factura silenciosamente por logs que nadie lee.
• VPC Flow Logs registran el tráfico aceptado/rechazado por interfaz de red. Actívalos al crear la VPC, no cuando ya estés depurando por qué la app no llega a la base de datos.

# Crear una alarma de facturación — lo primero que necesita una cuenta nueva
aws cloudwatch put-metric-alarm \
  --alarm-name billing-alert \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum --period 21600 \
  --threshold 10 --comparison-operator GreaterThanThreshold \
  --dimensions Name=Currency,Value=USD \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:billing-alerts

La alarma debe crearse en us-east-1 sin importar dónde viva tu carga de trabajo — AWS publica las métricas de facturación solo ahí, algo que confunde a todo el mundo la primera vez.

Arquitectura de referencia

Un primer despliegue típico en AWS se ve así:

El tráfico del cliente llega al load balancer en las subnets públicas. El cómputo — EC2 o Lambda — vive en subnets privadas sin exposición directa a internet; sale a través del NAT Gateway cuando lo necesita. La base de datos también está en subnets privadas, y S3 maneja objetos y assets estáticos directamente. IAM lo atraviesa todo, definiendo quién (y qué servicio) puede tocar qué.

Las dos reglas que hacen funcionar esta forma: nada con estado va en una subnet pública, y cada salto entre capas está controlado por security groups — el load balancer acepta tráfico de cualquier origen, las instancias solo aceptan del security group del load balancer, y la base de datos solo acepta de las instancias.

Cómo elegir entre servicios

La pregunta recurrente en AWS rara vez es “¿existe un servicio?” — es cuál de tres que se solapan elegir:

Necesidad	Elige	Evita
App de larga duración con control del SO	EC2	Lambda (trabajos >15 min, con estado)
Glue orientado a eventos, tráfico irregular	Lambda	EC2 (coste ocioso por trabajo ocioso)
Contenedores que gestionas tú	ECS	EKS salvo que necesites APIs de Kubernetes
Datos relacionales, joins, transacciones	RDS	DynamoDB
Clave-valor, datos de sesión, alta escala de escritura	DynamoDB	RDS
Sistema de archivos compartido entre instancias	EFS	EBS (una sola instancia)

Cuando dos servicios se solapan, el desempate es la carga operativa: la opción más gestionada suele ser la correcta para un equipo pequeño, aunque cueste más por unidad. Estás comprando horas de guardia, no cómputo.

EC2 vs Lambda

El razonamiento por defecto: si el trabajo es una request HTTP que termina en segundos, gana Lambda — sin parches, sin coste ocioso, escala a cero. Si es un proceso que mantiene estado (websockets, game servers), corre más de 15 minutos o necesita latencia predecible por request bajo carga, gana EC2 o un contenedor. La variable oculta es el tamaño del equipo: Lambda le traslada la carga operativa a AWS, lo que importa más que el precio bruto cuando tres personas mantienen la plataforma.

RDS vs DynamoDB

Modela primero tus patrones de acceso. Si la app necesita joins, consultas ad-hoc o transacciones entre entidades, es relacional — usa RDS. Si puedes describir las lecturas como “obtener item por clave” o “listar items bajo una partición”, DynamoDB escala más y más barato a alto volumen de escritura. El error a evitar es elegir DynamoDB por comodidad del desarrollador y descubrir seis meses después que tu reporting necesita SQL.

Arquitecturas comunes

Tres formas cubren la mayor parte de lo que un equipo pequeño despliega primero:

Sitio estático / hosting de SPA. Bucket S3 (privado) + distribución CloudFront delante + Route 53 para DNS. Sin servidores: CloudFront sirve desde cachés edge, S3 almacena el build. Es la arquitectura más barata que ofrece AWS — céntimos al mes a pequeña escala — y aquí es donde falla el default de “servir desde S3 directamente”: mantén el bucket privado y deja que CloudFront sea el único lector vía origin access control.

Backend de API clásico. ALB → EC2/ECS en subnets privadas → RDS en dos AZs, con S3 para subidas y ElastiCache si lo necesitas. Es el diagrama de la arquitectura de referencia y cubre el 80% de los backends CRUD. Las piezas que olvidas al principio: una ruta de health-check que no toque la base de datos, y connection draining para que los despliegues no corten requests.

Pipeline orientado a eventos. Subida a S3 → cola SQS → consumidores Lambda → tabla de resultados en DynamoDB, con una dead-letter queue para los fallos. Sin load balancer, sin cómputo always-on — pagas por evento y escala a cero. Es la arquitectura a la que acudir cuando el trabajo es irregular o asíncrono (thumbnails, webhooks, importaciones).

Un patrón que conviene notar: en las tres, la superficie pública es una sola cosa gestionada (CloudFront, ALB o el evento de S3) y todo lo demás vive en privado detrás. Si tu diseño tiene cómputo en una subnet pública “temporalmente”, ese es el bug que arreglar antes del lanzamiento.

Fundamentos de precios

El pricing de AWS muerde en tres sitios que los principiantes subestiman:

El cómputo sigue un menú: on-demand (sin compromiso, tarifa más alta), Savings Plans o Reserved Instances (compromiso de 1–3 años, ~30–60% de descuento) y Spot (hasta ~90% menos, recuperable con dos minutos de aviso). Spot es solo para trabajo sin estado e interrumpible.

El egress es el asesino silencioso: meter datos es gratis, sacarlos a internet cuesta ~$0.09/GB. Servir archivos grandes directamente desde EC2 en lugar de CloudFront, o replicar entre regiones a la ligera, es cómo una app de $200/mes se convierte en $2,000.

El Free Tier es más estrecho de lo que parece: 750 horas/mes de t2/t3.micro durante 12 meses, 5 GB de S3, 1M de requests Lambda — suficiente para aprender, no para producción. Configura una alarma de facturación (métrica AWS/Billing, solo en us-east-1) el primer día, antes de crear cualquier otra cosa.

Lo que funciona

1. Alarma de facturación antes que recursos — una alarma de $10 en la primera semana es más barata que cualquier decisión de arquitectura que tomes después.
2. Roles sobre claves — asigna roles IAM a EC2/Lambda; nunca escribas una access key en disco ni en el entorno.
3. Instancia mínima viable — empieza un tamaño por debajo; CloudWatch te avisará cuando te equivoques.
4. Etiqueta todo al crearlo — las etiquetas Service, Env, Owner son cómo finanzas y la respuesta a incidentes se mantienen cuerdas seis meses después.
5. Una región hasta que necesites dos — multi-región duplica coste y complejidad; gánatelo con requisitos reales, no con miedo.

Errores Comunes

La mayoría de las historias de terror en AWS son autoinfligidas y predecibles — los mismos cinco errores, repetidos en cada cuenta nueva. Dominan los fallos de seguridad (buckets abiertos, claves root), seguidos de las sorpresas de coste (sin alarmas, instancias olvidadas) y el silencio donde deberían estar los logs. Lee esta lista antes de desplegar, no después de que llegue el informe del incidente.

• Dejar buckets S3 públicos — usa bucket policies y Block Public Access
• Usar credenciales root — crea IAM users y roles inmediatamente
• Sin VPC flow logs — no puedes debuggear lo que no puedes ver
• Instancias EC2 sobreprovisionadas — empieza pequeño y escala; usa CloudWatch metrics
• Ignorar alertas de costo — configura billing alarms antes de sorpresas
• Elegir la región equivocada — la residencia de datos y la latencia se deciden al crear la cuenta; moverse de región después significa migrar todo, y algunos servicios (como las métricas de facturación en us-east-1) están anclados a la región de todos modos
• Gestionar infraestructura a mano — cualquier cosa que construyas haciendo clic en la consola tendrás que reconstruirla de memoria; usa Terraform o al menos documenta cada clic

Tu primera semana en AWS

Una ruta de aprendizaje sensata, en orden:

• Día 1–2: asegura la cuenta. MFA en root, un rol de admin IAM (no usuario) para ti, alarma de facturación configurada y una región elegida — la más cercana a tus usuarios.
• Día 3–4: pon un sitio estático en S3 + CloudFront, luego despliega una app pequeña de punta a punta: una instancia EC2 en una subnet privada detrás de un load balancer, hablando con RDS. Ese único ejercicio ejercita VPC, subnets, security groups, IAM y EBS a la vez.
• Día 5: rómpela a propósito — termina la instancia, observa qué reporta el load balancer y reconstúyela desde tus notas. Si no puedes reconstruirla, no la aprendiste.
• Día 6–7: automatiza el mismo despliegue en Terraform y anota lo que te sorprendió en Cost Explorer.

Resiste la tentación de pasear por el catálogo de servicios — aprendes AWS lanzando una cosa pequeña de punta a punta, no leyendo sobre 200 servicios.

Cuando ese primer despliegue esté estable, los siguientes pasos naturales son los que cubren los vecinos de esta guía: codifica toda la arquitectura en Terraform para que sea reproducible y revisable, pon una política de auto-scaling alrededor de la capa de cómputo para que el trabajo del load balancer sobreviva a un pico de tráfico, y lee una guía de FinOps antes de que llegue la primera factura de verdad — AWS premia a los preparados y factura en silencio a todos los demás.

Lectura Adicional

• AWS Well-Architected Framework — los seis pilares
• AWS Documentation — referencias por servicio