{"id":23152,"date":"2026-05-22T10:45:40","date_gmt":"2026-05-22T08:45:40","guid":{"rendered":"https:\/\/www.transparentedge.eu\/en\/blog\/"},"modified":"2026-05-22T12:36:20","modified_gmt":"2026-05-22T10:36:20","slug":"your-cdn-as-an-api-gateway","status":"publish","type":"post","link":"https:\/\/www.transparentedge.eu\/en\/blog\/your-cdn-as-an-api-gateway\/","title":{"rendered":"Your CDN as an API Gateway"},"content":{"rendered":"\n

Microservices, rate limiting, and rewriting at the edge<\/h2>\n\n\n\n

If you manage a microservices architecture, you probably have an API gateway<\/a> sitting in front of them. And, most likely, you also have a CDN in front of that API gateway. Two layers, two deployments, two bills, and\u2014above all\u2014two extra latency hops for every single request. The logical question that any CTO might eventually ask is: Do I really need both?<\/em><\/p>\n\n\n\n

The short answer is easy: yes. But the long answer comes with a surprise. If your CDN runs on VCL (Varnish Configuration Language), you might not need to duplicate your resources. In this post, we explain how the layer you already have in production can act as an API gateway\u2014routing microservices, limiting traffic, rewriting URLs, and applying security policies\u2014without adding a single extra component.<\/p>\n\n\n\n

What is an application gateway and why can your CDN already be one?<\/h2>\n\n\n\n

Traditionally, CDNs are used as intermediary proxies to cache content, accelerate delivery, or add an extra layer of security. However, there are lesser-known use cases that are incredibly valuable in complex architectures. One of them is using a CDN as an application gateway or application-level proxy.<\/p>\n\n\n\n

A next-generation CDN<\/a> acts as a hub for all requests hitting your domain. This means any routing, filtering, service mesh, or validation decisions can be made right at that layer. If you have a language like VCL to define that logic, the possibilities for any DevOps team are massive: SSL offloading, end-to-end SSL, WAF<\/a>, URL-based routing, multiple backends based on arbitrary criteria, A\/B testing<\/a>, canary deployments<\/a>, feature flags via HTTP headers<\/a>, and much more.<\/p>\n\n\n\n

In practice, the CDN stops being just an accelerator and becomes an orchestrator.<\/p>\n\n\n\n

Practical example: a microservices API under a single domain<\/h2>\n\n\n\n

Imagine an API based on microservices distributed across different hosts. With an application gateway, you can expose all services under a single domain\u2014api.mysite.com<\/code>\u2014and internally route each path to its corresponding backend: \/login<\/code>, \/analytics<\/code>, \/cart<\/code>.<\/p>\n\n\n\n

Assuming three backends are already configured in the CDN:<\/p>\n\n\n\n

c0_login $\\rightarrow$ login.mycompany.com:8080\nc0_stats $\\rightarrow$ 11.22.33.44:80\nc0_shopcart $\\rightarrow$ cart.thirdpartyprovider.com:443<\/code><\/pre>\n\n\n\n
The VCL configuration would look like this:<\/p>\n\n\n\n
Fragmento de c\u00f3digo<\/p>\n\n\n\n
sub vcl_recv {\n    if (req.url ~ \"^\/login\") {\n        set req.backend_hint = c0_login.backend();\n    } else if (req.url ~ \"^\/analytics\") {\n        set req.backend_hint = c0_stats.backend();\n    } else if (req.url ~ \"^\/cart\") {\n        set req.backend_hint = c0_shopcart.backend();\n    }\n}\n# To each their own\n<\/code><\/pre>\n\n\n\n
Without touching DNS, without coordinating deployments across teams, and without adding an extra component to the network path, you have unified three services under a single public URL. The end client only sees api.mysite.com<\/code>, while each backend team continues to deploy to their own infrastructure.<\/p>\n\n\n\n
Going further: rate limiting, IP allow-listing, and URL rewriting<\/h2>\n\n\n\n
The previous example is just the foundation. From there, your VCL can grow in complexity to incorporate validations, throttling, redirects, URL rewriting, and more. Let\u2019s look at some common patterns applied to the same scenario:<\/p>\n\n\n\n
Fragmento de c\u00f3digo<\/p>\n\n\n\n
sub vcl_recv {\n    if (req.url ~ \"^\/login\") {\n        set req.backend_hint = c0_login.backend();\n        # Only allow access to these URLs from the office IP\n        if (! req.http.True-Client-Ip == \"12.34.56.78\") {\n            error 403 \"The power of Christ compels you!\";\n        }\n    } else if (req.url ~ \"^\/analytics\") {\n        set req.backend_hint = c0_stats.backend();\n        # There are too many analytics fans; let's rate-limit to 30 req\/s\n        set req.http.x-ratelimit = 30;\n    } else if (req.url ~ \"^\/cart\") {\n        set req.backend_hint = c0_shopcart.backend();\n        # The cart belongs to a third party and has a URL we want to hide\n        set req.url = \"\/third-parties\/aef5677c321bb761c\/\";\n        # A bit of A\/B testing: if the client's IP ends in 0, 1, or 2,\n        # we send a header to the backend to serve version B\n        set req.http.abtesting = 0;\n        if (req.http.True-Client-IP ~ \"[0-2]$\") {\n            set req.http.abtesting = 1;\n        }\n    }\n}\n<\/code><\/pre>\n\n\n\n
What you just read covers, in about twenty lines, features that in a traditional architecture would require:<\/p>\n\n\n\n
    \n
  1. A managed API gateway for routing.<\/li>\n\n\n\n
  2. A separate plugin or service for rate limiting.<\/li>\n\n\n\n
  3. Firewall rules or ACLs for IP allow-listing.<\/li>\n\n\n\n
  4. An additional proxy for third-party URL rewriting.<\/li>\n\n\n\n
  5. A feature flag or split-testing service for A\/B testing.<\/li>\n<\/ol>\n\n\n\n
    All of that is compressed into the exact same layer you are already paying for to serve content.<\/p>\n\n\n\n
    When to (and when not to) use your CDN as an API gateway<\/h2>\n\n\n\n
    Not everything fits this pattern. To make a solid architectural decision, it\u2019s best to understand both sides of the coin:<\/p>\n\n\n\n
    It’s a great fit when:<\/strong><\/p>\n\n\n\n