Estrategias y Mejores Prácticas 12 min de lectura

Cómo Reducir los Costos de Transferencia de Datos en AWS: Guía Completa 2026

Los costos de transferencia de datos son el tercer gasto más alto en AWS y el más incomprendido. Guía 2026 con siete estrategias para reducir egreso, NAT Gateway, IPv4 e inter-AZ entre 60% y 85% usando Terraform.

Editorial Team

Si alguna vez has abierto la factura de AWS a fin de mes y te has encontrado con una línea misteriosa llamada "Data Transfer" que parece haber crecido sin control, no estás solo. Los costos de transferencia de datos son el tercer gasto más alto en la factura típica de AWS —después del cómputo y el almacenamiento— y, honestamente, los más incomprendidos de los tres. Mover datos hacia AWS es casi siempre gratis, pero sacarlos (o moverlos entre zonas, o pasarlos por un NAT Gateway) puede sumar miles de dólares al mes sin que nadie en el equipo se entere hasta que el CFO pregunta.

En 2026, con precios de egreso que siguen anclados en $0.09/GB y cargos ocultos por NAT Gateway, IPv4 públicas y replicación cruzada, entender dónde se fuga el dinero es la diferencia entre una factura sana y un ticket de emergencia un viernes por la noche. Lo digo por experiencia: la primera vez que vi una factura con $14k en NAT processing pensé que había un error en la consola.

Esta guía cubre las siete estrategias más efectivas para reducir los costos de transferencia de datos en AWS en 2026, con números reales, ejemplos de Terraform listos para copiar, y un mapa claro de cuándo aplicar cada técnica. Vamos al grano.

Precios de transferencia de datos en AWS: referencia 2026

Antes de optimizar hay que entender contra qué estamos peleando. Estos son los precios vigentes en us-east-1 en abril de 2026 (otras regiones varían, pero las proporciones se mantienen):

  • Internet (salida): $0.09/GB los primeros 10 TB/mes; baja progresivamente hasta $0.05/GB sobre 150 TB.
  • Entre regiones: $0.02/GB típicamente, aunque varía por par de regiones.
  • Entre zonas de disponibilidad (AZ): $0.01/GB en cada dirección. Sí, en cada dirección.
  • NAT Gateway: $0.045/hora + $0.045/GB procesado, sumado al egreso a internet.
  • IPv4 pública: $0.005/hora por dirección asignada (este cargo nuevo entró en vigor en febrero de 2024).
  • CloudFront → internet: $0.085/GB los primeros 10 TB. Sí, más barato que EC2 directo.
  • S3 → CloudFront: gratuito.
  • VPC Gateway Endpoint (S3, DynamoDB): $0/hora, $0/GB. Lo más cercano a un almuerzo gratis en AWS.
  • VPC Interface Endpoint (PrivateLink): $0.01/hora + $0.01/GB.

El cálculo que más sorprende a la gente: un solo gigabyte que sale de una subred privada, pasa por NAT Gateway y termina en internet cuesta $0.045 (procesamiento) + $0.09 (egreso) = $0.135/GB. Eso es triple de lo que sugiere la línea de "data processing" cuando la miras aislada. Multiplica por terabytes y entiendes por qué este es el rincón más rentable para optimizar.

Estrategia 1: VPC Gateway Endpoints para S3 y DynamoDB

Si tus instancias EC2 o tus pods de EKS descargan imágenes de contenedor desde ECR, leen datasets de S3 o consultan DynamoDB, todo ese tráfico pasa por el NAT Gateway por defecto. Y eso, como acabamos de ver, no es barato.

Los Gateway Endpoints para S3 y DynamoDB son gratuitos —repito: gratis— y enrutan el tráfico por la red troncal privada de AWS, evitando completamente el cargo de $0.045/GB del NAT. Para una cuenta que envía 5 TB/mes a S3, el ahorro directo es de ~$225/mes por cuenta sin tocar una línea del código de aplicación. En organizaciones con docenas de cuentas (cada vez más común con Control Tower), la cifra se multiplica rápidamente.

