How do you secure serverless and edge apps?

What is serverless security?

Serverless security protects applications that run on event-driven platforms where functions start on demand, such as AWS Lambda, Vercel Functions, and other function-as-a-service hosts. You do not harden a long-lived fleet. You protect each function, each request flow, and each service call, because every function is its own entry point.

Workloads scale automatically, often across regions, and they are composed of many small handlers. The interesting questions move from "is this host patched?" to "can this identity call this expensive function right now?" For more information about enforcing those decisions in the request path, see what is runtime application security.

Why do serverless, edge, and microservices increase risk?

In a monolith, traffic usually enters through one gateway that can rate-limit, filter, and authenticate. Distributed architectures break that assumption.

Each serverless function or edge route can accept requests directly. A login handler, webhook, AI inference route, and background trigger may all be independently invocable. An attacker does not need to take the whole application down; they only need to aim at one expensive function.

Edge runtimes execute close to users for latency. If every request returns to a centralized inspection tier, you give back the performance you bought. Security has to run where the code runs.

Microservices talk to each other over HTTP or RPC. Retry storms, a bad deploy, or a stolen service credential can generate traffic that looks fine at the network layer and still overwhelms a dependency. A perimeter device cannot see identity or intent inside those calls. The security boundary exists at every execution environment, not only at the edge of the network.

Why isn't perimeter security enough?

Firewalls, WAFs, and API gateways still matter. They filter at the network, integrate routing and authentication, and give you a single place to watch volumetric attack. They generally lack user identity, per-route business meaning, and visibility into internal service intent.

Relying only on the perimeter creates uneven coverage: some endpoints sit behind a well-tuned gateway rule, others rely on implicit trust. Abuse finds the gap. For more information about the API controls that belong next to application logic, see API security best practices.

The following table compares perimeter controls with application-layer enforcement.

Use both. Keep the edge for DDoS and coarse filtering. Put identity-aware limits and route-specific bot policy in the function.

What is application-layer security in distributed systems?

Application-layer security evaluates the request inside the function: user identity, payload, route, behavior, and service-specific rules. Identity-aware rate limiting can combine IP, email, API key, or account ID. That is more precise than IP throttling at a firewall, and it scales horizontally with the function instead of forcing every region through one chokepoint.

What serverless security practices should you follow?

Enforce rate limits in the function, not only at the gateway. Login, signup, password reset, and AI inference should check identity-aware capacity before they do expensive work.

Protect authentication and AI routes more aggressively than a public catalog. Those paths consume backends and often trigger downstream calls. Credential stuffing and cost amplification succeed when the handler runs first and the limiter sits somewhere else.

Apply limits and validation to internal APIs. A misconfigured worker should not be able to retry a dependency into the ground. Distributed systems fail gradually; internal enforcement shrinks blast radius.

Do not add a distant inspection hop just to satisfy a security checkbox on an edge route. Run the control in the isolate that already has the Request.

Keep policies consistent across services. Shared rules in a library beat a mix of strict functions and unprotected ones. Consistency matters more than a clever one-off.

How do you add Arcjet on Lambda, Vercel, and Cloudflare Workers?

Create one client at module scope (or from the Worker env binding), then call protect() before business logic. The following examples use Shield, bot detection, and a sliding window or token bucket. Start new rules in DRY_RUN on a busy route, then switch to LIVE.

AWS Lambda with @arcjet/node. This adapter does not take a Fetch Request. It takes an ArcjetNodeRequest, the http.IncomingMessage shape, so map the event onto headers, method, and url yourself. Pass ipSrc from the source IP the platform already verified, because there is no socket to read it from:

1
import type {
2
  APIGatewayProxyEventV2,
3
  APIGatewayProxyResultV2,
4
} from "aws-lambda";
5
import arcjet, {
6
  detectBot,
7
  shield,
8
  slidingWindow,
9
  type ArcjetNodeRequest,
10
} from "@arcjet/node";
11

12
const aj = arcjet({
13
  key: process.env.ARCJET_KEY!,
14
  rules: [
15
    shield({ mode: "LIVE" }),
16
    detectBot({ mode: "LIVE", allow: [] }),
17
    slidingWindow({ mode: "LIVE", interval: 60, max: 100 }),
18
  ],
19
});
20

