When AWS Lambda launched in November 2014, it promised developers a world where servers simply vanished. A decade later, that promise has largely held, but teams have learned the hard way that serverless doesn’t mean consequence-free. Functions still time out, cold starts still bite, and a single misconfigured retry loop can quietly drain a budget overnight. According to AWS’s own Lambda documentation, the difference between a smooth FaaS deployment and a chaotic one usually comes down to a handful of design decisions made early. This guide walks through those decisions with the kind of practical detail that only shows up after you’ve been paged at 2 a.m.
Start With the Handler, Not the Framework
The single most common mistake in function as a service development is treating the handler function as the application. It isn’t. The handler should be a thin adapter that translates an event into a call to your core logic, then translates the result back out.
Why does this matter in practice? Because business logic buried inside a handler is nearly impossible to unit test without mocking the entire cloud event structure. Teams that separate the two find they can run thousands of local tests in seconds, and they can port the same logic to a container or a traditional server if requirements change.
A practical pattern looks like this: the handler parses the event, validates it, calls a pure function, and formats the response. Anything involving retries, logging, or metrics lives in middleware or a wrapper. The core function knows nothing about the cloud provider.
Keep Deployment Packages Small
Large packages slow down cold starts and make deployments fragile. AWS recommends minimizing package size, and in practice that means trimming dependencies aggressively. If a library is only needed for one rarely used code path, consider lazy-loading it or moving it to a separate function. The same discipline applies to any FaaS platform, whether it’s Azure Functions or Google Cloud Functions.
Initialize Outside the Handler
Execution environments get reused. That’s the whole trick behind warm invocations. According to AWS’s guidance on execution environment reuse, you should initialize SDK clients, database connections, and configuration reads outside the handler so they survive across invocations.
This is one of those tips that sounds obvious and gets ignored constantly. A developer writes `const client = new DynamoDBClient({})` inside the handler, and every single invocation pays the connection setup cost. Move it out, and the first invocation pays it while the next thousand reuse it.
The caveat: don’t assume the environment will be reused. Treat any state as a bonus, never a requirement. That distinction is what separates resilient functions from flaky ones.
Design for Idempotency From Day One
Event sources like SQS, EventBridge, and S3 notifications commonly deliver at-least-once. That means your function may see the same event twice, sometimes minutes apart, sometimes milliseconds apart during a retry storm.
If your function charges a credit card or sends an email, duplicate execution is a real business problem. The fix is an idempotency key: a stable identifier derived from the event, stored alongside a record of whether processing completed. Before doing work, check the store. After doing work, write to it. On a duplicate, return the cached result.
| Approach | Best For | Trade-off |
|---|---|---|
| Idempotency key in DynamoDB | Payment, order, and messaging flows | Extra read/write cost per invocation |
| Conditional writes | Simple dedupe | Requires a unique key in the event |
| Natural idempotency (PUT-style updates) | State overwrites | Not applicable to side effects like emails |
The teams that get this right build the dedupe layer before launch, not after the first duplicate charge.
Set Timeouts and Memory Deliberately
Default timeouts are almost always wrong for production. AWS Lambda defaults to 3 seconds with a maximum of 15 minutes, and that 15-minute ceiling was only introduced in 2018. If you leave the default in place, a function that occasionally takes 4 seconds will fail intermittently and confusingly.
The practical rule: set the timeout to roughly double your p99 latency, then alert when you approach it. That gives you headroom without letting a stuck function burn through your concurrency budget for 15 minutes.
Memory deserves the same care. On AWS Lambda, memory allocation also scales CPU, so a function that feels “slow” may simply be under-provisioned. Right-sizing memory is one of the few optimizations that improves both latency and cost at the same time. Test a few configurations with realistic load and compare the duration-times-cost math rather than guessing.
Make Statelessness a Hard Rule
Functions should never rely on local disk or in-memory state persisting between invocations. The `/tmp` directory exists, and on AWS it can now hold up to 10 GB, but it’s ephemeral and tied to a specific execution environment that may disappear at any moment.
Use external storage for anything that matters: object storage for files, a managed database for records, a cache for hot data. The one legitimate use of `/tmp` is scratch space within a single invocation, such as downloading a file, processing it, and uploading the result. Even then, clean up after yourself so a reused environment doesn’t inherit stale files.
Instrument Everything, Because Functions Are Short-Lived
A function that lives for 80 milliseconds is nearly invisible without deliberate instrumentation. Distributed tracing and structured logging aren’t optional extras in FaaS; they’re the only way to understand what happened.
The OpenTelemetry FaaS semantic conventions give teams a vendor-neutral way to describe function invocations, cold starts, and trigger types. Adopting those conventions early means you can switch observability vendors later without rewriting your instrumentation.
Practical tips that save real debugging time:
- Log structured JSON instead of freeform strings, so queries actually work.
- Include a correlation ID from the triggering event in every log line.
- Emit custom metrics for business events in addition to technical ones.
- Track cold-start frequency separately from overall latency.
- Set alarms on error rate and throttles in addition to raw invocation counts.
Lock Down Permissions Per Function
A function’s identity is its execution role, and that role should grant the minimum permissions the function needs. The temptation to reuse one broad role across a dozen functions is strong, and it’s how small breaches become large ones.
Beyond IAM, keep secrets out of plaintext environment variables. Use a secrets manager and fetch values at cold start, caching them in memory. Rotate runtimes on a schedule, because an unpatched runtime is an open door regardless of how clean your code is.
If your team is also wrestling with endpoint security tooling on the machines developers use to build and deploy, it’s worth understanding what an antimalware service executable actually does, and if it’s eating CPU during builds, there are documented steps to fix antimalware service executable high CPU usage. Slow local builds quietly push teams toward skipping tests, which is exactly the habit that breaks serverless deployments. (Function as a service)
Watch for Recursive Invocation Loops
This one deserves its own section because it has bankrupted companies. A function writes to a bucket, the bucket triggers the same function, which writes again. Or a function publishes to a queue that feeds the same function. AWS explicitly warns against recursive loops in its best practices, and the warning exists because people keep doing it.
Guardrails that work:
- Separate input and output locations so a function can’t trigger itself.
- Add a recursion-detection counter to events where the platform allows it.
- Set reserved concurrency limits on functions that could spiral.
- Test failure paths as well as happy paths before going live.
Keep Functions Focused but Not Microscopic
There’s a real debate about function granularity. One school says every function should do exactly one thing. The other points out that a hundred tiny functions create a hundred deployment pipelines and a distributed monolith that’s impossible to reason about.
The balanced answer: group functions by bounded context and deployment lifecycle. If two functions always change together and share dependencies, they probably belong in the same package. If they have different scaling profiles or security requirements, split them. The goal is independent deployability without an explosion of operational overhead.
This is also where governance matters. As function counts grow, someone needs to own naming conventions, tagging, cost allocation, and deprecation. Teams that skip this step end up with orphaned functions running for years. A clear set of AI governance principles, risks, and best practices offers a useful template for that kind of lifecycle discipline, even when the workloads aren’t AI-related at all.
Handle Cold Starts Realistically
Cold starts are the tax you pay for elasticity. They vary wildly by runtime, package size, VPC configuration, and provider. Claims from 2019 don’t reliably describe 2025 behavior, so measure your own workload rather than trusting blog benchmarks.
Mitigations that genuinely help:
| Mitigation | Effect | When to Use |
|---|---|---|
| Provisioned concurrency | Eliminates cold starts for a reserved pool | Latency-critical APIs |
| Smaller packages | Reduces init time | Always |
| Lazy initialization | Defers unused work | Functions with heavy SDKs |
| Snapshots (e.g., SnapStart) | Restores pre-initialized state | JVM-based functions |
For most internal workloads, cold starts are acceptable. For customer-facing endpoints with tight SLAs, paying for warm capacity is usually cheaper than losing users.
Control Cost With the Same Rigor as Performance
FaaS billing is per invocation and per duration, which makes cost a design variable rather than an afterthought. Two functions doing identical work can differ 5x in cost based on memory settings and batching.
Batch where the platform supports it. Process 10 messages per invocation instead of one when latency allows. Right-size memory. Delete unused functions. Set budget alarms. These aren’t glamorous tasks, but they’re the difference between a serverless bill that scales gracefully and one that surprises the finance team every quarter.
Conclusion
Function as a service rewards discipline. The teams that thrive with it separate handlers from logic, initialize resources outside the invocation path, design for duplicate events, set timeouts and memory on purpose, instrument everything, and lock down permissions per function. None of these practices are exotic. They’re the same fundamentals that made good server architecture work for decades, reapplied to a model where the server is invisible and the consequences of skipping them arrive faster.
The providers keep improving the platform. Cold starts shrink, limits expand, tooling matures. What doesn’t change is that a function doing too much, with too many permissions, and no observability will fail eventually. Build the guardrails early. Future you, asleep at 2 a.m., will be grateful.
What is the biggest mistake teams make with function as a service?
The most common mistake is putting business logic directly inside the handler. This makes testing painful, couples code to a specific cloud provider, and turns every refactor into a risky deployment. Separating the handler from core logic is the single highest-leverage change most teams can make.
How do you prevent duplicate executions in FaaS?
Use idempotency keys. Derive a stable identifier from the incoming event, check a durable store before processing, and record completion after. Since most event sources deliver at least once, this pattern is essential for anything involving payments, notifications, or state changes.
Are cold starts still a problem in 2025?
They exist but vary enormously by runtime, package size, and provider. Measure your own workload instead of trusting older benchmarks. Provisioned concurrency and snapshot-based restores have made cold starts manageable for latency-critical APIs, while most internal workloads can tolerate them.
Should every function do exactly one thing?
Not necessarily. Over-splitting creates deployment sprawl and a distributed monolith. Group functions by bounded context and deployment lifecycle. Split when scaling profiles, security requirements, or change cadence genuinely differ.
How much memory should a serverless function get?
Enough that latency stays within your target at realistic load. On platforms where memory scales CPU, under-provisioning makes functions slower and more expensive per request. Test a few settings under real traffic and compare duration-times-cost rather than guessing.
What should every FaaS function log?
Structured JSON with a correlation ID from the triggering event, the function version, cold-start status, and duration. Add custom metrics for business events. Without this, debugging an 80-millisecond invocation in production becomes guesswork.
