When to Use Serverless: 5 Security Decision Points

The Serverless Threat Model: What You Gain and Lose

Serverless removes the OS from your responsibility. No SSH keys to rotate, no kernel vulnerabilities to patch, no iptables rules to audit. The provider manages the host, and your function runs in a sandboxed runtime that dies after each invocation. This cuts your exposure to persistent threats like backdoors or rootkits.

But you lose visibility. You cannot inspect kernel logs, install a host-based IDS, or monitor network traffic at the packet level. The provider defines tenant isolation—you trust their hypervisor, their container runtime, their shared CPU scheduler. If a vulnerability exists in the function runtime itself, you wait for the provider to patch it. Check your SLA: some providers do not disclose CVE timelines for managed runtimes.

You also inherit IAM complexity. Every function needs permissions to read secrets, write logs, and touch your data layer. Misconfigure a policy and a compromised function can exfiltrate your entire database. Serverless makes IAM the primary security perimeter, not the network.

Decision Point One: Secret Rotation Frequency and Injection Model

Serverless wins when secrets rotate frequently. Credentials get injected at invocation time from a secret manager, not baked into an image or written to disk. If you rotate database passwords daily or use short-lived OAuth tokens, serverless pulls the current value on every cold start without redeploying code.

Containers and VMs require you to restart the process or poll the secret manager inside the application. This introduces a window where the old credential is still in memory after rotation. Serverless closes that window—each invocation is stateless and fetches fresh secrets.

The trade-off: if your secret manager has an outage, every function invocation fails. With a long-running server, you can cache credentials for a grace period. Test your secret manager's availability SLA before committing. I have seen functions go down because the secret manager hit rate limits during a traffic spike.

Decision Point Two: Attack Surface vs. Blast Radius

Serverless shrinks the attack surface by removing SSH, closing all ports except HTTPS, and isolating each invocation. An attacker cannot pivot from one function to another through the file system or shared memory. But the blast radius of an IAM compromise is larger—if one function's role has broad permissions, a code injection vulnerability gives the attacker access to everything that role can touch.

Containers offer the opposite trade. The attack surface is bigger: you manage the OS, open ports, and inter-container networking. But you can sandbox untrusted code with seccomp, AppArmor, or gVisor. A compromised container does not automatically get IAM credentials unless you explicitly mount them.

Use serverless when you control all the code and your functions perform simple, scoped tasks: resize an image, validate a webhook, query a read-only API. Use containers when you run third-party dependencies that could exploit the runtime, or when you need to execute user-uploaded scripts in a sandboxed environment.

• Serverless: smaller attack surface, larger IAM blast radius, no kernel-level sandbox
• Containers: bigger attack surface, controlled blast radius with namespace isolation, kernel sandboxing available
• VMs: full isolation but you patch everything, best for untrusted multi-tenant workloads

Decision Point Three: Cold Start Latency in Security-Critical Paths

Cold starts introduce latency. A function that has not run recently takes 200ms to 2 seconds to initialize, depending on the runtime and dependencies. For background jobs this does not matter. For an authentication flow it breaks the user experience.

Worse, cold starts create a window where you might serve stale data. If your function validates a JWT against a revocation list cached in memory, a cold start means the first request after idle time does not have that cache. You either accept the risk or add a warm-up request to every deploy, which costs money and adds complexity.

Provision reserved concurrency if latency matters. This keeps a pool of warm instances running, but now you are paying for idle compute—often more than a small VM that runs continuously. At that point the serverless cost model stops making sense. Check your SLA: if 99th percentile latency must stay under 200ms, measure cold-start behavior under real traffic before migrating.

Decision Point Four: Compliance and Shared Tenancy Boundaries

Some compliance frameworks explicitly forbid shared tenancy. PCI-DSS allows it if the provider is certified, but some auditors flag serverless runtimes as unacceptable risk because you cannot prove logical isolation. HIPAA and FedRAMP have similar edge cases. Read your BAA or compliance attestation carefully.