Implementación con Terraform

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id

  policy = jsonencode({
    Statement = [{
      Effect    = "Allow"
      Principal = "*"
      Action    = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
      Resource  = ["arn:aws:s3:::${var.data_bucket}",
                   "arn:aws:s3:::${var.data_bucket}/*"]
    }]
  })

  tags = { Name = "s3-gateway-endpoint", CostCenter = "platform" }
}

resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Asegúrate de que las tablas de ruteo de tus subredes privadas estén asociadas al endpoint —es el error número uno cuando algo "no funciona". Si usas EKS con IRSA y acceso a S3, este es, sin discusión, el primer cambio que deberías hacer hoy mismo.

Estrategia 2: VPC Interface Endpoints (PrivateLink) para servicios regionales

Aquí está la parte aburrida: los Gateway Endpoints solo existen para S3 y DynamoDB. Para todo lo demás —ECR, CloudWatch Logs, SQS, SNS, Secrets Manager, STS, SSM— necesitas Interface Endpoints basados en PrivateLink. Y estos sí cuestan: $0.01/hora por endpoint y por AZ, más $0.01/GB procesado.

La economía cambia frente al NAT Gateway. Los Interface Endpoints son más baratos cuando el tráfico de ese servicio supera ~160 GB/mes. Por debajo de ese umbral, el cargo por hora se come el ahorro por GB. Un cluster de EKS que descarga imágenes de ECR constantemente cruza ese umbral el primer día —de hecho, suele cruzarlo en las primeras horas.

locals {
  interface_services = [
    "ecr.api", "ecr.dkr", "logs", "sts",
    "secretsmanager", "ssm", "ssmmessages",
    "ec2messages", "sqs", "monitoring"
  ]
}

resource "aws_vpc_endpoint" "interface" {
  for_each = toset(local.interface_services)

  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.${each.key}"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.endpoints.id]
  private_dns_enabled = true

  tags = { Name = "endpoint-${each.key}" }
}

resource "aws_security_group" "endpoints" {
  name   = "vpc-endpoints"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }
}

El truco está en private_dns_enabled = true: con esa línea, el SDK y la AWS CLI resuelven automáticamente el nombre del servicio hacia el endpoint, sin cambios de configuración en tus aplicaciones. Magia transparente.

Estrategia 3: Usar CloudFront como frontend de S3 y ALB

Para cualquier aplicación que sirva contenido a internet —APIs públicas, sitios web, assets estáticos, vídeo bajo demanda—, poner CloudFront delante reduce el egreso entre un 50% y un 70%, según los datos agregados de proveedores como Cloudflare. ¿La razón? El caché en puntos de presencia evita que la mayoría de las requests llegue al origen.

La economía es doble: por un lado, las respuestas servidas desde caché no consumen egreso del origen (cero). Por otro, el egreso de CloudFront cuesta $0.085/GB frente a los $0.09/GB de EC2, con tarifas decrecientes más agresivas a partir de 10 TB. No es la diferencia más espectacular del mundo, pero sumada al ahorro por caché, los números salen rotundos.

Y aquí va la guinda: el tráfico S3 → CloudFront es gratuito. Migrar un bucket público a CloudFront con OAC (Origin Access Control) reduce a cero el egreso directo de S3. Lo cual es tan bueno como suena.

resource "aws_cloudfront_distribution" "site" {
  enabled             = true
  is_ipv6_enabled     = true
  price_class         = "PriceClass_100"  # US/EU solamente, mas barato

  origin {
    domain_name              = aws_s3_bucket.site.bucket_regional_domain_name
    origin_id                = "s3-origin"
    origin_access_control_id = aws_cloudfront_origin_access_control.oac.id
  }

  default_cache_behavior {
    target_origin_id       = "s3-origin"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    compress               = true  # Brotli + Gzip automatico
    cache_policy_id        = "658327ea-f89d-4fab-a63d-7e88639e58f6"
  }

  restrictions {
    geo_restriction { restriction_type = "none" }
  }

  viewer_certificate { cloudfront_default_certificate = true }
}