21
export async function handler(
22
  event: APIGatewayProxyEventV2,
23
): Promise<APIGatewayProxyResultV2> {
24
  const req: ArcjetNodeRequest = {
25
    headers: event.headers,
26
    method: event.requestContext.http.method,
27
    // Keep the query string: Shield reads `query` from this URL.
28
    url: event.rawQueryString
29
      ? `${event.rawPath}?${event.rawQueryString}`
30
      : event.rawPath,
31
  };
32

33
  const decision = await aj.protect(req, {
34
    ipSrc: event.requestContext.http.sourceIp,
35
  });
36

37
  if (decision.isDenied()) {
38
    const status = decision.reason.isRateLimit() ? 429 : 403;
39
    return {
40
      statusCode: status,
41
      body: status === 429 ? "Too Many Requests" : "Forbidden",
42
    };
43
  }
44

45
  return { statusCode: 200, body: "ok" };
46
}

Vercel with @arcjet/next. The App Router handler already receives a Fetch Request:

1
import arcjet, { detectBot, shield, tokenBucket } from "@arcjet/next";
2
import { NextResponse } from "next/server";
3

4
const aj = arcjet({
5
  key: process.env.ARCJET_KEY!,
6
  rules: [
7
    shield({ mode: "LIVE" }),
8
    detectBot({ mode: "LIVE", allow: ["CATEGORY:SEARCH_ENGINE"] }),
9
    tokenBucket({
10
      mode: "LIVE",
11
      refillRate: 10,
12
      interval: 60,
13
      capacity: 20,
14
    }),
15
  ],
16
});
17

18
export async function POST(req: Request) {
19
  const decision = await aj.protect(req, { requested: 1 });
20
  if (decision.isDenied()) {
21
    const status = decision.reason.isRateLimit() ? 429 : 403;
22
    return NextResponse.json(
23
      { error: status === 429 ? "Too Many Requests" : "Forbidden" },
24
      { status },
25
    );
26
  }
27
  return NextResponse.json({ ok: true });
28
}

Cloudflare Workers are the exception. There is no request adapter for workerd, so Shield, bot detection, and IP analysis are not available there. What does run on Workers is @arcjet/guard, which covers rate limiting, prompt injection, content moderation, and sensitive information. Import from @arcjet/guard and the fetch transport is selected for you:

1
import { launchArcjet, tokenBucket } from "@arcjet/guard";
2

3
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
4
const limit = tokenBucket({
5
  refillRate: 5,
6
  intervalSeconds: 10,
7
  maxTokens: 10,
8
});
9

10
export default {
11
  async fetch(request: Request, env: unknown, ctx: ExecutionContext) {
12
    const key = request.headers.get("cf-connecting-ip") ?? "anonymous";
13
    const decision = await arcjet.guard({
14
      label: "worker.api",
15
      rules: [limit({ key, requested: 1 })],
16
    });
17

18
    ctx.waitUntil(arcjet.flush());
19

20
    if (decision.conclusion === "DENY") {
21
      return new Response("Too Many Requests", { status: 429 });
22
    }
23

24
    return new Response("ok");
25
  },
26
};

Guard rate limits take seconds as numbers (intervalSeconds, windowSeconds, maxTokens), not the duration strings the request rules accept, and denial is decision.conclusion === "DENY" rather than isDenied(). Workers need compatibility date 2025-09-01 or later. Because a module-scoped client cannot reach a per-invocation context, pass Cloudflare's ExecutionContext in and call flush() through waitUntil.

Pin the adapters you use: @arcjet/node@1.10.0, @arcjet/next@1.10.0, and @arcjet/guard@1.10.0. All of them are ESM-only, and the supported Node.js range is >=22.21.0 <23 || >=24.5.0. Node.js 23 is not supported and Node.js 20 is end-of-life.

How does Arcjet fit serverless and edge architectures?

Arcjet runs beside the handler instead of assuming every decision happens at a centralized gateway. That scales with the function, keeps edge latency, and lets each service enforce the same primitives: Shield, detectBot, and a rate limit keyed on application identity.

It complements a WAF or gateway. The platform absorbs volumetric attack. The SDK distinguishes your largest customer from a scraper because it sees the user, the plan, and the route. Generic edge rules are poor at that distinction.

Companion tutorials apply the same protect() shape on long-lived and GraphQL servers: how to secure a Node.js/Express API, how to secure a GraphQL API, and GraphQL rate limiting and bot detection.