Every piece of data that travels takes time. A request that leaves Lima, crosses to a data center in North America, and comes back spends time that no code optimization recovers, because the limit is set by the physics of the link, not by the server. For years that delay was an engineering detail. Today, when a tenth of a second moves the conversion rate of an online store, it is a business matter.
Edge computing is the architectural answer to that problem: bringing part of the processing closer to where data is born or consumed. This guide explains what it covers, when it genuinely pays off, and how it is implemented on AWS, in business language.
What is edge computing?
Edge computing is the model in which part of the processing happens close to the source of the data —the user, the store, the plant, the vehicle— instead of always traveling to a central cloud region.
The key word is part. The edge is not an alternative destination to the cloud: it is an additional layer that solves what is urgent nearby and leaves the heavy work at the center. Anyone who frames it as an either-or ends up with two infrastructures doing the same thing and a duplicated bill.
In practice, the edge takes three distinct forms that are often confused:
- Content points of presence: hundreds of locations that store copies of your content and can run lightweight logic on every request.
- Extensions of the region into metropolitan areas: cloud infrastructure placed inside a city, for workloads that need very low latency for local users.
- Infrastructure on the customer’s premises: when the process or the data has to stay physically where the operation happens.
Why latency stopped being a technical matter
Distance is not negotiable. A round trip between Lima and a data center on the east coast of the United States takes tens of milliseconds at best, and a modern page does not make a single request: it makes dozens. Those dozens add up.
That matters for three concrete business reasons:
- Load speed affects revenue. In e-commerce and in any acquisition funnel, perceived delay is measurable abandonment. It is not an infrastructure metric, it is a commercial one.
- Operations cannot always wait for the link. A store in a remote region, a plant, or a dispatch point does not stop operating because the internet went down. If critical logic lives only at the center, a link outage is a business outage.
- Moving data costs. Sending the full stream from sensors or cameras to the cloud only to discard 95% on arrival means paying transport for information that was never going to be used. Filtering on site and sending what matters changes the equation.
Edge, central cloud, and own premises
| Dimension | Edge computing | Central cloud region | Own servers |
|---|---|---|---|
| Where processing happens | Close to the user or the data | In the chosen region | In the customer’s data center |
| Latency for the local user | Very low | Depends on distance | Very low inside the network |
| What it solves best | Immediate response and local continuity | Volume, history, and analytics | Physical data location requirements |
| Compute capacity | Bounded by design | Practically no ceiling | Limited by what was purchased |
| Consumption model | Pay per use | Pay per use | Investment and hardware refresh |
| Who operates the hardware | The provider | The provider | The internal team |
| Architectural complexity | High if overused | Low | High |
The row worth reading slowly is the last one. The edge adds moving parts: more places where something can fall out of sync, more surface to monitor, more versions to keep aligned. That complexity is worth it when it solves a real problem, and it is pure cost when adopted as a trend.
Three scenarios where the edge does pay off
Content delivery and web experience. This is the most mature case and the fastest to justify. Static content, images, and application files are served from a nearby point, and lightweight logic —redirecting by language, validating a header, normalizing a URL— runs right there without bothering the origin.
Operating with intermittent connectivity. Retail with stores in remote regions, mining, agribusiness, and logistics share the same pattern: operations cannot stop when the link fails. Processing locally and syncing when the connection returns turns a network outage into an inconvenience rather than a shutdown.
Preprocessing before sending to the cloud. Sensors, cameras, and industrial equipment generate a volume that is rarely worth moving in full. Filtering, aggregating, and discarding on site, then sending only what feeds the analysis, reduces traffic and speeds up the response to what is actually urgent.
Edge computing on AWS
AWS addresses the three forms of the edge with distinct services, and confusing them is the most common design mistake:
- Amazon CloudFront is the content delivery network: hundreds of points of presence that serve cached copies close to the user. It is the natural entry point to the edge and already covers most web experience cases. We cover it in detail in Amazon CloudFront.
- CloudFront Functions runs very lightweight JavaScript logic on viewer request and viewer response events, with sub-millisecond start times. It is used to manipulate headers, rewrite URLs, or redirect. It has no network access to other services: that is its design restriction and also the reason for its speed.
- Lambda@Edge runs functions in Node.js or Python and can reach other services over the network. Beyond viewer events, it acts on origin events, which fire only when the content was not in cache. It is the option when the logic needs to look something up before responding.
- AWS Local Zones extend an AWS Region into a metropolitan area for workloads that require single-digit millisecond latency for users in that city. A Local Zone has been available in Lima since January 2023, which changes the calculation for latency-sensitive Peruvian applications.
- AWS Outposts brings AWS infrastructure into the customer’s data center or facility, with the same cloud APIs. This is hybrid cloud territory: it applies when the data or the process must physically remain on premises.
One useful clarification about edge functions: CloudFront Functions is not a stripped-down version of Lambda@Edge, it is a different tool. The first is chosen for speed and volume on every request; the second, for capability and access to other services. Choosing wrong is paid in latency or in the bill, depending on which side the mistake falls.
When the edge is not the answer
It is worth saying just as clearly: most enterprise applications do not need edge computing beyond a good content delivery network.
If your users are concentrated in one city, if your application tolerates a couple of tenths of a second, if your operation does not stop when the link fails, and if the data volume you move is manageable, the central cloud region does the job with fewer parts and lower operating cost. The right answer is often to bring the region closer —choosing well where the workload runs— before building a new layer.
And when the problem really is distance, order matters: first a well-configured CDN, then lightweight logic at the edge, and only then metropolitan or on-site infrastructure. Skipping the first two steps is the most expensive way to solve a cheap problem.
How we approach it at Caleidos
At Caleidos we treat the edge as an architectural decision with a business criterion, not as a layer added by default. We start by measuring where time is actually lost —often it is not distance but the application— and only then define what should move closer and what belongs in the region.
That analysis is part of our work in cloud strategy and application modernization, and it draws on architectures we already run in production, documented in our case studies.
Frequently asked questions
Is edge computing the same as a CDN? No. A CDN is the most common case of the edge, focused on delivering cached content. Edge computing also includes running logic and processing data at that nearby point.
Do I need edge computing if my users are only in Peru? It depends on the latency requirement. For most applications, a well-configured content delivery network solves the problem. The Lima Local Zone helps when the workload demands single-digit milliseconds consistently.
Can you run serverless code at the edge? Yes. Both CloudFront Functions and Lambda@Edge are serverless models: no machines to manage, and you pay per execution.
Is latency costing you conversions?
Let’s talk about your current architecture and we will tell you, with data, whether the problem is distance or something else.