Serverless providers isolate tenants at the VM or container level, but they do not give you dedicated hardware. Side-channel attacks like Spectre theoretically allow one tenant to read another's memory, though no public exploit has succeeded in production. If your threat model includes nation-state attackers or you handle classified data, you probably need bare metal or single-tenant VMs.

For most workloads, provider isolation is sufficient. AWS Lambda uses Firecracker, a purpose-built VMM designed for multi-tenancy. Google Cloud Functions and Azure Functions use gVisor and Hyper-V containers. These are hardened runtimes, not general-purpose Docker. But if your auditor says no, you cannot argue with the checkbox.

Hardening Checklist: Securing Serverless Functions Before Deployment

Start with IAM. Every function should have a unique role scoped to the minimum permissions required for its task. Do not reuse roles across functions. A logging function does not need S3 write access. An API gateway function does not need DynamoDB admin. Write your policies in Terraform or CloudFormation so you can audit them in version control.

Enable function-level logging and send logs to a centralized system with tamper-proof retention. Serverless functions are ephemeral—if you do not ship logs off the platform immediately, you lose forensic evidence when the runtime terminates. Set retention to at least 90 days. Some compliance frameworks require a year.

Never put secrets in environment variables. They appear in logs, crash dumps, and the provider console. Use the provider's secret manager and fetch secrets at runtime. Rotate them automatically. If a secret leaks, revoke it in the manager and every function gets the new value on the next invocation.

Set aggressive resource limits. Cap memory at what your function actually needs, not the provider maximum. Set timeout to the longest reasonable execution time plus a buffer. A function that runs forever because of an infinite loop will cost you thousands of dollars in a single day. I have seen this twice.

Disable public URLs unless the function explicitly needs anonymous access. Default to internal VPC invocation or require an API key. Public URLs show up in search engines and get scanned by bots within hours. If you must expose a public endpoint, add rate limiting at the API gateway layer and validate every input.

Verification: How to Audit Your Serverless Security Posture

Run an IAM policy audit. List every function and its attached role. Check for wildcard permissions, cross-account access, or roles that grant more than the function uses. Tools like AWS IAM Access Analyzer and GCP Policy Analyzer flag overly permissive policies automatically. Fix them before an incident forces you to.

Test cold-start behavior under load. Spin up a load generator and measure p99 latency after the function has been idle for 10 minutes. If it exceeds your SLA, either provision reserved concurrency or rethink the architecture. Do this in staging with production traffic patterns, not with a single curl request.

Verify secret rotation. Manually rotate a database password in your secret manager and confirm the function picks up the new value without redeployment. If it does not, your code is caching credentials or pulling from the wrong source. Check your logs for secret fetch errors.

Review your provider's shared responsibility model. Confirm you own encryption at rest for data in S3, DynamoDB, or any other service your function touches. The provider encrypts the runtime and infrastructure, but application data is your job. Enable encryption on every resource and rotate the keys annually.

Run a function with deliberately bad input and confirm it fails safely. Inject a SQL payload, an oversized file, a malformed JSON body. The function should reject the input, log the attempt, and return a generic error—not a stack trace that leaks internal paths or dependency versions. If exceptions are verbose, add a global error handler.

When Not to Use Serverless: Recognizing the Wrong Fit Early

Serverless is a poor fit for long-running tasks. If your workload takes more than 15 minutes to complete, you will hit the function timeout. Some providers allow up to an hour, but you pay for every second of execution. A batch job that runs for 45 minutes is cheaper on a VM that you terminate after the job finishes.

Do not use serverless for stateful applications that require sticky sessions or in-memory caches shared across requests. Functions are stateless by design. If you need to track user sessions or cache expensive computations, you will pay the latency cost of external storage on every invocation. A container with local Redis is faster and simpler.

Avoid serverless when you need fine-grained network control. You cannot install a custom firewall, run a packet sniffer, or enforce egress filtering at the IP level. The provider controls the network. If your compliance regime requires evidence of network segmentation or DPI logs, use a VM with full network access.