DevOps desde Cero: AWS desde Cero

Introduccion

Bienvenido al articulo seis de la serie DevOps from Zero to Hero. Ya cubrimos conceptos de DevOps, construimos una API en TypeScript, aprendimos control de versiones, testing automatizado, y configuramos CI/CD. Ahora es momento de hablar de la nube. Vamos a configurar una cuenta de AWS correctamente, configurar IAM con minimo privilegio, instalar el CLI, entender VPC y security groups, y repasar los servicios clave de la serie.

Vamos a meternos de lleno.

Creando tu cuenta de AWS

Anda a aws.amazon.com y hace clic en “Create an AWS Account.” Necesitas email, tarjeta de credito y telefono. AWS no te cobra por crear la cuenta, y muchos servicios tienen free tier por 12 meses. Te dan un usuario root con acceso sin restricciones a todo. Nunca lo uses para el trabajo diario. Lo que tenes que hacer inmediatamente:

• Habilitar MFA en root: Anda a IAM, configura autenticacion multifactor con Google Authenticator o Authy
• Crear un usuario admin de IAM: Lo cubrimos a continuacion. De aca en mas, te logeas con el usuario IAM
• Configurar alarma de facturacion: Crea una alarma en CloudWatch cuando los cargos superen $10
• Guardar credenciales de root: Anotalas en un gestor de contraseñas y deja de usar root

IAM: Identity and Access Management

IAM controla quien puede hacer que en tu cuenta de AWS. Cuatro conceptos principales:

• Users: Personas o aplicaciones individuales, cada una con sus propias credenciales
• Groups: Colecciones de usuarios. Adjuntas permisos al grupo y agregas usuarios
• Roles: Identidades temporales que asumen usuarios, servicios o aplicaciones (ej: una instancia EC2 asumiendo un role para leer de S3)
• Policies: Documentos JSON que definen que acciones estan permitidas o denegadas sobre cuales recursos

El principio de minimo privilegio: dale a cada identidad solo los permisos que necesita. Si se filtran credenciales, el radio de impacto se limita a lo permitido.

Creando un usuario admin de IAM:

1. Anda a la consola de IAM, clic en “Users,” despues “Create user.”
2. Nombrado admin, marca “Provide user access to the AWS Management Console.”
3. Adjunta la policy AdministratorAccess directamente.
4. Guarda la URL de login y credenciales, logueate como este usuario y habilita MFA.

Escribiendo una policy de IAM personalizada:

Aca hay una policy de minimo privilegio que permite subir y descargar de un bucket S3 especifico:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadWrite",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-uploads",
        "arn:aws:s3:::my-app-uploads/*"
      ]
    }
  ]
}

