Región, cantidad de zonas de disponibilidad y camino de salida a internet son tres decisiones de presupuesto con precio de lista publicado. Se toman en la primera hora de un proyecto, cuando todavía no hay tráfico que medir, y después quedan fijas porque moverlas implica reconstruir. La factura las describe dos meses más tarde, con precisión, en un vocabulario que nadie eligió.
Este artículo es el marco para hacer esa cuenta antes: qué comprás cuando comprás capacidad en la nube, qué frontera cruzan tus bytes, y qué parte del sistema sigue siendo tuya después de firmar.
Todos los precios que siguen son de lista, región us-east-1, en dólares y sin impuestos, verificados a la fecha del frontmatter. Varían por región y AWS los mueve. Cuando digo TB me refiero a terabytes decimales: 1 TB son 1.000 GB, que es la unidad en la que factura AWS.
Una jerarquía de fronteras con un medidor en cada cruce
AWS construyó la nube como una jerarquía de fronteras físicas de aislamiento —región, zona de disponibilidad, data center— y puso un medidor de facturación en cada cruce. Esa es la estructura completa. Todo lo demás se deriva.
La frontera de la AZ tiene una geometría concreta y publicada. El whitepaper de fault isolation boundaries define cada zona como uno o más datacenters con energía, refrigeración, red y conectividad redundantes e independientes, separados de las otras zonas por muchos kilómetros pero dentro de unos 100 km. Los dos números están en tensión a propósito. Suficientemente lejos para que un incendio, una inundación o un corte de red no se lleve dos zonas al mismo tiempo. Suficientemente cerca para que la replicación sincrónica siga siendo posible con latencia de un dígito en milisegundos.
De esa tensión sale una consecuencia que después aparece en cada decisión de arquitectura. Multi-AZ es un checkbox en RDS porque la replicación sincrónica cabe adentro de 100 km. Multi-región es un proyecto porque no cabe: a distancias continentales la escritura sincrónica deja de ser viable y hay que elegir consistencia eventual, con todo lo que eso implica en el código de la aplicación.
El precio te dice cuántas fronteras compraste. S3 Standard guarda cada objeto en un mínimo de tres zonas de disponibilidad y cuesta USD 0,023 por GB-mes los primeros 50 TB. S3 One Zone-IA guarda el mismo objeto en una sola zona y cuesta USD 0,01 por GB-mes, con cargo de recuperación por GB y mínimo de 30 días de facturación. La diferencia de durabilidad entre las dos clases no es una promesa de marketing: son dos edificios más, con su propia energía y su propia red.
Cada frontera física que cruza un byte tiene un medidor.
Con eso, la tabla de peajes deja de ser una lista de precios para memorizar y pasa a ser algo que podés derivar. Si el byte no cruza nada, no hay medidor. Si cruza de una zona a otra, hay dos: el emisor y el receptor son recursos distintos y cada uno se mide por separado.
Qué es una región y qué es una AZ
Una región es una frontera de cinco cosas al mismo tiempo, y cada una empuja la decisión para un lado distinto.
Es una frontera de precios: el mismo t3.medium no vale lo mismo en us-east-1 que en sa-east-1. Cualquier número que leas —incluidos los de acá— pertenece a una región específica o no significa nada.
Es una frontera de aislamiento: AWS reportaba 123 zonas de disponibilidad en 39 regiones lanzadas a junio de 2026. Las regiones nuevas se lanzan con al menos tres AZ, aunque en algunas regiones comerciales viejas una cuenta puede ver solo dos zonas utilizables. Ese aislamiento es literalmente el producto.
Es una frontera de catálogo: no todos los servicios existen en todas las regiones, y las novedades suelen aparecer primero en us-east-1.
Es una frontera jurisdiccional: dónde vive el dato define qué ley le aplica.
Y es una frontera de facturación: casi todo lo que cruza el límite de una región se cobra por GB.
Adentro hay una trampa de nomenclatura que importa cuando trabajás con varias cuentas. Para cuentas creadas antes de noviembre de 2025 en las regiones más viejas, el nombre us-east-1a se mapea de forma independiente por cuenta: puede ser un edificio distinto que el us-east-1a de otra cuenta. Las cuentas creadas desde noviembre de 2025 reciben el mismo mapeo. El identificador estable en los dos casos es el AZ ID —use1-az1, use1-az4— que apunta al mismo lugar físico en todas las cuentas.
Si administrás una flota mixta de cuentas viejas y nuevas, la regla operativa es una sola: comparás AZ ID, nunca nombre. Verificalo antes de compartir subnets por Resource Access Manager, antes de colocar dos servicios de cuentas distintas en la misma zona física, y antes de comparar precios spot entre cuentas —donde el nombre de zona en un reporte y el nombre en el otro pueden no ser el mismo edificio.
# Qué AZ ID hay detrás de los nombres que ve esta cuenta
aws ec2 describe-availability-zones \
--region us-east-1 \
--filters Name=zone-type,Values=availability-zone \
--query 'AvailabilityZones[].{Nombre:ZoneName,ID:ZoneId}' \
--output table
Las unidades de la factura
| Qué se mide | Unidad | Referencia us-east-1 | Quién la controla |
|---|---|---|---|
| Cómputo | segundos de instancia, mínimo 60 en Linux | on-demand por hora, prorrateado al segundo | vos, al elegir tamaño y encendido |
| Storage de objetos | GB-mes | S3 Standard, USD 0,023 por GB los primeros 50 TB | vos, al elegir clase y retención |
| Storage de bloque | GB-mes provisionado | EBS gp3, USD 0,08 por GB-mes con 3.000 IOPS y 125 MB/s incluidos | vos, al provisionar |
| Operaciones | por cada 1.000 requests | S3, USD 0,005 por PUT y USD 0,0004 por GET | tu código, no tu consola |
| Transferencia | GB movidos, con precio distinto por frontera | ver el mapa de peajes | tu topología |
Las primeras cuatro son proporcionales a lo que pediste. Elegiste un m6i.large, elegiste guardar 400 GB, elegiste escribir un objeto por evento. Cada una apunta a un recurso concreto en la consola, con un tamaño que alguien tipeó.
La transferencia funciona distinto, y por eso no tiene una sola cifra en esta tabla. Nadie provisiona transferencia de datos: se emite, como calor. Es el subproducto de dónde pusiste cada cosa respecto de cada otra cosa, y es la única línea de la factura que no tiene un recurso propio al cual culpar. Su precio depende enteramente de qué frontera cruza cada byte.
La transferencia de datos es la sombra que proyecta tu topología sobre la factura.
El mapa de peajes
| Recorrido | Precio de lista us-east-1 |
|---|---|
| Entre instancias en la misma AZ, por IP privada | sin cargo |
| Entre AZ de la misma región | USD 0,01 por GB en cada dirección |
| Salida a internet desde EC2, S3, RDS o Lambda | primeros 100 GB del mes sin cargo, después USD 0,09 por GB hasta 10 TB |
| Salida vía CloudFront | primer TB del mes y 10 millones de requests sin cargo, después desde USD 0,085 por GB en Norteamérica y Europa |
| Procesado por NAT gateway | USD 0,045 por hora de existencia más USD 0,045 por GB procesado |
| Gateway endpoint a S3 o DynamoDB | sin cargo |
| Interface endpoint (PrivateLink) | USD 0,01 por hora y por AZ más USD 0,01 por GB |
Tres lecturas de esa tabla cambian decisiones concretas.
El cross-AZ se cobra dos veces. Cuando mandás un gigabyte de una instancia en use1-az1 a otra en use1-az2, el emisor paga egress y el receptor paga ingress. Un gigabyte en una dirección, dos líneas DataTransfer-Regional-Bytes en el Cost and Usage Report, una por extremo, dos centavos. No es un doble cobro: es el modelo midiendo por recurso, y hay dos recursos involucrados. Corey Quinn lo verificó contra una factura real moviendo 10 GB entre zonas y recibiendo un cargo de 20 centavos. La consecuencia práctica es que el ida y vuelta son cuatro centavos, no dos: 1 GB de request más 1 GB de respuesta son 2 GB unidireccionales. Un servicio conversador que mueve 40 TB por mes entre zonas —40.000 GB unidireccionales— son USD 800 mensuales que no figuran en ningún diagrama de cajas.
El NAT gateway cobra por procesar, no por salir. Cobra el byte aunque el destino sea un servicio de AWS en tu misma región. Un cluster de EKS que baja imágenes de ECR a través del NAT paga el procesamiento; el mismo cluster hablando por un VPC endpoint no lo paga. Diez TB mensuales hacia S3 vía NAT —10.000 GB por USD 0,045— son USD 450 al mes que desaparecen con un gateway endpoint, que no cuesta nada. La diferencia entre las dos facturas es una línea de Terraform.
Los 100 GB gratis son por cuenta, no por servicio ni por región. Se agregan en un solo contador entre EC2, S3, RDS, Lambda y todas las regiones, con la excepción de las regiones de China y GovCloud. Un staging que descarga backups se los come antes de que producción arranque.
Dónde está el punto de cruce
Las tablas de precios no deciden nada por sí solas. Lo que decide es el volumen al que dos opciones cuestan lo mismo, y ese número se despeja con una división.
Tomá el caso más frecuente en una VPC privada: llegar a un servicio de AWS por NAT gateway contra llegar por interface endpoint. El NAT ya existe para el resto del tráfico, así que su cargo por hora está pago de todas formas y lo que comparás es el marginal.
| NAT gateway | Interface endpoint en 3 AZ | |
|---|---|---|
| Cargo fijo mensual | USD 0,00 marginal (el NAT ya está) | 3 × USD 0,01/h × 730 h = USD 21,90 |
| Cargo por GB | USD 0,045 | USD 0,01 |
La diferencia por GB es USD 0,035. El punto de cruce es 21,90 / 0,035 = 626 GB por mes hacia ese servicio. Por debajo de unos 630 GB mensuales, el NAT sale más barato y el endpoint es ceremonia. Por encima, el endpoint gana y la ventaja crece linealmente: a 10 TB mensuales, el NAT cobra USD 450 y el endpoint USD 121,90.
Para S3 y DynamoDB no hay punto de cruce. El gateway endpoint no tiene cargo fijo ni cargo por GB: gana siempre, desde el primer byte. Si tu VPC saca tráfico a S3 por NAT, no hay volumen en el que eso sea la opción correcta.
El mismo despeje sirve para el chatter cross-AZ, que es la línea que nadie estima. Una réplica t4g.small on-demand cuesta USD 0,0168 por hora en us-east-1, unos USD 12,26 al mes. A USD 0,02 por GB unidireccional entre zonas, mover 613 GB al mes entre AZ cuesta exactamente lo mismo que tener una réplica chica más prendida las 24 horas. Un servicio que conversa un poco cruza esos 613 GB sin que nadie lo note.
Control plane y data plane no fallan juntos
El plano de control crea y modifica recursos: lanzar una instancia, cambiar una tabla de ruteo, registrar un target, pedir una IP. El plano de datos usa lo que ya existe: el paquete que atraviesa el load balancer, la lectura de S3, la query al RDS. AWS los construye con dependencias separadas a propósito, y en un evento grande el plano de control se degrada primero, porque concentra el trabajo de recuperación de todos los clientes de la región al mismo tiempo.
Eso invalida un runbook común. "Si se cae una AZ, lanzamos instancias en las otras dos" es una recuperación que depende del plano de control justo en el minuto en que el plano de control está saturado. "La capacidad ya está caliente en las tres AZ y sacamos la fallada del target group" depende del plano de datos y de una operación que ya está preprovisionada. AWS le puso nombre al segundo patrón: estabilidad estática.
La lectura económica es directa. La capacidad precalentada en las tres zonas no es sobredimensionamiento; es el precio del failover que no depende del plano de control. Se paga todos los meses en cómputo ocioso y se cobra una sola vez, el día del evento. Si diseñás para tres AZ, la cuenta honesta es 150% de la capacidad pico dividida en tres, no 100% dividida en tres más un plan de escalar cuando arda.
Cuatro decisiones y lo que cuesta cada una
| Decisión | Cuándo sí | Cuándo no | Delta de costo | Qué se rompe |
|---|---|---|---|---|
| Una sola AZ | cargas internas, batch, ambientes de prueba | cualquier cosa con SLA hacia afuera | cero cross-AZ, una sola copia de todo | una zona caída es el servicio caído, y el RTO pasa a ser restaurar un snapshot |
| Multi-AZ activo-activo | producción con costo por minuto caído | servicios donde ese costo es cero | duplica el cómputo mínimo más USD 0,02 por GB de chatter unidireccional | estado en disco local y sesiones sticky; exige capacidad precalentada, no autoscaling reactivo |
| RDS Multi-AZ | la base es el punto único de falla | réplicas descartables o datos reconstruibles | duplica el precio de la instancia y del storage | failover automático de uno a dos minutos, con conexiones cortadas; no salva de un DROP TABLE |
| Multi-región | requisito regulatorio o mercado con latencia crítica | alta disponibilidad genérica | duplica todo más replicación cobrada por GB | consistencia eventual, porque a esa distancia la escritura sincrónica no cierra |
El criterio para decidir es uno solo: cuánto cuesta un minuto caído. Si un minuto de indisponibilidad del reporte interno cuesta cero, una sola zona es la respuesta correcta y el ahorro es real. Si un minuto de la API de pagos cuesta transacciones perdidas, multi-AZ es barato a cualquier precio. Lo que no se defiende es pagar multi-AZ sin haber estimado ninguno de los dos números.
La responsabilidad compartida también reparte la factura
AWS lo formula así: AWS es responsable de la seguridad de la nube, el cliente es responsable de la seguridad en la nube. AWS protege el hardware, el software base, la red física y las instalaciones. Vos te ocupás de lo que pusiste arriba.
El límite se mueve según el servicio. En EC2 te toca el sistema operativo invitado, los parches, la aplicación y las reglas del security group. En servicios abstraídos como S3 o DynamoDB, AWS opera la infraestructura y la plataforma, y a vos te quedan los datos, el cifrado y los permisos de IAM.
La versión económica del mismo principio se enuncia igual de corto: AWS garantiza que el recurso esté disponible, vos sos responsable de que exista.
| Capa | Quién la opera | Quién paga el error |
|---|---|---|
| Datacenter, energía, hipervisor | AWS | AWS |
| Elección de región e instancia | vos | vos, todos los meses |
| Sizing | vos | vos: AWS factura lo que pediste, no lo que usás |
| Ciclo de vida de los recursos | vos | vos, hasta que alguien lo borre |
| Topología de red y egress | vos | vos, por GB |
| Permisos y datos | vos | vos, y ahí el costo no es solo la factura |
La fila de sizing es la que más plata mueve y la que menos se revisa. Un volumen EBS gp3 de 500 GB provisionados con 12 GB efectivamente escritos factura los 500: a USD 0,08 por GB-mes son USD 40 mensuales por 12 GB de datos. El bloque se cobra por lo provisionado, no por lo ocupado, y esa distinción no tiene ninguna señal en la consola hasta que la buscás.
Nada se apaga solo. Un volumen EBS desasociado factura GB-mes. Un snapshot de 2023 factura. Una IP pública IPv4 factura USD 0,005 por hora esté en uso o esté ociosa, unos USD 3,65 al mes cada una. Un NAT gateway olvidado en una VPC de staging factura USD 32,85 al mes por existir, sin procesar un solo byte. El modelo de responsabilidad compartida no tiene cláusula de apagado automático, y no la va a tener: apagarte un recurso es exactamente el tipo de decisión que AWS no puede tomar por vos.
Cuanto más arriba subís en abstracción, menos superficie de operación te queda y más caro es el precio unitario, pero el patrón de facturación cambia de forma: Lambda y Fargate cobran por lo que se ejecuta, no por lo que está encendido. Ese es el intercambio real entre EC2 y serverless.
Hacer la cuenta antes, y leerla al revés después
Agrupá por usage type, no por servicio. Cost Explorer agrupado por servicio dice "EC2: 4.200 dólares", que no es información. Agrupado por usage type separa BoxUsage, DataTransfer-Regional-Bytes, NatGateway-Bytes y EBS:VolumeUsage.gp3. Recién ahí cada línea apunta a una decisión distinta.
aws ce get-cost-and-usage \
--time-period Start=2026-07-01,End=2026-08-01 \
--granularity MONTHLY \
--metrics UnblendedCost \
--group-by Type=DIMENSION,Key=USAGE_TYPE \
--output table
Sin filtro a propósito. La API devuelve los montos como string, así que cualquier comparación numérica en --query de JMESPath resuelve a null y descarta todas las filas sin devolver error: salida vacía, cero pistas. Si querés filtrar del lado del servidor, confirmá primero los valores válidos con aws ce get-dimension-values --dimension USAGE_TYPE_GROUP, o filtrá por USAGE_TYPE con el prefijo DataTransfer y hacé el ordenamiento localmente.
Bajá al recurso. El Cost and Usage Report, hoy dentro de AWS Data Exports, trae detalle por hora y por recurso individual. Es la diferencia entre "el NAT gateway cuesta" y "ese NAT gateway, entre las 02:00 y las 04:00, cuesta".
Poné tags antes de necesitarlos. Las cost allocation tags se activan explícitamente en la consola de facturación y no son retroactivas. Una tag nueva tarda hasta 24 horas en aparecer en la lista de activación y hasta 24 horas más en volverse filtrable en Cost Explorer: entre que la ponés y que sirve pasan hasta dos días. La excepción que conviene conocer antes de resignarse a un mes ciego: la cuenta de administración puede pedir un backfill de cost allocation tags de hasta doce meses hacia atrás.
Movelo hacia la izquierda. Infracost estima el delta de costo de un plan de Terraform y lo comenta en el pull request, cuando el número todavía es una decisión y no un hecho consumado.
Las herramientas
| Herramienta | Para qué | Costo |
|---|---|---|
| AWS Pricing Calculator | comparar dos arquitecturas antes de escribir la primera; obliga a declarar los GB de egress, que es justo la línea que se omite al estimar | sin cargo |
| AWS Cost Explorer | agrupar por usage type y aislar los tipos que terminan en -Bytes para ver cuánto del gasto es transferencia | interfaz sin cargo; las consultas por API se cobran por request |
| Infracost | el delta de costo del plan de Terraform, comentado en el pull request | open source, sin cargo |
| Steampipe (plugin de AWS) | consultar el inventario con SQL: qué instancias en qué AZ, qué subnets rutean por el NAT, qué volúmenes quedaron sin adjuntar | open source, sin cargo |
| AWS CloudShell | un shell con credenciales cargadas dentro de la consola, sin instalar nada | sin cargo dentro de los límites del servicio |
| AWS CLI | comprobar por cuenta propia lo que dice este artículo: ce get-cost-and-usage y ec2 describe-availability-zones | sin cargo |
Falta una en esa lista a propósito. aws-nuke vacía cuentas de sandbox por completo y es absolutamente destructivo: sirve para ambientes efímeros y nunca cerca de producción.
El orden de las palancas
| Palanca | Ahorro sobre on-demand | Qué se rompe |
|---|---|---|
| Apagar lo que no se usa | hasta 100% de ese recurso | nada, si el ambiente es efímero de verdad |
| Rightsizing | proporcional al salto de tamaño: bajar de m6i.2xlarge (USD 0,384/h) a m6i.xlarge (USD 0,192/h) es exactamente 50% del cómputo de esa instancia, USD 140,16 al mes | el margen para picos, si te pasás de ajustado |
| Compute Savings Plans | hasta 66% | compromiso de gasto por 1 o 3 años |
| EC2 Instance Savings Plans y reserved instances | hasta 72% | compromiso atado a familia y región |
| Spot | hasta 90% | la instancia se recupera con dos minutos de aviso |
El orden importa. Las familias de EC2 duplican precio a cada salto de tamaño, así que el rightsizing tiene un techo aritmético conocido de antemano y no hace falta estimarlo: cada escalón que bajás es la mitad. Comprometer tres años de savings plans sobre una flota que nunca pasó por rightsizing es comprarse el sobredimensionamiento a plazo fijo.
Y todos esos descuentos aplican al cómputo. No tocan la transferencia, no tocan el storage, y no arreglan una topología. El gateway endpoint que borra USD 450 mensuales de procesamiento por NAT no aparece en ninguna recomendación de Savings Plans, porque no es un problema de compra.
La factura y la disponibilidad son la misma decisión
Un diseño que sobrevive a la caída de una zona de disponibilidad paga cross-AZ todos los meses. Un diseño que no paga cross-AZ no sobrevive a la caída de una zona. No son dos conversaciones separadas que después hay que reconciliar en una reunión: es la misma frontera física mirada desde sus dos lados, el de la resiliencia y el del medidor.
Eso es lo que comprás cuando comprás nube. No capacidad de cómputo —esa la conseguís en cualquier lado— sino fronteras de aislamiento construidas, mantenidas y tarifadas por otro, con un precio publicado por cada cruce. La factura es la suma literal de esas decisiones, ordenada por el sistema de medición del proveedor. Describe el sistema que tenés, no el que dibujaste.
Elegí sabiendo que estás eligiendo.
Keep going
Reading
- Availability Zones (AWS Fault Isolation Boundaries whitepaper) — define la AZ como uno o más datacenters con energía y red independientes, separados por muchos kilómetros pero dentro de ~100 km: la tensión física de la que se deriva todo el resto del artículo.
- Shared Responsibility Model — la fuente canónica de seguridad de la nube contra seguridad en la nube, y el texto exacto que hay que citar cuando se discute dónde termina AWS y empezás vos.
- How AWS Pricing Works (AWS Whitepaper) — el whitepaper fundacional de qué se factura: cómputo, storage y transferencia como las tres dimensiones de cobro, sin pasar por blogs de terceros.
- Overview of Data Transfer Costs for Common Architectures — el mapa completo de dónde nace un cargo de transferencia: internet gateway contra NAT gateway, cross-AZ, cross-region, peering y Transit Gateway, con diagramas por arquitectura.
- AWS Cross-AZ Data Transfer Costs More Than AWS Says — el experimento con factura real: 10 GB entre AZ costaron 20 centavos y no 10, porque el gigabyte se cobra en las dos puntas.
- Slashing Data Transfer Costs in AWS by 99% — el mismo traslado de ~1 TB entre AZ facturado de dos formas: USD 21,49 directo contra USD 0,08 pasando por S3. La topología como decisión de costos, medida.
Videos
- AWS re:Invent 2020 — Demystifying data transfer on AWS — el único material oficial que trata la transferencia como tema central en vez de nota al pie: servicio por servicio, dónde nace el cargo.
- AWS re:Invent 2025 — Resilience of AWS Cloud: Design patterns for availability (ARC310) — por qué las regiones y las AZ están construidas como están, y qué patrones de disponibilidad habilita esa construcción. Nivel 300.
- AWS re:Invent 2023 — AWS networking foundations (NTA307) — los fundamentos de red que explican por qué cruzar una frontera es lo que dispara el cargo. Sin este modelo, la factura de transferencia parece arbitraria.