Una nota sobre PriceClass_100: limita la distribución a edges en Norteamérica y Europa. Para la mayoría de aplicaciones B2B (que es donde suele estar tu audiencia si lees este artículo), es más que suficiente, y resulta entre un 40% y un 60% más barato que la clase global. Si tu producto se usa en Asia o LatAm, sube a PriceClass_200.

Estrategia 4: Co-localizar cómputo y almacenamiento en la misma AZ

El cargo de $0.01/GB por dirección entre AZ parece trivial hasta que ves arquitecturas de microservicios con cientos de llamadas por segundo convertirlo en miles de dólares al mes. Un stack típico —un servicio en us-east-1a consultando una base de datos RDS en us-east-1b— paga ese peaje en cada query. Cada. Una.

Algunas buenas prácticas que han demostrado funcionar:

  • Configura topology-aware routing en Kubernetes (service.kubernetes.io/topology-mode: Auto) para que los pods prefieran endpoints en la misma AZ.
  • Usa RDS Multi-AZ cluster con lectores en cada zona y conecta cada consumidor al endpoint de su zona local.
  • Para Kafka/MSK, habilita rack-aware consumers (client.rack=use1-az1) para evitar fetch entre zonas, que es el silent killer del presupuesto en pipelines de eventos.
  • Comunica servicios internos por IP privada, nunca por IP pública o DNS público. Una instancia que llama a otra de la misma VPC por IP pública paga tarifa de internet —duele, pero pasa más de lo que admite la gente.

Estrategia 5: Comprimir respuestas HTTP

Esta estrategia es tan sencilla que casi me da pena incluirla, pero la cantidad de APIs que sirven JSON sin comprimir en producción me obliga a mencionarla. Comprimir con Brotli (nivel 4–6) o Gzip reduce el volumen transferido entre un 60% y un 80% para JSON, HTML y JavaScript. Es literalmente una línea de configuración: compress = true en CloudFront, o un par de directivas en nginx/ALB. El cliente decodifica todo automáticamente gracias al header Accept-Encoding.

# nginx.conf — compresion on-the-fly
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types
  application/json
  application/javascript
  text/css
  text/plain
  text/xml
  application/xml+rss
  image/svg+xml;

# Brotli (requiere modulo ngx_brotli)
brotli on;
brotli_comp_level 5;
brotli_types application/json application/javascript text/css;

Si tu API devuelve respuestas JSON grandes sin compresión, el ahorro al activar Brotli es típicamente un factor 4× en bytes transferidos. Y eso se traduce, casi linealmente, en ahorro de egreso. Cuesta cinco minutos de configuración. No hay excusa.

Estrategia 6: Reducir direcciones IPv4 públicas

Desde febrero de 2024 AWS cobra $0.005/hora (~$3.60/mes) por cada IPv4 pública asignada. Suena a poco —y por dirección, lo es— pero acumulado, no. Cuentas con cientos de EIPs asignadas a NAT Gateways obsoletos, NLBs de entornos de staging que nadie apagó nunca, o EC2s zombi acumulan cientos de dólares al mes en cargos completamente invisibles. Es el gasto silencioso por excelencia.

Limpieza rápida con AWS CLI:

# Listar EIPs no asociadas
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

# Liberar una EIP huerfana
aws ec2 release-address --allocation-id eipalloc-0abc123def456

# Identificar interfaces con IP publica auto-asignada
aws ec2 describe-network-interfaces \
  --filters "Name=association.public-ip,Values=*" \
  --query 'NetworkInterfaces[].[NetworkInterfaceId,PrivateIpAddress,Association.PublicIp,Description]' \
  --output table