• Version: Siempre "2012-10-17" (version del lenguaje de policies, no una fecha que cambias)
• Effect: "Allow" o "Deny". Deny siempre gana
• Action: Llamadas API especificas permitidas
• Resource: Recursos AWS identificados por ARN. Necesitas el bucket y /* para los objetos

Mejores practicas de IAM:

• Nunca uses root excepto facturacion y emergencias
• Usa grupos para permisos, no policies individuales por usuario
• Usa roles en lugar de access keys para EC2, Lambda y ECS
• Habilita MFA en cada usuario humano
• Rota access keys cada 90 dias

Configuracion del AWS CLI

El AWS CLI te permite interactuar con AWS desde tu terminal. Instalacion:

# Linux
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

# macOS
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
aws --version

Crea un access key en IAM para tu usuario admin, despues configura:

aws configure
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Default region name [None]: us-east-1
# Default output format [None]: json

Perfiles con nombre para multiples cuentas (dev, staging, prod):

aws configure --profile dev
aws configure --profile staging
aws configure --profile prod

# Usar un perfil especifico
aws s3 ls --profile dev

# O configurar via variable de entorno
export AWS_PROFILE=dev
aws sts get-caller-identity

Configura tu default apuntando a dev para nunca ejecutar comandos contra produccion por accidente.

VPC: Virtual Private Cloud

Una VPC es tu propia red aislada dentro de AWS. Cada recurso vive dentro de una VPC. Tenes una VPC default en cada region, pero para produccion crea VPCs personalizadas.

Conceptos clave:

• Bloque CIDR: Rango de IPs de tu VPC (ej: 10.0.0.0/16 = 65,536 IPs). Se elige al crear, no se puede cambiar
• Subnets: Subdivisiones de la VPC, cada una en una zona de disponibilidad especifica
• Zonas de disponibilidad (AZs): Data centers separados fisicamente dentro de una region

Subnets publicas vs privadas:

• Publicas: Ruta a internet via Internet Gateway. Para load balancers y bastion hosts
• Privadas: Sin ruta directa a internet. Para app servers y bases de datos. Salida via NAT gateway

Tablas de ruteo dictan a donde va el trafico. Las subnets publicas rutean 0.0.0.0/0 al Internet Gateway; las privadas al NAT Gateway. VPC tipica de produccion:

                        Region: us-east-1
 ┌──────────────────────────────────────────────────────────┐
 │                    VPC: 10.0.0.0/16                      │
 │                                                          │
 │  ┌─────────────────────┐    ┌─────────────────────┐      │
 │  │   AZ: us-east-1a    │    │   AZ: us-east-1b    │      │
 │  │                     │    │                     │      │
 │  │ ┌─────────────────┐ │    │ ┌─────────────────┐ │      │
 │  │ │ Subnet Publica  │ │    │ │ Subnet Publica  │ │      │
 │  │ │ 10.0.1.0/24     │ │    │ │ 10.0.2.0/24     │ │      │
 │  │ │ [Load Balancer] │ │    │ │ [NAT Gateway]   │ │      │
 │  │ └─────────────────┘ │    │ └─────────────────┘ │      │
 │  │ ┌─────────────────┐ │    │ ┌─────────────────┐ │      │
 │  │ │ Subnet Privada  │ │    │ │ Subnet Privada  │ │      │
 │  │ │ 10.0.3.0/24     │ │    │ │ 10.0.4.0/24     │ │      │
 │  │ │ [App Server]    │ │    │ │ [App Server]    │ │      │
 │  │ │ [Database]      │ │    │ │ [Database]      │ │      │
 │  │ └─────────────────┘ │    │ └─────────────────┘ │      │
 │  └─────────────────────┘    └─────────────────────┘      │
 │                                                          │
 │                    [Internet Gateway]                     │
 └──────────────────────────────────────────────────────────┘
                            │
                        Internet

Alta disponibilidad (dos AZs), seguridad (bases de datos en subnets privadas), y acceso saliente via NAT. Vamos a construir esta VPC con Terraform mas adelante.

Security groups

Security groups son firewalls virtuales para tus recursos. Son stateful (permitir entrada en puerto 80 y la respuesta se permite de salida automaticamente), solo permiten (sin regla que permita = denegado), y a nivel de instancia (se adjuntan a recursos, no subnets).

Ejemplo de security group para web server:

Security Group: web-server-sg

Reglas de Entrada:
  HTTP       TCP  80     0.0.0.0/0       Permitir HTTP
  HTTPS      TCP  443    0.0.0.0/0       Permitir HTTPS
  SSH        TCP  22     203.0.113.50/32 SSH solo desde mi IP

Reglas de Salida:
  Todo       Todo Todo   0.0.0.0/0       Permitir toda salida

Security group de base de datos referenciando el grupo web:

Security Group: database-sg

Reglas de Entrada:
  PostgreSQL TCP  5432   web-server-sg   Solo desde web servers

Reglas de Salida:
  Todo       Todo Todo   0.0.0.0/0       Permitir toda salida

La base de datos referencia web-server-sg como origen. Cualquier instancia con ese grupo puede llegar a la DB, sin trackeo de IPs. Mejores practicas: nunca abras SSH a 0.0.0.0/0, usa referencias a security groups para comunicacion interna, y crea grupos separados por rol.

Resumen de servicios clave de AWS

AWS tiene mas de 200 servicios. Los que vamos a usar en la serie:

• EC2: Servidores virtuales. Elegis OS, CPU, memoria. Pagas por segundo
• S3: Storage de objetos. Para assets, backups, logs, hosting estatico. 99.999999999% durabilidad
• RDS: Bases de datos administradas (PostgreSQL, MySQL, etc.). AWS maneja backups, parches, failover
• ECS: Corre contenedores Docker en EC2 o Fargate (serverless). Maneja scheduling y scaling
• Lambda: Funciones serverless. Pagas solo por tiempo de computo. Ideal para workloads event-driven
• Route 53: Servicio DNS con health checks y politicas de ruteo
• ACM: Certificados SSL/TLS gratuitos. Adjuntar a load balancers o CloudFront
• Secrets Manager: Almacena contraseñas, API keys, tokens con rotacion automatica

Free Tier y como evitar facturas sorpresa

El free tier tiene tres tipos:

• 12 meses gratis: 750 hs/mes EC2 t2/t3.micro, 5GB S3, 750 hs/mes RDS single-AZ
• Siempre gratis: 1M requests Lambda/mes, 25GB DynamoDB, 1M notificaciones SNS
• Pruebas cortas: Trials por servicio (ej: 750 hs Redshift por 2 meses)

Para evitar sorpresas:

• Alarmas de facturacion en CloudWatch y AWS Budgets con alertas al 50%, 80%, 100%
• Revisa facturacion semanalmente mientras aprendes
• Termina recursos sin usar: instancias EC2 detenidas igual generan cargos de EBS
• Ojo con NAT gateways: ~$32/mes incluso sin trafico
• Ojo con transferencia de datos: datos salientes de AWS cuestan plata

Configurar alarma de facturacion con CLI:

# Crear topic SNS
aws sns create-topic --name billing-alerts --profile dev

# Subscribir email
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alerts \
  --protocol email \
  --notification-endpoint [email protected] \
  --profile dev

# Crear alarma CloudWatch para cargos mayores a $10
aws cloudwatch put-metric-alarm \
  --alarm-name "billing-alarm-10-usd" \
  --alarm-description "Alarma cuando cargos superan $10" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 21600 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=Currency,Value=USD \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:billing-alerts \
  --region us-east-1 \
  --profile dev

Las metricas de facturacion solo estan en us-east-1, sin importar donde esten tus recursos.

El AWS Well-Architected Framework

AWS define seis pilares para sistemas bien diseñados:

• Excelencia Operacional: Automatizar operaciones, responder a eventos, definir estandares
• Seguridad: Proteger datos con IAM, encriptacion y controles detectivos
• Confiabilidad: Recuperarse de fallas, cumplir demanda, probar procedimientos de recuperacion
• Eficiencia de Rendimiento: Dimensionar correctamente instancias, monitorear rendimiento
• Optimizacion de Costos: Evitar desperdicio con instancias reservadas/spot y right-sizing
• Sustentabilidad: Minimizar impacto ambiental, optimizar utilizacion

Vamos a aplicar estos principios mientras construimos infraestructura real.

Notas finales

AWS puede sentirse abrumador, pero la mayoria de las apps solo usan un puniado de servicios. Una vez que entendes IAM, VPC y los servicios core de computo y storage, tenes la base para todo. Puntos clave: nunca uses root, siempre aplica minimo privilegio, entende subnets publicas vs privadas, y configura alertas de facturacion antes de olvidarte. En el proximo articulo, vamos a construir infraestructura real con Terraform, definiendo VPCs, subnets, security groups e instancias EC2 como codigo.

Espero que te haya resultado util y lo hayas disfrutado, hasta la proxima!

Errata

Si encontras algun error o tenes alguna sugerencia, por favor mandame un mensaje para que lo corrija.

Tambien, podes revisar el codigo fuente y los cambios en los fuentes aca