Hello Reader,

There is a debate that plays out in almost every engineering team adopting cloud infrastructure. Containers or serverless. Kubernetes or Lambda. And almost every time, the person making the argument has already picked a side before the conversation starts.

The person adopting serverless says containers are too complex. The person adopting containers says serverless lacks features. Both are partially right and both are missing the point. The real answer depends on five factors, and knowing how to evaluate those factors is what separates a Solutions Architect from someone who just knows the tools.

Scaling works differently and the difference matters

Lambda scales by connection. Every incoming request spins up a separate Lambda instance. One instance cannot handle more than one connection at a time. There is no scaling configuration required because the service handles it automatically. You control concurrency, which caps how many copies run simultaneously, and that is it.

Containers scale by threshold. One pod or task can handle multiple connections. When CPU or memory hits a defined limit, another pod spins up. For Kubernetes that means configuring Horizontal Pod Autoscaler (and then Cluster Autoscaler or Karpenter). For ECS you use Application Auto Scaling or capacity providers.

The practical implication is IP address management. Lambda reuses IP addresses across instances within the same security group and subnet combination, so massive scaling does not exhaust your VPC range. Containers assign a separate IP to each pod or task. If your application scales to thousands of tasks, IP exhaustion becomes a real operational concern and you need to plan subnet ranges accordingly.

Lambda integrates out of the box. Containers require more wiring.

This is one of Lambda's clearest advantages. Over 100 AWS services integrate directly with Lambda. S3 puts an object, Lambda fires. SQS message arrives, Lambda pulls and processes it. SNS topic publishes, Lambda handles it. No integration layer required. No polling code to write and maintain.

Containers require more work to achieve the same result. If you want EKS to process SQS messages, you need to write the polling logic yourself in addition to the processing logic. If you want to expose a Kubernetes pod through API Gateway, you cannot do it directly. You need a load balancer with an ingress controller in between. ECS has more flexibility here, including direct API Gateway integration via AWS Cloud Map, but it still requires more configuration than Lambda.

The event-driven pattern is where Lambda genuinely has no equal. For anything that reacts to infrastructure events, file uploads, queue messages, or stream records, Lambda is the cleaner and faster path.

Resource configuration is where containers win

Lambda gives you one knob: memory. CPU is allocated proportionally. More memory means more CPU cores, up to six cores at the maximum 10GB memory setting. You cannot independently control CPU and memory. If your workload is CPU-intensive but memory-light, Lambda forces you to over-provision memory to get the CPU you need. In addition, Lambda can run upto maximum 15 mins.

Containers let you define CPU and memory independently in your pod spec or task definition. If your workload needs high CPU and low memory, you configure exactly that. If you are running on EC2 worker nodes, you can choose GPU instances for graphics-intensive workloads or memory-optimized instances for in-memory processing. Fargate has some constraints on the combinations available, but it still gives you more flexibility than Lambda. Both Fargate and Containers running on EC2 has no maximum duration constraint. In fact, webservers on containers pretty much run 24X7!

For high-performance, resource-specific workloads, containers are the right answer. For general compute triggered by events, Lambda is simpler and faster to operate.

High availability is automatic with Lambda and manual with containers

Lambda deploys across multiple availability zones automatically at no additional cost. The Lambda service acts as the internal load balancer. If one availability zone goes down, traffic routes to another without any configuration on your part.

Containers require you to build this yourself. You deploy pods or tasks across multiple availability zones, provision an Elastic Load Balancer to distribute traffic, and configure topology spread constraints for Kubernetes or task placement strategies for ECS. It is the same model as running EC2 in multiple availability zones. More control, more responsibility.

Cost is not as simple as comparing price per invocation

Lambda is primarily charged based on execution duration and memory allocated. It is pay as you go as in, you only pay when it's executing, and don't pay for idle. Lambda is generally cost effective with inconsistent traffic.

Fargate charges based on CPU and memory for the duration the task runs. EC2 worker nodes charge a flat hourly rate for the instance regardless of utilization. The comparison that trips people up is this: Lambda is good for unpredictable traffic, but if traffic is predictable EC2 is more cost effective.

Spot instances change the math significantly. ECS Fargate supports spot out of the box, running 70% cheaper than standard pricing. EKS on EC2 supports spot worker nodes. EKS Fargate does not support spot yet. Always run your own cost calculation before making a decision. The right answer depends on your traffic pattern, not a general rule.

The question every SA interview asks

When should you use Lambda and when should you use containers? The answer the interviewer is listening for covers five dimensions: where your data lives, what your compliance requirements are, how much infrastructure control you need, whether you have an existing CI/CD pipeline and application ecosystem, and how much operational overhead your team can absorb.

Lambda wins on simplicity, event-driven integration, and automatic high availability. Containers win on resource control, flexibility, and workload portability. The best architectures use both, with Lambda handling event-driven triggers and lightweight processing, and containers handling long-running, stateful, or resource-specific workloads.

Knowing the trade-offs in depth is what gets you hired. Picking a side is what gets you filtered out.

Keep learning and keep rocking 🚀,

Raj

P.S. If you have found this newsletter helpful, and want to support me 🙏:

Checkout my bestselling courses on AWS, System Design, Kubernetes, DevOps, and more: Max discounted links​

Checkout my YouTube channel for Cloud Gen AI tutorial and interview prep videos: Here​

AWS SA Bootcamp with Live Classes, Mock Interviews, Hands-On, Resume Improvement and more: https://app.cloudwithraj.com/​