Edge computing 5G con AWS Wavelength - Diseño de aplicaciones de ultra baja latencia

Explicamos la ejecución de aplicaciones en el edge 5G con Wavelength, el diseño de Wavelength Zones y los casos de uso.

Unos 8 min de lecturaÚltima actualización: 2026-10-29

Descripción general de Wavelength

Wavelength es un servicio que coloca recursos de cómputo de AWS dentro de las redes 5G de los principales operadores de telecomunicaciones como Verizon, KDDI y Vodafone. El tráfico desde dispositivos 5G se procesa dentro de la red del operador sin pasar por Internet, logrando latencias de un solo milisegundo. Es adecuado para aplicaciones que requieren ultra baja latencia como AR/VR, streaming de juegos e inferencia en tiempo real.

Wavelength Zones y arquitectura

Las Wavelength Zones son infraestructura AWS instalada dentro de los centros de datos de los operadores de telecomunicaciones, logrando latencias de 10 milisegundos o menos (normalmente 2-5 milisegundos), y permiten utilizar EC2, EBS y subredes VPC. Se agregan subredes de Wavelength Zone a una VPC existente, conectando los recursos del edge 5G con los recursos de la región (RDS, S3) dentro de la VPC. La arquitectura general procesa las solicitudes de dispositivos 5G en EC2 de la Wavelength Zone y persiste los datos en DynamoDB o S3 de la región. En Japón, las Wavelength Zones de Tokio y Osaka están disponibles en la red 5G de KDDI.

Patrones de diseño de aplicaciones

El patrón básico es una arquitectura dividida donde se colocan los procesos sensibles a la latencia (inferencia en tiempo real, servidores de juegos, procesamiento de video) en la Wavelength Zone, y los almacenes de datos backend y funciones de gestión en la región padre. Las instancias EC2 en la Wavelength Zone se comunican con dispositivos 5G a través del carrier gateway y acceden a los servicios de la región padre mediante enrutamiento dentro de la VPC. Se pueden colocar tareas/Pods de ECS o EKS en subredes de la Wavelength Zone para operar aplicaciones edge basadas en contenedores. Auto Scaling responde a las fluctuaciones del tráfico 5G ajustando automáticamente la capacidad en picos. Para inferencia en el edge, se despliegan modelos de SageMaker en EC2 para procesar solicitudes de inferencia de dispositivos 5G en milisegundos.

Precios y restricciones de Wavelength

Las instancias EC2 en Wavelength Zones tienen la misma estructura de precios que la región padre, pero los tipos de instancia disponibles son limitados. La transferencia de datos a través del carrier gateway está sujeta a las tarifas de transferencia de datos del operador de telecomunicaciones, que difieren de las tarifas de transferencia de datos hacia Internet de la región. La transferencia de datos entre la Wavelength Zone y la región padre tiene el mismo precio que la transferencia entre AZs (aproximadamente 0.01 USD/GB) (a fecha de agosto de 2026). Los operadores y ubicaciones disponibles son limitados, por lo que es necesario verificar previamente la distribución geográfica de los usuarios objetivo y la cobertura del operador. Los servicios AWS disponibles en Wavelength Zones están limitados a EC2, EBS, VPC, ECS, EKS, IAM, CloudWatch, entre otros, y se utilizan RDS y S3 de la región padre.

Casos de uso en los que importa la ultra baja latencia

Wavelength es un mecanismo que coloca entornos de AWS dentro de la red del operador de telecomunicaciones para que los dispositivos móviles puedan llegar a ellos con un retardo muy corto. Esta característica se aprovecha en usos en los que incluso un pequeño retardo perjudica la experiencia. Son ejemplos representativos las aplicaciones inmersivas como AR y VR, los juegos competitivos, el procesamiento que analiza video en tiempo real, el control de la conducción autónoma y de los vehículos conectados, y el IoT que supervisa y controla en tiempo real los equipos de las fábricas. En estos casos, si los datos tienen que ir y volver hasta un centro de datos lejano, no se pueden cumplir los requisitos. Al procesar cerca del dispositivo, se pueden hacer realidad aplicaciones que requieren una respuesta inmediata.

Diseño de la arquitectura

En un diseño que utiliza Wavelength, lo esencial es separar qué se procesa en el edge cercano a los dispositivos y qué se procesa en una región normal. El reparto básico de funciones consiste en colocar en el edge el procesamiento inmediato que requiere baja latencia, y poner en el lado de la región la acumulación de datos a gran escala, el análisis por lotes y las funciones de gestión. Conecte el edge y la región a través de la red y agregue los resultados procesados en el edge. En lugar de colocarlo todo en el edge, seleccione cuidadosamente y coloque solo las partes sensibles a la latencia; así podrá aprovechar bien los recursos limitados del edge. La clave es un diseño que descomponga la aplicación según los requisitos de latencia y coloque cada parte en el lugar adecuado.

