--- title: "Edge Functions Explained: Serverless Code at the CDN Edge" description: What edge functions are, how serverless code runs at CDN points of presence, common use cases, limits, and when edge compute beats the origin. image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-02-25-17-4088-AM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [📘 Learn ▾](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [📖 Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [🎬 Video & Streaming ▾](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [🔴 Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [📺 VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [🎞️ Encoding & Players](https://blog.blazingcdn.com/encoding-players?hsLang=en-us) [🎧 Audio & Podcasts](https://blog.blazingcdn.com/audio-podcasts?hsLang=en-us) [💰 Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [🏗️ Infrastructure ▾](https://blog.blazingcdn.com/cdn-infrastructure?hsLang=en-us) [🗄️ Storage & Origin](https://blog.blazingcdn.com/storage-origin?hsLang=en-us) [📦 Large File Delivery](https://blog.blazingcdn.com/large-file-delivery?hsLang=en-us) [💸 Cloud Costs & Egress](https://blog.blazingcdn.com/cloud-costs-egress?hsLang=en-us) [🌐 Networking & ISP](https://blog.blazingcdn.com/networking-isp?hsLang=en-us) [⚙️ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [⚡ Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [🏭 Industries ▾](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [📺 Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [💾 Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [📣 AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [🎮 Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [📱 Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [🤖 AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [🏛️ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [📚 E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [🏟️ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [💰 Pricing & Compare ▾](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [⚡ Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [📊 Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [🔒 Security ▾](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [🛠️ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [DevOps & Cloud Infra](https://blog.blazingcdn.com/en-us/tag/devops-cloud-infra) [Infrastructure](https://blog.blazingcdn.com/en-us/tag/infrastructure) # Edge Functions Explained: Serverless Code at the CDN Edge Vadym Borovskyi Nov 1, 2026, 3:27:44 AM ![\Edge Functions Explained: Serverless Code at the CDN Edge\](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-02-25-17-4088-AM.jpeg) Edge functions are short-lived programs a CDN executes at its points of presence on matching requests, usually in 1 to 50 ms of CPU time, so redirects, auth checks and A/B bucketing finish near the user instead of after a long-haul trip to the origin. The trade is hard limits on CPU, memory and code size, plus a per-invocation bill that keeps running on cache hits. Edge functions on Amazon CloudFront come in two tiers: CloudFront Functions cap code at 10 KB and memory at 2 MB, while Lambda@Edge viewer triggers allow up to 5 seconds of execution. Cloudflare Workers paid plans default to 30 seconds of CPU time per request. All three figures are from vendor documentation as of 2025. This article covers where these runtimes sit in the request path, a use-case table, the limits that bite in production, a cost model at 1 billion requests a month, an edge vs origin decision matrix, and the failure modes to look for after you ship. ## **How edge functions run inside a CDN point of presence** An edge function is code deployed globally and bound to a route or event: the viewer request, the cache lookup, the origin fetch, or the response. The PoP that terminates TLS for the user runs the code, which can rewrite the request, answer directly, or fetch from cache or origin and then modify the response. ### Isolates vs containers: why cold starts differ Two runtime models dominate. Isolate-based platforms such as Cloudflare Workers run many tenants inside one V8 process, with per-isolate overhead of a few MB and vendor-published startup times under 5 ms. Fastly Compute instantiates WebAssembly modules and publishes startup figures in the microsecond range. Container or microVM models such as Lambda@Edge boot a full language runtime, and cold starts typically land between 100 ms and more than 1 second depending on runtime and package size (estimate). The practical consequence: isolate cold starts disappear into TLS handshake time, while container cold starts show up as p99 spikes on low-traffic PoPs. ### Where in the request path the function fires This is the detail most teams get wrong. A Cloudflare Worker runs in front of the cache, so it executes on every request, hit or miss. On Amazon CloudFront, viewer-request and viewer-response triggers run on every request, but origin-request and origin-response triggers run only on cache misses. Placing logic on the miss path can cut invocations by the inverse of your hit ratio. ## **What is serverless edge, and how does it differ from regional serverless?** Serverless edge means deploying functions to every CDN location instead of one cloud region, with no servers, capacity planning or region choice exposed to the developer. Regional serverless runs closer to your database with generous limits; serverless edge runs closer to the user with tight CPU and memory budgets and no shared local state. That makes the two complementary rather than competing. Regional functions own business logic that needs data. Edge functions own decisions that can be made from the request alone: headers, cookies, geolocation, a signed token, or a small replicated key-value lookup. ## **CDN edge functions use cases: redirects, A/B tests, auth and personalization** | Use case | Trigger point | Typical CPU cost | Main risk | | --- | --- | --- | --- | | Redirects and URL rewrites (vanity paths, locale routing) | Viewer request | Under 1 ms | Redirect tables outgrowing code size limits | | A/B test bucketing | Viewer request, sets cookie | Under 1 ms | Cache key split per variant halves hit ratio per object | | Auth: JWT or signed token validation | Viewer request | About 1 ms for one signature check (estimate) | Key rotation lagging across PoPs | | Personalization (geo pricing, banners) | Response, fragment assembly | 2 to 20 ms with HTML parsing | Personalized output cached for the wrong user | Request-only decisions (redirects, bucketing, token checks) are the cheapest and safest edge workloads; personalization carries the highest correctness risk. By industry, the same primitives recur: - **Streaming and media:** token-gated manifests, geo rights enforcement, ad decision routing. - **SaaS and APIs:** JWT validation, rate limiting, regional access rules, header normalization. - **E-commerce:** geo pricing, bot screening hints, experiment bucketing on cacheable pages. - **Gaming:** region-aware matchmaking endpoints, build channel routing for patches. - **IoT:** payload validation and filtering before telemetry reaches a regional ingest tier. ## **What limits do edge computing functions have?** Edge computing functions are bounded by CPU time per request, memory per instance, compressed code size, and subrequest counts. As documented in 2025, CloudFront Functions allow 10 KB of code with no network access, Lambda@Edge viewer triggers allow 5 seconds and 128 MB, and Cloudflare Workers paid plans default to 30 seconds of CPU. | Runtime (2025 documentation) | Execution limit | Memory | Network calls | | --- | --- | --- | --- | | CloudFront Functions | Sub-millisecond compute budget | 2 MB | None | | Lambda@Edge viewer triggers | 5 s | 128 MB | Yes | | Lambda@Edge origin triggers | 30 s | Up to 10,240 MB | Yes | | Cloudflare Workers (paid) | 30 s CPU default, configurable higher | 128 MB | Yes, with subrequest caps | The limit that matters most is not wall-clock time but whether the runtime can make network calls at all, because that decides whether a function can depend on anything beyond the request. ## **Edge vs origin: a decision guide** Run logic at the edge when the decision needs only the request plus small, slowly changing data, finishes in under about 10 ms of CPU, and saves a long-haul round trip. Keep it at the origin when it needs strongly consistent data, heavy CPU, or writes. The matrix below turns that into checks. | Property of the logic | Place it | Why | | --- | --- | --- | | Decision from headers, cookie, geo or signed token | Edge, viewer request | Keeps cache hits as hits | | Only needed when the object is not cached | Edge, origin-request path | Invocations scale with misses, not traffic | | Reads a central database on every call | Origin | The edge adds a hop and saves nothing | | CPU above roughly 50 ms or large dependencies | Origin or regional serverless | Hits limits and per-ms billing | | Writes, counters, strong consistency | Origin, or a vendor coordination primitive | Per-PoP memory is not shared state | If a function cannot answer without calling home, it belongs at home. The latency arithmetic shows why. Assume a user 150 ms RTT from the origin and 20 ms from the nearest PoP (estimate). An auth check done at the origin turns every protected, otherwise cacheable response into a 150 ms-plus round trip. The same check at the edge keeps it near 20 ms plus about 1 ms of CPU, roughly a 7x reduction in time to first byte for that request class. ## **Benefits and trade-offs of edge functions at scale** The benefits are measurable: lower time to first byte for request-only decisions, origin offload when unauthorized or redirected traffic never leaves the PoP, and automatic scaling with no regional capacity to manage. The trade-offs are distributed debugging, vendor-specific APIs that raise switching cost, an extra security surface for secrets, and usage billing that grows with request count rather than bytes. ### What it costs to run code on every request A worked model at 1 billion requests a month, using published prices as of 2025 (our estimate; verify current rates): - **CloudFront Functions** at $0.10 per million invocations: 1,000 x $0.10 = $100. - **Lambda@Edge** at $0.60 per million plus $0.00005001 per GB-second, 5 ms at 128 MB: $600 in requests plus 625,000 GB-seconds, about $31, for roughly $631. - **Cloudflare Workers Standard**: $5 base including 10 million requests, then 990 x $0.30 = $297, plus 2 ms average CPU: 1,970 million billable CPU ms x $0.02 per million, about $39, for roughly $341. Now move a Lambda@Edge function from viewer request to origin request on a property with a 95% hit ratio. Invocations drop to 50 million and the request charge falls from $600 to $30. Trigger placement often outweighs runtime choice. ## **Edge function failure modes: what breaks and how to confirm it** - **CPU or memory limit exceeded.** Shows up as sporadic 5xx responses on specific inputs, such as large cookies or long redirect lists; Cloudflare surfaces error 1102. Confirm by correlating errors with request size and the CPU-time histogram, not the mean. - **Cold starts on long-tail PoPs.** p99 TTFB spikes only in low-traffic regions after deploys. Confirm by splitting latency by PoP and by first invocation per instance. - **Cache key fragmentation.** Hit ratio falls after launching an A/B test or personalization. Confirm by counting unique cache keys per URL and checking which cookies or headers entered the key or Vary. - **Personalized content cached publicly.** Users see another user's banner or currency. Confirm by checking Cache-Control on personalized responses and whether the function strips private values before storage. - **Hidden origin fan-out.** Origin requests per second rise after a deploy because the function issues subrequests. Confirm by comparing origin RPS against edge request count before and after. - **Per-instance state treated as global.** In-memory rate limiters let through far more than the limit because each isolate counts alone. Confirm by load testing from several regions at once. - **Scattered logs.** Lambda@Edge writes logs in the region nearest the executing location, so incidents look silent in your home region. Confirm by querying every region or centralizing logs. ## **Implementation best practices for edge functions** 1. Start with a request-only, reversible use case: a redirect map or header normalization. 2. Pick the narrowest trigger: miss path before viewer path, specific routes before catch-all. 3. Keep functions stateless, dependency-light and under a few ms of CPU at p99. 4. Validate inputs, scope secrets per function, and version keys so rotation tolerates propagation lag. 5. Roll out by percentage with a kill switch that bypasses the function entirely. 6. Track before and after: TTFB by region, cache hit ratio, origin RPS, error rate, invocation cost. ## **FAQ: edge functions in production** ### Do CDN edge functions run on every request, including cache hits? It depends on the trigger. Cloudflare Workers run in front of the cache, so they execute on hits and misses. On Amazon CloudFront, viewer triggers run on every request while origin triggers run only on cache misses. Choosing the miss path for logic that only matters on misses can cut invocation counts by the inverse of the hit ratio. ### How long can an edge function run before it is terminated? Limits vary by platform. As documented in 2025, Lambda@Edge viewer triggers allow 5 seconds and origin triggers 30 seconds, Cloudflare Workers paid plans default to 30 seconds of CPU time, and CloudFront Functions get a sub-millisecond budget. Design for single-digit milliseconds regardless, because per-request CPU is billed and it adds directly to time to first byte. ### Can edge functions connect to a database? Most edge functions can make outbound network calls, but CloudFront Functions cannot. Calling a central database from the edge usually erases the latency benefit, since the function still waits on a long-haul round trip. Prefer replicated key-value stores for read-mostly data, and keep writes and strongly consistent reads at the origin or in regional serverless. ### Are edge functions cheaper than running the same logic at the origin? Sometimes. Edge functions bill per invocation, so at 1 billion requests a month a single function costs roughly $100 to $630 depending on the platform, using 2025 published prices. They save money when they block, redirect or answer requests that would otherwise reach paid origin compute, and cost more when they wrap cacheable traffic that needs no logic. ### How do you debug edge functions across many PoPs? Emit structured logs with PoP identifier, cache status, CPU time and function version on every invocation, then centralize them. Lambda@Edge writes logs in the region nearest the executing location, so query all regions. Reproduce failures by replaying captured requests with identical headers and cookies, since most edge bugs depend on specific request inputs. ## **Profile your edge function invocations before adding more** This week, tag every edge function invocation with route, cache status and CPU time, then compute three numbers: the share of invocations landing on cache hits, p99 CPU per route, and monthly invocation cost. Any route where most invocations hit cache and the function makes no decision is a candidate to unbind, and any route over 10 ms of p99 CPU is a candidate to move to the origin path. Those three numbers usually reveal that most bytes are static objects no function needs to touch. For those static bytes, BlazingCDN can run beside your existing edge platform as a second CDN behind DNS with a weighted traffic split, priced from $5 per TB down to $2.50 per TB at volume with no request fees, as of November 2026 (current rates on the BlazingCDN pricing page). The [**BlazingCDN features for static delivery offload**](https://blazingcdn.com/features/) list what every plan includes. Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions) [𝕏](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions&text=) [✉](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3EEdge%20Functions%20Explained:%20Serverless%20Code%20at%20the%20CDN%20Edge%3C/span%3E&body=https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic 100 TB a month at list price - BlazingCDN**$415** - [bunny.net](https://bunny.net/pricing/) Volume**$500** - [CDN77](https://www.cdn77.com/pricing), plan to 250 TB**$990** - [KeyCDN](https://www.keycdn.com/pricing), NA and Europe**$2,600** - [CloudFront](https://aws.amazon.com/cloudfront/pricing/pay-as-you-go/) pay as you go**$6,965** Each provider's published list price for transfer, lowest first, checked November 2026. BlazingCDN publishes this blog. Up to 50 TB a month a flat plan such as CloudFront Pro ($15) can cost less. [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![What Is a Load Balancer? Types and How It Works](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-03-2026-09-25-38-3387-PM.jpeg)](https://blog.blazingcdn.com/en-us/what-is-a-load-balancer-types-and-how-it-works?hsLang=en-us) DevOps & Cloud Infra ### [What Is a Load Balancer? Types and How It Works](https://blog.blazingcdn.com/en-us/what-is-a-load-balancer-types-and-how-it-works?hsLang=en-us) The short answer to what is a load balancer: it is a network component that distributes incoming connections or ... Nov 3, 2026, 10:27:18 PM [Read more](https://blog.blazingcdn.com/en-us/what-is-a-load-balancer-types-and-how-it-works?hsLang=en-us) [![503 Service Unavailable: What It Means and How to Fix It](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-10-01-57-8244-AM.jpeg)](https://blog.blazingcdn.com/en-us/503-service-unavailable-what-it-means-and-how-to-fix-it?hsLang=en-us) DevOps & Cloud Infra ### [503 Service Unavailable: What It Means and How to Fix It](https://blog.blazingcdn.com/en-us/503-service-unavailable-what-it-means-and-how-to-fix-it?hsLang=en-us) HTTP 503 Service Unavailable means the server, or a proxy in front of it, is temporarily refusing requests because it ... Nov 2, 2026, 11:03:58 AM [Read more](https://blog.blazingcdn.com/en-us/503-service-unavailable-what-it-means-and-how-to-fix-it?hsLang=en-us) [![504 Gateway Timeout: Causes and Fixes Behind a CDN](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-07-55-36-2777-AM.jpeg)](https://blog.blazingcdn.com/en-us/504-gateway-timeout-causes-and-fixes-behind-a-cdn?hsLang=en-us) DevOps & Cloud Infra ### [504 Gateway Timeout: Causes and Fixes Behind a CDN](https://blog.blazingcdn.com/en-us/504-gateway-timeout-causes-and-fixes-behind-a-cdn?hsLang=en-us) A 504 Gateway Timeout behind a CDN means one proxy in the chain (the CDN edge, an origin shield, a load balancer or a ... Nov 2, 2026, 8:58:02 AM [Read more](https://blog.blazingcdn.com/en-us/504-gateway-timeout-causes-and-fixes-behind-a-cdn?hsLang=en-us) [![502 Bad Gateway: What It Means and How to Fix It](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-05-50-36-4647-AM.jpeg)](https://blog.blazingcdn.com/en-us/502-bad-gateway-what-it-means-and-how-to-fix-it?hsLang=en-us) DevOps & Cloud Infra ### [502 Bad Gateway: What It Means and How to Fix It](https://blog.blazingcdn.com/en-us/502-bad-gateway-what-it-means-and-how-to-fix-it?hsLang=en-us) A 502 Bad Gateway means a proxy in your request path, such as nginx, a load balancer or a CDN edge, reached the next ... Nov 2, 2026, 6:52:50 AM [Read more](https://blog.blazingcdn.com/en-us/502-bad-gateway-what-it-means-and-how-to-fix-it?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [📘 Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [📊 Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [🎬 Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [🏭 Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [💰 Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [⚡ Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [🔒 Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [🛠️ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [✍️ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f 𝕏 ✉ Copyright © BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-11-09T14:54:20Z", "datePublished" : "2026-11-01T02:27:44Z", "description" : "What edge functions are, how serverless code runs at CDN points of presence, common use cases, limits, and when edge compute beats the origin.", "headline" : "Edge Functions Explained: Serverless Code at the CDN Edge", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-01-2026-02-25-17-4088-AM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 2146 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions", "name" : "Edge Functions Explained: Serverless Code at the CDN Edge", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/edge-cdn-integration-with-serverless-functions#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "It depends on the trigger. Cloudflare Workers run in front of the cache, so they execute on hits and misses. On Amazon CloudFront, viewer triggers run on every request while origin triggers run only on cache misses. Choosing the miss path for logic that only matters on misses can cut invocation counts by the inverse of the hit ratio." }, "name" : "Do CDN edge functions run on every request, including cache hits?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Limits vary by platform. As documented in 2025, Lambda@Edge viewer triggers allow 5 seconds and origin triggers 30 seconds, Cloudflare Workers paid plans default to 30 seconds of CPU time, and CloudFront Functions get a sub-millisecond budget. Design for single-digit milliseconds regardless, because per-request CPU is billed and it adds directly to time to first byte." }, "name" : "How long can an edge function run before it is terminated?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Most edge functions can make outbound network calls, but CloudFront Functions cannot. Calling a central database from the edge usually erases the latency benefit, since the function still waits on a long-haul round trip. Prefer replicated key-value stores for read-mostly data, and keep writes and strongly consistent reads at the origin or in regional serverless." }, "name" : "Can edge functions connect to a database?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Sometimes. Edge functions bill per invocation, so at 1 billion requests a month a single function costs roughly $100 to $630 depending on the platform, using 2025 published prices. They save money when they block, redirect or answer requests that would otherwise reach paid origin compute, and cost more when they wrap cacheable traffic that needs no logic." }, "name" : "Are edge functions cheaper than running the same logic at the origin?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Emit structured logs with PoP identifier, cache status, CPU time and function version on every invocation, then centralize them. Lambda@Edge writes logs in the region nearest the executing location, so query all regions. Reproduce failures by replaying captured requests with identical headers and cookies, since most edge bugs depend on specific request inputs." }, "name" : "How do you debug edge functions across many PoPs?" } ] } ```