Key takeaways
- Akamai Functions transforms the edge into a smarter front door and full compute layer that acts as the glue uniting security, data, CDNs, and inference on a single network.
- Organizations can easily offload mass redirects, data transformations, and nuanced bot triage from the expensive origin to the edge to eliminate unnecessary infrastructure overhead.
- Relocating these workflows results in massive latency drops, such as 10-millisecond redirect responses, and offloads more than 51% of global web traffic driven by automated bots.
- Companies may adopt a surgical approach by migrating one painful workload at a time using open standards to avoid vendor lock-in.
Most teams know that edge compute is faster, closer, and cheaper than origin. But what’s often missed is that the edge can do more than most people realize. The edge can be a smarter and more connected front door — a full compute layer that connects on the same network to your security stack, your data, your CDN, and your inference. The edge is more than just a place for isolated scripts. It can be the glue that holds your applications together.
In the first two posts of this series, we wrote about how Akamai Functions enables this smarter, more connected front door, and the costs of leaving work at the origin.
In this blog post, we’ll take a practical approach and look at three concrete examples of functionality you can move to the edge today:
Mass redirects
Data transformation
Bot triage
We’ll explore what each looks like at origin, what each looks like running on Akamai Functions, and how the move results in lower latency, egress, infrastructure overhead, engineering time, and costs.
Edge use case: Mass redirects
For our first example, let’s look at mass redirects. It’s a common scenario: Your company just acquired a competitor and now 400,000 URLs need a redirect as soon as possible.
In a typical setup, the redirect logic lives at the origin. Every redirect becomes a round trip to a centralized region where lookups are sent to an external database. Of course, latency compounds.
Teams end up with a significant amount of work: a new database to maintain, a rules engine to update, a full deployment pipeline, and a long list of one-off exceptions from marketing. The incurred cost, hours, and risk are all high.
Moving mass redirects to the edge
What do mass redirects look like using Akamai Functions?
With Akamai Functions, the redirect logic runs right at the front door (Figure 1). For most implementations, the entire redirect map lives in memory at every Akamai Cloud region, creating near-instant responses. In cases of more than 1 million redirects, a dedicated KV store kicks in.
Fig. 1: Moving mass redirects to the edge
In both cases, the request never travels to the origin. And because the function sits on the same network as Akamai's CDN and Akamai Bot Manager, redirects that need to coordinate with other policies don't need to cross a vendor seam to do it.
The results
End-to-end round trips happen in approximately 10 milliseconds.
Updates are deployed in just 90 to 120 seconds, to every Akamai Cloud region, with just a single command.
There is no region-by-region rollout, no infrastructure to provision, and no cluster to keep warm.
Edge use case: Data transformation between services
For our second example, let’s look at another common scenario: Two services need to talk to each other, but their JSON is incompatible.
Maybe it’s a versioned API contract you can’t migrate. Maybe it’s a third-party integration. Or maybe it’s an internal team that hasn’t updated their schema in two years. Whatever the reason, your team needs to transform the payload between the services, in flight, on every request.
In a traditional setup, you deploy a cloud service. This means picking a region, tuning autoscaling rules, owning a deployment pipeline, and running monitoring.
The actual transformation logic is just a few lines of code, but it’s wrapped in layers of expensive and slow infrastructure.
Moving data transformation to the edge
With Akamai Functions, you simply deploy a lightweight function that transforms the data inline and right at the front door (Figure 2). No trip to the origin is needed. And you can write the function in the language your team already uses, such as JavaScript, Python, Rust, Go, and more.
Fig. 2: Moving data transformations to the edge
The results
- Sub-millisecond cold starts
- Enough memory and execution time for real transformation logic, not just lightweight header rewrites
Because Akamai Functions uses open standards, your function isn’t trapped in a specific or proprietary vendor stack. If you ever need to move that function, you can. And if the function needs to call an inference model to translate a field … or a credential vault for an API key … or an edge cache for a recent value, those services run on the same Akamai network as the function.
Edge use case: Customized bot responses at the front door
Finally, let’s look at bots. Akamai’s 2026 State of the Internet (SOTI) Security report, Protecting Publishing: Navigating the AI Bot Era, found that AI bot activity surged by 300% in 2025. Bots now account for 51% of global web traffic, outnumbering humans for the first time.
You need to be responsive to this traffic, but the details are nuanced. Some bots you want — such as search indexers that drive SEO, partner AI agents you’ve authorized, and well-behaved AI crawlers feeding legitimate user queries. Some bots you don’t — such as scrapers harvesting your pricing, competitor surveillance, and low-value automation hitting your forms. And some bots are neutral, such as uptime monitors and archive crawlers.
You can’t block everything: Blocking all bots hurts your SEO and alerts the bad bots to your security policies. You need to triage the bots in flight and then respond in selective ways. And your origin is the wrong (and an expensive) place to do it.
Moving bot triage to the edge
An Akamai Function can respond to this traffic inline at the front door. The function reads the Bot Manager classification (wanted vs. unwanted) and chooses what each segment sees: markdown for indexers, obfuscated content for scrapers, normal HTML for humans.
The decision is made at the edge, and the response is served from the edge. Origin never sees the bot traffic (Figure 3).
Fig. 3: Moving bot triage to the edge
And because Akamai Functions runs on the same network as Bot Manager and the CDN, the function can reach any of them in-line — pulling from Akamai Cloud when core compute is needed, or calling distributed inference to rewrite content for an AI crawler. All without leaving the network.
The results
- You see millisecond execution and minimal user impact. Your origin sees a clean traffic profile.
- You offload more than 51% of origin traffic and become more resilient in a bot storm.
- Chained detection, classification, and response all exist in one in-line workflow, eliminating seam costs.
- Your organization achieves fast and cost-effective bot triage.
Best practices for moving to the edge
These three edge use cases share several best practices that can help you choose what functionality to move to the edge, including:
- Be surgical. You don’t need to rethink your entire stack. Instead, start with one workload that’s causing pain today. Pick a single workload, ship it, then pick the next one. Look for projects with immediate payoff.
- Look for the real, but often invisible, savings. Savings won’t always show on an invoice. Instead, look for savings from infrastructure you never needed, developer time avoided, and incidents that never happened.
- Don’t break your architecture. Edge logic runs alongside your existing origin infrastructure. Don’t start with major redesigns; keep your Kubernetes cluster. The edge just picks up the work it should have been doing all along.
- Don’t accept vendor lock-in. Run on open standards. Don’t trap your code into a specific runtime. You may need to move it one day.
- Use the edge as glue. The biggest gains come from using the edge as the glue. Use Akamai Functions to connect your edge compute, security stack, CDN, cloud, inference, and your origin — all on the same network.
Move to the edge with Akamai Functions
To get started with Akamai’s smarter, more connected edge, determine which of your origin workloads are generating the most traffic, cost, or operational complexity. Common candidates include:
- Redirects
- Auth
- Bot triage
- A/B testing
- Data transformation
- Personalization
- Inference
With Akamai Functions, these functions can be faster, cheaper, and run on the same network as your security stack, CDN, and inference.
How to get started
Ready to see what your front door can do? Start with the Functions Quick Start Guide in TechDocs.
Tags