Para tráfico saliente desde subredes privadas, considera IPv6 (gratis para egreso) o un egress-only internet gateway, que no requiere IPv4 pública en absoluto. Es la dirección hacia la que va el mundo, así que mejor ir adoptándola pronto.

Estrategia 7: S3 Select y filtrado en el origen

Descargar un CSV de 5 GB para filtrar 200 MB de filas relevantes paga egreso por los 5 GB completos. Es el equivalente cloud a pedir delivery de toda la pizzería para sacar dos rebanadas. S3 Select ejecuta la cláusula WHERE directamente en S3 y devuelve solo las filas que coinciden, típicamente entre un 80% y un 95% menos de bytes.

import boto3

s3 = boto3.client("s3")

resp = s3.select_object_content(
    Bucket="analytics-raw",
    Key="events/2026/04/22/events.csv.gz",
    ExpressionType="SQL",
    Expression="SELECT s.user_id, s.event_type FROM S3Object s "
               "WHERE s.region = 'eu-west-1' AND s.amount > 100",
    InputSerialization={
        "CSV": {"FileHeaderInfo": "USE"},
        "CompressionType": "GZIP",
    },
    OutputSerialization={"JSON": {}},
)

for event in resp["Payload"]:
    if "Records" in event:
        payload = event["Records"]["Payload"].decode("utf-8")
        process(payload)

Para datasets que se consultan con frecuencia, convertir a Parquet (columnar, comprimido) reduce aún más los bytes leídos cuando lo combinas con S3 Select o Athena. Es uno de esos cambios que parecen pequeños hasta que ves la factura del mes siguiente.

Monitoreo: encontrar de dónde viene el tráfico

Una verdad incómoda: no puedes optimizar lo que no mides. Activa VPC Flow Logs hacia CloudWatch Logs o S3 y analiza qué ENIs están generando más bytes salientes. Sin esto, optimizar es disparar a ciegas.

resource "aws_flow_log" "vpc" {
  vpc_id               = aws_vpc.main.id
  traffic_type         = "ALL"
  log_destination      = aws_s3_bucket.flow_logs.arn
  log_destination_type = "s3"
}

Después, una consulta rápida con Athena para identificar a los mayores consumidores de egreso:

SELECT
  instance_id,
  pkt_dstaddr,
  SUM(bytes) / 1024 / 1024 / 1024 AS gb_transferred,
  SUM(bytes) * 0.09 / 1024 / 1024 / 1024 AS estimated_usd
FROM vpc_flow_logs
WHERE flow_direction = 'egress'
  AND traffic_path = 8
  AND date = '2026-04-21'
GROUP BY instance_id, pkt_dstaddr
ORDER BY gb_transferred DESC
LIMIT 20;

Complementa esto con Cost Explorer, agrupando por Usage Type y filtrando por dimensiones que contengan DataTransfer, Bytes o NatGateway. Entre los Flow Logs y Cost Explorer suele aparecer, en cuestión de minutos, el culpable que llevaba meses comiéndose el presupuesto.

Plan de 30 días para reducir egreso en 50%+

Si me preguntaras por dónde empezar mañana mismo, este es el plan que recomiendo casi sin pensarlo:

  1. Día 1–3: Habilita VPC Flow Logs y Cost Explorer con granularidad diaria. Identifica los top 10 flujos de egreso. Sin esto, lo demás es marketing.
  2. Día 4–7: Crea Gateway Endpoints para S3 y DynamoDB en todas las VPCs. Ahorro inmediato del 30–45% del tráfico de NAT.
  3. Día 8–14: Añade Interface Endpoints para ECR, CloudWatch Logs, STS y Secrets Manager si superas 160 GB/mes por servicio.
  4. Día 15–20: Pon CloudFront delante de cualquier bucket S3 público o ALB que sirva a internet. Habilita compresión —no se te olvide.
  5. Día 21–25: Audita IPv4 públicas sin usar, EIPs huérfanas y replicación S3 cross-region sin justificación clara.
  6. Día 26–30: Configura topology-aware routing en Kubernetes y revisa que RDS y MSK estén usando lectores por AZ.

