There is a version of the serverless conversation that is not very useful. It turns into a generic debate about whether AWS Lambda is overhyped, whether cold starts are still a problem, or whether containers are more serious.
For small teams on AWS, the better question is simpler: when should AWS Lambda be the default choice?
My view is that AWS Lambda should be the default for small teams more often than people think. Not because serverless is perfect, but because it removes infrastructure overhead at the exact stage where teams most need to keep momentum.
That does not mean everything belongs on Lambda. It does mean many teams move away from it too early, often for reasons that sound architectural but are really about familiarity or fashion.
This becomes even more compelling when Lambda is paired with a tool like SST. SST keeps the infrastructure defined in code, close to the application, and manageable in the same workflow the team already uses. That makes Lambda easier to adopt without turning serverless into a pile of manual setup and hidden configuration.
Why AWS Lambda is such a strong default for small teams
For small teams, speed is not only about writing code. It is also about how much operational machinery the team has to carry while shipping.
Lambda is strong because it cuts down the amount of machinery early:
- no servers to patch
- no cluster to operate
- no container platform to set up first
- less deployment surface area to think about
- a direct path from application code to a running workload
Every extra layer of infrastructure becomes something somebody has to understand, debug, maintain, and revisit later.
The usual argument against Lambda is that it becomes limiting at some point. That is true. But a future limit is not a present problem. Small teams often make themselves slower by solving for a later operating model before they have earned the need for it.
That is another reason I like Lambda with SST. It keeps the path from application code to deployed infrastructure short. You still get infrastructure as code, reviewable changes, and a robust deployment model, but you avoid a lot of the platform ceremony that slows small teams down.
Where AWS Lambda fits best
Lambda is not only for tiny utilities. It is a very good fit for a lot of normal product work.
I reach for Lambda first when the system looks like one or more of these:
- an event-driven workflow
- an API with modest runtime needs
- a background job triggered by a queue or event
- a scheduled task
- a product with uneven or uncertain traffic
- a system where the team wants to stay focused on product code instead of service operations
This is especially true in the first phase of a product, when the architecture is still moving and nobody knows traffic shape with much confidence. Lambda works well in that uncertainty because it lets the team stay light.
It is also a good fit when the workflow boundary is clear. A request comes in, some logic runs, something gets stored, a message gets published, and the function exits. That is a clean serverless shape.
When teams use SST for this kind of system, that shape tends to stay understandable. The Lambda functions, queues, storage, and surrounding infrastructure can evolve together in code instead of being spread across dashboards, scripts, and half-documented setup steps.
What AWS Lambda gives small teams that containers do not
Containers are familiar, which is one reason teams move toward them early. But familiar is not always simpler.
With a container-based setup, even a relatively lean one, teams still need to think about:
- image build and storage
- service definitions
- networking and ingress
- scaling rules
- runtime patching assumptions
- deployment orchestration
None of that is unreasonable. It is just more platform than many small teams need at the beginning.
Lambda changes that tradeoff. It lets a team defer a lot of operating complexity until there is a real reason to absorb it.
That is why I think Lambda is often the right default even when containers would also work. The best first platform is not always the most flexible one. It is often the one that creates the least drag while the product is still finding its shape.
For AWS teams, SST strengthens that argument because it gives you a practical way to keep the serverless infrastructure explicit and maintainable without committing to a heavier platform model too early.
Where AWS Lambda and serverless start to become awkward
Lambda is not a good answer to every workload.
I start questioning it when one or more of these become true:
- the service wants to behave like a conventional long-running application
- startup behavior or latency becomes too sensitive
- the runtime needs are unusual or heavily customized
- the local development model drifts too far away from reality
- the system turns into a large network of functions, queues, retries, and compensating logic that becomes harder to reason about than a service would be
This is the point where teams should be honest. Sometimes a team says it is using serverless, but what it has really built is a distributed platform with hidden complexity. That is not a Lambda problem so much as a boundary problem. If the shape is wrong for Lambda, forcing it rarely improves the system.
The mistake small teams make with AWS Lambda
The most common Lambda mistake is not choosing it. It is abandoning it too early.
Teams often move away from Lambda because:
- they assume serious systems should run in containers
- they want one deployment model for everything before they need one
- they are more comfortable with long-running services
- they are designing around imagined scale instead of current needs
Those are understandable reasons, but they are not always good ones.
If Lambda is keeping the team fast, the system understandable, and the operating burden low, that is already a strong architectural result. It does not need to be replaced just because another model looks more mature on paper.
What to watch carefully in a Lambda-heavy system
If Lambda is the default, teams still need discipline.
The main things I would watch are:
- function boundaries that are too vague
- retries without clear idempotency rules
- missing tracing across asynchronous paths
- weak visibility into failures and queue buildup
- accidental sprawl in event flows
- too much business logic spread across too many handlers
This is where serverless systems can become hard to manage. Not because Lambda is inherently chaotic, but because teams sometimes mistake low infrastructure overhead for low architecture discipline.
You still need explicit boundaries, clear ownership, and enough observability to understand what the system is doing.
SST helps here as well, but only if teams use it directly and keep the infrastructure understandable. It is a strong tool for managing serverless systems as code. It is not a reason to pile on more abstraction than the team needs.
When I would move beyond AWS Lambda
I would move beyond Lambda when the constraints are real, repeated, and visible in delivery or operations.
That usually means one of these:
- the application clearly wants to be a long-running service
- the team needs more runtime control than Lambda is comfortable with
- performance characteristics require a different model
- the complexity of the function graph is now greater than the complexity of running a service
At that point, moving to a container model can be the right choice. But it should be a response to concrete pressure, not an early default.
In other words, Lambda should lose by evidence, not by assumption.
My default recommendation for small teams on AWS
If a small team is building on AWS and the workload fits reasonably well, I would start with Lambda first.
Use it for:
- event-driven workflows
- APIs with straightforward runtime needs
- queue-based workers
- scheduled jobs
- early product systems where speed and low operational drag matter more than maximum runtime control
Then move away from it only when the workload clearly wants a different operating model.
If the team is using SST, that becomes even more practical. You get a flexible and robust way to define the Lambda-based system in code while keeping it manageable as the product grows.
That is the part teams get wrong most often. They treat Lambda like a temporary toy instead of what it often is: the fastest, cleanest way for a small team to get useful systems into production without carrying unnecessary infrastructure weight.
For small teams, that is not a compromise. It is often the right architectural choice.