Comparación con otras opciones de edge

AWS ofrece varias opciones para procesar en el edge; elija entre ellas según los requisitos. Wavelength está especializado en la ultra baja latencia desde las redes móviles. Si busca un rendimiento cercano al de una región en un área metropolitana concreta, Local Zones es adecuado. Si desea colocar un entorno de AWS en sus propias instalaciones, Outposts es una opción. Si solo quiere acelerar la entrega de contenido estático, CloudFront es suficiente. El medio óptimo cambia según si la ultra baja latencia para dispositivos móviles es imprescindible, si el objetivo es la proximidad geográfica o si la instalación on-premises es un requisito. Es importante elegir después de aclarar qué desea resolver.

Restricciones y precauciones de operación

Como Wavelength es un entorno especial, es necesario comprender varias restricciones al utilizarlo. Dado que los servicios de AWS disponibles en el edge son más limitados que en una región normal, construya el procesamiento que coloca en el edge con las funciones mínimas necesarias. Como el alcance disponible depende de las redes y las áreas de los operadores de telecomunicaciones compatibles, compruebe que la ubicación de los usuarios objetivo coincide con el área de servicio. Como los recursos del edge tienen límites físicos, gestione la capacidad de forma planificada. Diseñar una configuración realista que combine el edge y la región partiendo de estas restricciones es el punto clave para aprovechar Wavelength.

Resumen

El criterio para decidir la adopción de Wavelength es si los requisitos de latencia de la aplicación son de 10 milisegundos o menos. Si se puede tolerar una latencia de 20-50 milisegundos en la región normal, el costo y la complejidad operativa de Wavelength no se justifican. En caso de adoptarlo, se recomienda una arquitectura dividida que coloque solo los procesos sensibles a la latencia en el edge y realice la persistencia y el análisis de datos en la región. Dado que los operadores y las regiones compatibles son limitados, verifique previamente las ubicaciones disponibles.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Construcción de service mesh con AWS App Mesh - Control de comunicación entre microservicios y observabilidadPresentamos cómo configurar de forma declarativa despliegues canary con sidecar Envoy, políticas de reintento y cifrado mTLS, y cómo visualizar las dependencias entre servicios con la integración de X-Ray (AWS dejó de dar soporte a App Mesh el 30 de septiembre de 2026).Descubrimiento de servicios con AWS Cloud Map - Resolución dinámica de nombres para microserviciosDescubra dinámicamente endpoints de microservicios usando enfoques basados en DNS y API. Aprenda cómo automatizar el registro y desregistro de servicios mediante integración con ECS y EKS.Cómo funciona la selección de PoP de CloudFront - El enrutamiento DNS y la jerarquía de cachéExplicamos el mecanismo de enrutamiento basado en DNS con el que CloudFront dirige las solicitudes de los usuarios al PoP más cercano, la estructura de caché de varias capas formada por las ubicaciones de borde y las cachés de borde regionales, y los factores de diseño que determinan la tasa de aciertos de caché.Diseño de conexión dedicada - Conexión de red privada estable con Direct ConnectSe explican los métodos de diseño de conexiones de línea dedicada con AWS Direct Connect y se presenta cómo lograr una conexión de red privada estable mediante la elección entre conexión dedicada y conexión hospedada, la configuración redundante y la integración con VPC.Conexión dedicada con AWS Direct Connect - Configuración redundante y control de tráficoDiseñe configuraciones redundantes de conexión dedicada y conéctese a VPCs de múltiples regiones con Direct Connect Gateway. También presentamos la agregación de ancho de banda con LAG y el cifrado MACsec.Gestión y diseño de Elastic IP - Uso de IP estáticas y optimización de costosExplicamos la asignación de Elastic IP, la asociación con EC2, el impacto en costos de EIP no utilizadas y la consideración de alternativas.Por qué ELB se divide en 4 tipos - Detrás de las decisiones de diseño de ALB / NLB / GWLB / CLBSe explica por qué los 4 tipos de balanceadores de carga, ALB, NLB, GWLB y CLB (Classic), coexisten sin unificarse, a partir de las capas del modelo de referencia OSI, las características de rendimiento y la evolución histórica.Optimización de red global con AWS Global Accelerator - Entrega de baja latencia y failoverAprende a enrutar tráfico hacia la red global de AWS usando IPs Anycast, diseñar grupos de endpoints y lograr failover mediante health checks.