Preguntas frecuentes

¿Cuánto cuesta transferir datos entre regiones de AWS?

La transferencia entre regiones cuesta típicamente $0.02/GB, aunque el precio varía según el par de regiones. Por ejemplo, us-east-1 → eu-west-1 son $0.02/GB. Siempre es más caro que el tráfico intra-región y, eso sí, más barato que el egreso a internet. Si replicas buckets S3 entre regiones, esos bytes pagan tanto la tarifa de replicación como la de egreso inter-región, así que vale la pena revisar si realmente necesitas replicación cross-region o si basta con versionado y backup en la misma región (a menudo basta).

¿Los VPC Endpoints eliminan todos los costos del NAT Gateway?

No, solo el tráfico hacia los servicios cubiertos por los endpoints. El NAT Gateway sigue siendo necesario para tráfico a internet general: APIs de terceros, GitHub, npm, pip, Docker Hub y compañía. La estrategia correcta es reducir el tráfico del NAT, no eliminarlo, y mantener un NAT Gateway por AZ para alta disponibilidad. En la práctica, los endpoints bien aplicados bajan el procesamiento del NAT entre un 50% y un 70%, lo cual ya es muchísimo.

¿CloudFront siempre es más barato que servir directo desde S3 o EC2?

Casi siempre, sí, al menos para tráfico público. CloudFront cobra $0.085/GB frente a los $0.09/GB de EC2, y la mayor parte del tráfico real se sirve desde caché a costo cero de origen. La excepción son aplicaciones con muy baja tasa de hits de caché (contenido 100% dinámico y único por usuario), donde el ahorro puede ser marginal o nulo. Para tráfico interno entre servicios, CloudFront no tiene sentido —usa endpoints privados.

¿Cómo identifico qué servicio está gastando más en transferencia de datos?

Combina tres herramientas: (1) Cost Explorer filtrado por Usage Type Group: EC2: Data Transfer agrupado por recurso; (2) VPC Flow Logs analizados con Athena para ver los ENIs con más bytes egress; y (3) métricas de CloudWatch para NAT Gateway (BytesOutToDestination) por gateway. Si tienes etiquetas de asignación de costos consistentes —y si no las tienes, ese es tu próximo proyecto—, puedes atribuir el gasto a equipos o productos directamente.

¿Vale la pena migrar a IPv6 solo por ahorrar costos de IPv4 pública?

Depende del volumen. A $0.005/hora (~$3.60/mes) por dirección, el ahorro por IP individual es modesto. Pero en flotas grandes con cientos o miles de EIPs, la cuenta se vuelve significativa. Más importante todavía: IPv6 es gratuito para egreso en VPC con egress-only internet gateway, así que cualquier arquitectura cloud-native nueva debería diseñarse dual-stack o IPv6-only desde el inicio. El futuro ya llegó.

Conclusión

Los costos de transferencia de datos son invisibles hasta el momento en que decides iluminarlos. Y cuando lo haces, la combinación de Gateway Endpoints gratuitos para S3 y DynamoDB, Interface Endpoints para servicios de alto volumen, CloudFront con compresión delante del tráfico público, co-localización en AZ y limpieza de IPv4 huérfanas puede reducir fácilmente la factura de egreso entre un 60% y un 85%. Sin tocar una sola línea de código de aplicación.

El objetivo no es cero egreso —eso es imposible para cualquier servicio real— sino egreso bien dimensionado: pagar por los bytes que entregan valor al negocio, no por los que se escapan por misconfiguraciones que llevan meses ahí sin que nadie las haya mirado. La buena noticia es que el primer 50% del ahorro suele estar al alcance de una tarde bien invertida.

Sobre el Autor Editorial Team

Our team of expert writers and editors.

Artículos Relacionados