You push your service to production, traffic spikes, and suddenly every millisecond of latency becomes a negotiation with physics. At that moment, edge computing stops being a buzzword and becomes survival. Fastly Compute@Edge and Kuma together are how teams stay fast, flexible, and sane under those conditions.
Fastly Compute@Edge lets you run secure, low-latency code closer to users, not buried in some central region. It executes logic at the edge to shape responses, enforce policies, and handle requests before they ever hit your infrastructure. Kuma, from Kong, provides service mesh capabilities: policy enforcement, observability, and zero-trust networking for microservices. Combined, Fastly Compute@Edge Kuma reduces complexity while tightening control across thousands of distributed APIs.
When joined, Fastly handles traffic at the perimeter and Kuma manages it within the cluster. Requests land at Fastly’s edge, where functions inspect headers or authenticate tokens. Verified requests pass through to services inside the mesh, where Kuma applies layer‑7 routing, mTLS, and traffic policies. You get dynamic, per‑request logic at the edge, and consistent security once inside.
A common workflow looks like this. An incoming API request first hits Fastly Compute@Edge for validation and rate limiting. Fastly then forwards sanitized traffic to an ingress routed by Kuma, where destination policies and service discovery take over. Fastly’s edge logs feed metrics directly into whatever observability stack Kuma uses through tags or Dataplane tokens. The result is shared confidence that every byte passing through is accounted for, authorized, and fast.
For best results, map your RBAC policy between the identity provider and Kuma’s dataplanes. Use OIDC to federate access from providers like Okta or AWS Cognito so there is one source of truth for identity everywhere. Rotate signing keys regularly and treat Fastly dictionaries as configuration, not secret stores. The idea is to keep identity dynamic but trust predictable.