{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiboqh252mx5vyctlykwxjtk4gh5vosuyogesmzvzc3dqshfc2bpoe",
    "uri": "at://did:plc:qllwm7os6w6f6hxue4mcr7mz/app.bsky.feed.post/3mjze525tlow2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreieu62r2y46343fxw2f2gnbnwmeiyuo7txey5v2pdrj5dqvkjxsiq4"
    },
    "mimeType": "image/png",
    "size": 1973040
  },
  "description": "Serverless and edge architectures have changed how today’s apps are built, which also means they’ve also changed how they must be secured. If you’re deploying to AWS Lambda, Vercel Functions, Cloudflare Workers, or running distributed microservices across regions, your security model can’t rely solely on a traditional perimeter. The architecture itself distributes execution, scale, and exposure.\n\nThis guide explains:\n\n * What serverless security actually means\n * Why edge and microservices archi",
  "path": "/securing-serverless-and-edge-apps-with-arcjet/",
  "publishedAt": "2026-04-21T16:00:57.000Z",
  "site": "https://blog.arcjet.com",
  "tags": [
    "Explore how Arcjet fits into your architecture."
  ],
  "textContent": "Serverless and edge architectures have changed how today’s apps are built, which also means they’ve also changed how they must be secured. If you’re deploying to AWS Lambda, Vercel Functions, Cloudflare Workers, or running distributed microservices across regions, your security model can’t rely solely on a traditional perimeter. The architecture itself distributes execution, scale, and exposure.\n\nThis guide explains:\n\n  * What serverless security actually means\n  * Why edge and microservices architectures may expand your attack surface\n  * The most important serverless security best practices\n  * How application-layer protection fits into distributed systems\n\n\n\nIf you’re building modern infrastructure, this is the security model you need to understand.\n\n## **What Is Serverless Security?**\n\nServerless security refers to protecting applications that run on event-driven platforms where functions are spun up on demand, such as AWS Lambda, Vercel Functions, and other function-as-a-service environments.\n\nUnlike traditional servers, serverless workloads:\n\n  * Scale automatically and dynamically\n  * Do not expose a fixed server fleet\n  * Often run across multiple regions\n  * Are composed of many small functions\n\n\n\nSecurity in this model focuses less on hardening long-lived hosts and more on protecting individual functions, request flows, and service interactions. The core challenge is that every function becomes its own entry point.\n\n## **Why Serverless, Edge, and Microservices Architectures Increase Risk**\n\nIn a monolithic system, traffic typically flows through a centralized gateway where that gateway becomes the main enforcement point for rate limiting, filtering, and access control. Distributed architectures break that assumption.\n\n### **Multiple Public Entry Points**\n\nEach serverless function or edge route can accept requests directly. A login endpoint, webhook handler, AI inference API, and background trigger may all be independently invokable. An attacker doesn’t need to take down your entire application, they only need to target one expensive function.\n\n### **Geographic Distribution at the Edge**\n\nEdge runtimes execute close to users for latency reasons. If every request had to be routed back to a centralized security layer, you would undermine the performance benefits of edge deployment. Security controls must respect latency constraints.\n\n### **Internal Service-to-Service Risk**\n\nMicroservices communicate internally over HTTP or RPC. Retry storms, misconfigurations, or compromised credentials can generate traffic that looks legitimate at the network layer but still overwhelms downstream services. Perimeter security cannot see intent or identity context inside those calls.\n\nIn distributed systems, the security boundary is not just at the edge of the network, it exists at _every_ execution environment.\n\n## **Why Traditional Perimeter Security Is Not Enough**\n\nFirewalls, WAFs, and API gateways still play important roles. They provide:\n\n  * Network-level filtering\n  * Routing and authentication integration\n  * Centralized observability\n\n\n\nBut they operate at the infrastructure layer which means they generally lack:\n\n  * Deep awareness of user identity\n  * Fine-grained per-route enforcement\n  * Context about business logic\n  * Visibility into internal service intent\n\n\n\nIn serverless and microservices environments, relying exclusively on perimeter controls creates gaps. Some endpoints receive strong protection, while others rely on implicit trust. That inconsistency is where abuse often occurs.\n\n## **What Is Application-Layer Security in Distributed Systems?**\n\nApplication-layer security enforces protection inside the request lifecycle of each service or function. Instead of inspecting traffic only at the network boundary, it evaluates:\n\n  * User identity\n  * Request payload\n  * Route context\n  * Behavioral patterns\n  * Service-specific rules\n\n\n\nFor example, identity-aware rate limiting can combine IP address, email, API key, or account ID into enforcement logic, that is far more precise than simple IP throttling at a firewall. Because enforcement runs inside the service, it scales horizontally and does not require introducing a centralized bottleneck In distributed architectures, this placement is critical.\n\n## **Serverless Security Best Practices**\n\nIf you are securing serverless functions, edge deployments, or microservices, these best practices should guide your architecture.\n\n  1. **Enforce Rate Limiting at the Application Layer** Rate limiting should not exist only at the gateway. High-risk endpoints such as login, signup, password reset, and AI inference routes should enforce identity-aware limits within the function itself. This prevents attackers from bypassing coarse network limits and reduces resource consumption before expensive operations run.\n  2. **Protect Authentication and AI Endpoints Aggressively** Authentication endpoints are common targets for credential stuffing and brute force attacks and AI endpoints can be abused for cost amplification. Because these endpoints directly consume backend resources and often trigger downstream calls, they should have strict request validation and abuse controls embedded in their execution path.\n  3. **Apply Controls to Internal APIs** Internal service-to-service traffic is frequently under-protected. Apply reasonable rate limits and validation rules between microservices to prevent cascading failures. A misconfigured worker should not be able to overwhelm a downstream dependency indefinitely. Distributed systems fail gradually. Internal enforcement reduces blast radius.\n  4. **Avoid Centralized Latency Bottlenecks in Edge Architectures** If you deploy to edge runtimes for performance, avoid forcing all traffic through a distant inspection tier. Security enforcement should respect geographic distribution and operate as close as possible to where code executes.\n  5. **Maintain Consistent Policies Across Services** As teams scale, policy drift becomes a problem. Some services implement strict limits. Others rely on defaults. Define shared protection rules and ensure they are enforced consistently across serverless functions and microservices. Consistency is often more important than complexity.\n\n\n\n## **How Arcjet Fits Into Serverless and Edge Security Architectures**\n\nArcjet is designed to integrate directly into application runtimes such as serverless functions, edge handlers, and microservices. Rather than assuming all enforcement happens at a centralized gateway, it enables protection logic to run alongside application logic.\n\nThis approach:\n\n  * Scales horizontally with your app\n  * Preserves edge latency benefits\n  * Reduces reliance on centralized chokepoints\n  * Enables consistent policy enforcement across services\n\n\n\nIt complements, rather than replaces, API gateways and WAFs by adding contextual, identity-aware enforcement inside distributed execution environments. Arcjet exists as part of a defense in depth strategy where you delegate generic protections to the platform with Arcjet customized to protect high-value endpoints. Generic solutions are great for protecting against volumetric attacks, but application context makes the difference between distinguishing between an attack and legitimate requests from your largest user. That’s where Arcjet shines.\n\n## **FAQ: Serverless and Edge Security**\n\n### **Is serverless more secure than traditional servers?**\n\nServerless platforms reduce some infrastructure risks because providers manage the underlying host environment. However, they do not eliminate application-layer risks. Each function remains an exposed entry point that must enforce its own protections.\n\n### **Do I still need a WAF with serverless?**\n\nYes, but with a different purpose depending on where it’s deployed. Traditional WAFs filter known attack patterns at the network edge. Arcjet Shield WAF provides protection directly inside your application, alongside identity-aware rate limiting and abuse controls.\n\nFor many serverless and edge architectures, enforcing WAF and application-layer protection where your code runs is a better fit than relying solely on a centralized network WAF.\n\n### **How do you rate limit AWS Lambda functions?**\n\nYou enforce rate limiting inside the Lambda handler by evaluating request context before running expensive logic. This allows limits to scale with the function and use identity-aware signals such as IP, user ID, or API key.\n\nTools like Arcjet provide built-in rate limiting and abuse controls that run directly inside your Lambda functions, rather than relying only on upstream gateways.\n\n### **What is the biggest security risk in microservices?**\n\nInconsistent enforcement and internal service abuse are major risks. When services trust each other implicitly, misconfigurations or compromised components can cause cascading failures.\n\n## **Building a Security Model That Matches Modern Architecture**\n\nServerless, edge, and microservices architectures improve scalability and performance by distributing execution, your security must follow the same pattern.\n\nIf enforcement remains centralized while everything else becomes distributed, you introduce blind spots, inconsistent protection, and unnecessary latency. Modern systems require a layered approach: infrastructure controls at the network boundary combined with application-layer enforcement inside each service and function.\n\nArcjet is built for this distributed model. Instead of assuming security lives only at a gateway, it runs alongside your application code inside serverless functions, edge handlers, and microservices where identity, context, and intent are available. This allows rate limiting, abuse prevention, and WAF protection to scale horizontally with your architecture without creating a centralized bottleneck.\n\nAs architectures evolve, security strategies must evolve with them, and distributed systems require distributed protection and enforcement that lives where your code runs.\n\nIf you are building on Lambda, Vercel, or at the edge, security should be part of your runtime, not bolted on afterward. Explore how Arcjet fits into your architecture.",
  "title": "Securing Serverless and Edge Apps with Arcjet",
  "updatedAt": "2026-04-21T16:00:57.674Z"
}