Todo dato que viaja tarda. Una solicitud que sale de Lima, cruza hasta un centro de datos en Norteamérica y regresa gasta un tiempo que ninguna optimización de código recupera, porque el límite lo pone la física del enlace, no el servidor. Durante años esa demora fue un detalle de ingeniería. Hoy, cuando una décima de segundo mueve la tasa de conversión de una tienda en línea, es un asunto de negocio.
El edge computing —cómputo en el borde— es la respuesta arquitectónica a ese problema: acercar una parte del procesamiento al lugar donde los datos nacen o se consumen. Esta guía explica qué cubre, cuándo conviene de verdad y cómo se implementa sobre AWS, en lenguaje de negocio.
¿Qué es el edge computing?
El edge computing es el modelo en el que parte del procesamiento ocurre cerca del origen de los datos —el usuario, la tienda, la planta, el vehículo— en lugar de viajar siempre hasta una región de nube central.
La palabra clave es parte. El borde no es un destino alternativo a la nube: es una capa adicional que resuelve lo urgente cerca y deja lo pesado en el centro. Quien lo plantea como una disyuntiva termina con dos infraestructuras que hacen lo mismo y una factura duplicada.
En la práctica, el borde toma tres formas distintas, que se confunden seguido:
- Puntos de presencia de contenido: cientos de ubicaciones que guardan copias de tu contenido y pueden ejecutar lógica ligera sobre cada solicitud.
- Extensiones de la región en áreas metropolitanas: infraestructura de nube instalada dentro de una ciudad, para cargas que necesitan latencia muy baja frente a usuarios locales.
- Infraestructura en las instalaciones del cliente: cuando el proceso o el dato tiene que quedarse físicamente donde ocurre la operación.
Por qué la latencia dejó de ser un asunto técnico
La distancia no se negocia. Un ida y vuelta entre Lima y un centro de datos en la costa este de Estados Unidos toma decenas de milisegundos en el mejor de los casos, y una página moderna no hace una sola solicitud: hace decenas. Esas decenas se suman.
Eso importa por tres razones concretas de negocio:
- La velocidad de carga afecta el ingreso. En comercio electrónico y en cualquier embudo de captación, la demora percibida es abandono medible. No es una métrica de infraestructura, es una métrica comercial.
- La operación no siempre puede esperar al enlace. Una tienda en provincia, una planta o un punto de despacho no dejan de operar porque se cayó internet. Si la lógica crítica vive solo en el centro, la caída del enlace es una caída del negocio.
- Mover datos cuesta. Enviar el flujo completo de sensores o cámaras hacia la nube para descartar el 95% al llegar es pagar transporte por información que nunca se iba a usar. Filtrar en sitio y enviar lo relevante cambia la ecuación.
Borde, nube central e instalaciones propias
| Dimensión | Cómputo en el borde | Región de nube central | Servidores propios |
|---|---|---|---|
| Dónde ocurre el proceso | Cerca del usuario o del dato | En la región elegida | En el centro de datos del cliente |
| Latencia frente al usuario local | Muy baja | Depende de la distancia | Muy baja dentro de la red |
| Qué resuelve mejor | Respuesta inmediata y continuidad local | Volumen, histórico y analítica | Requisitos de ubicación física del dato |
| Capacidad de cómputo | Acotada por diseño | Prácticamente sin techo | Limitada por lo que se compró |
| Modelo de consumo | Por uso | Por uso | Inversión y renovación de hardware |
| Quién opera el hardware | El proveedor | El proveedor | El equipo interno |
| Complejidad de arquitectura | Alta si se abusa | Baja | Alta |
La fila que más conviene leer despacio es la última. El borde agrega piezas móviles: más lugares donde algo puede desincronizarse, más superficie que monitorear, más versiones que mantener alineadas. Es una complejidad que vale la pena cuando resuelve un problema real, y un costo puro cuando se adopta por moda.
Tres escenarios donde el borde sí paga
Entrega de contenido y experiencia web. Es el caso más maduro y el que más rápido se justifica. El contenido estático, las imágenes y los archivos de la aplicación se sirven desde un punto cercano, y la lógica ligera —redirigir por idioma, validar un encabezado, normalizar una URL— se ejecuta ahí mismo sin molestar al origen.
Operación con conectividad intermitente. Retail con locales en provincia, minería, agroindustria y logística comparten el mismo patrón: la operación no puede detenerse cuando el enlace falla. Procesar localmente y sincronizar cuando vuelve la conexión convierte una caída de red en una molestia en lugar de una parada.
Preprocesamiento antes de enviar a la nube. Sensores, cámaras y equipos industriales generan un volumen que casi nunca conviene mover entero. Filtrar, agregar y descartar en sitio, y enviar al centro solo lo que alimenta el análisis, reduce el tráfico y acelera la respuesta a lo que sí es urgente.
El edge computing en AWS
AWS resuelve las tres formas del borde con servicios distintos, y confundirlos es el error más común al diseñar:
- Amazon CloudFront es la red de entrega de contenido: cientos de puntos de presencia que sirven copias en caché cerca del usuario. Es la puerta de entrada natural al borde y ya cubre la mayoría de los casos de experiencia web. Lo explicamos en detalle en Amazon CloudFront.
- CloudFront Functions ejecuta lógica muy ligera en JavaScript sobre los eventos de solicitud y respuesta del visitante, con tiempos de arranque por debajo del milisegundo. Sirve para manipular encabezados, reescribir URLs o redirigir. No tiene acceso a red hacia otros servicios: esa es su restricción de diseño y también la razón de su velocidad.
- Lambda@Edge ejecuta funciones en Node.js o Python y sí puede alcanzar otros servicios por red. Además de los eventos del visitante, actúa sobre los eventos de origen, que solo se disparan cuando el contenido no estaba en caché. Es la opción cuando la lógica necesita consultar algo antes de responder.
- AWS Local Zones extiende una región de AWS a un área metropolitana para cargas que exigen latencia de milisegundos de un dígito frente a usuarios de esa ciudad. Hay una Local Zone disponible en Lima desde enero de 2023, lo que cambia el cálculo para aplicaciones peruanas sensibles a la latencia.
- AWS Outposts lleva infraestructura de AWS al centro de datos o al local del cliente, con las mismas APIs de la nube. Es el terreno de la nube híbrida: aplica cuando el dato o el proceso debe permanecer físicamente en las instalaciones.
Una aclaración útil sobre las funciones de borde: CloudFront Functions no es una versión reducida de Lambda@Edge, es otra herramienta. La primera se elige por velocidad y volumen sobre cada solicitud; la segunda, por capacidad y acceso a otros servicios. Elegir mal se paga en latencia o en factura, según el lado del error.
Cuándo el borde no es la respuesta
Vale la pena decirlo con la misma claridad: la mayoría de las aplicaciones empresariales no necesitan cómputo en el borde más allá de una buena red de entrega de contenido.
Si tus usuarios están concentrados en una ciudad, si tu aplicación tolera bien un par de décimas de segundo, si tu operación no se detiene cuando falla el enlace y si el volumen de datos que mueves es manejable, la región de nube central hace el trabajo con menos piezas y menos costo de operación. La respuesta correcta muchas veces es acercar la región —elegir bien dónde se ejecuta la carga— antes que construir una capa nueva.
Y cuando el problema sí es de distancia, el orden importa: primero una CDN bien configurada, después lógica ligera en el borde, y solo entonces infraestructura metropolitana o en sitio. Saltarse los dos primeros pasos es la forma más cara de resolver un problema barato.
Cómo lo abordamos en Caleidos
En Caleidos tratamos el borde como una decisión de arquitectura con criterio de negocio, no como una capa que se agrega por defecto. Empezamos midiendo dónde se pierde realmente el tiempo —muchas veces no es la distancia sino la aplicación— y recién después definimos qué corresponde acercar y qué conviene dejar en la región.
Ese análisis forma parte de nuestro trabajo de estrategia cloud y de modernización de aplicaciones, y se apoya en arquitecturas que ya operamos en producción, documentadas en nuestros casos de éxito.
Preguntas frecuentes
¿El edge computing es lo mismo que una CDN? No. Una CDN es el caso más común del borde, centrado en entregar contenido cacheado. El edge computing incluye además ejecutar lógica y procesar datos en ese punto cercano.
¿Necesito edge computing si mis usuarios están solo en Perú? Depende de la exigencia de latencia. Para la mayoría de aplicaciones, una red de entrega de contenido bien configurada resuelve el problema. La Local Zone de Lima aporta cuando la carga exige milisegundos de un dígito de forma sostenida.
¿Se puede ejecutar código sin servidor en el borde? Sí. Tanto CloudFront Functions como Lambda@Edge son modelos sin servidor: no se administran máquinas y se paga por ejecución.
¿La latencia te está costando conversiones?
Conversemos sobre tu arquitectura actual y te decimos con datos si el problema está en la distancia o en otra parte.
