Hello Reader,

Ahh, the good old scaling. Easy peasy, right? Just create a trust auto scaling group, and you are done. Not so fast! Scaling is an important topic for both interviews and real-world projects, and in today's newsletter, we are going to learn how it differs between EC2, Lambda, and Kubernetes. Heads up - Kubernetes scaling is the trickiest, and we will spend the most amount of time explaining that part. Let's get started

Scaling vanilla EC2

Quite straightforward. You create an auto-scaling group that automatically adjusts the number of EC2 instances based on defined policies. You can set up scaling policies based on metrics such as CPU utilization, memory usage, or custom CloudWatch metrics. You can mention the minimum, maximum, and desired number of EC2s in this auto-scaling group to control cost.

Pro tip - Use scheduled scaling to pre-warm EC2 instances before a peak traffic event for your business

Scaling Lambda

This is the easiest service to scale among the three. Unlike vanilla EC2, and Kubernetes pods, one Lambda instance only serves one connection. As the concurrent traffic increases, each connection creates additional instances of the Lambda function. For that reason, no scaling policy is required. AWS Lambda function will automatically scale out of the box. You need to adjust the max concurrency limit for your function based on peak traffic

Pro tip - If you want to avoid Lambda cold start during heavy traffic bursts, enable Lambda Provisioned Concurrency, which will pre-warm pre-defined numbers of Lambda instances before a traffic surge happens. You can configure provisioned Concurrency either by schedule or dynamic target tracking (i.e. maintain the Provisioned Concurrency utilization at 80% of the total Provisioned Concurrency)

Scaling Kubernetes

In most Cloud interviews, you'd get this question: "Tell me how the Kubernetes cluster EC2 worker nodes scale." Most candidates answer: set Auto Scaling Groups to scale at a certain EC2 metric utilization like scaling regular EC2s. This answer is WRONG!

Instead here is how K8s cluster worker EC2, also known as VMs or Virtual Machines, scale:

Step 1: You configure HPA (Horizontal Pod Autoscaler) to increase the replica of your pods at a certain CPU/Memory/Custom Metrics threshold.
​
​Step 2: As traffic increases and the pod metric utilization crosses the threshold, HPA increases the number of pods. If there is capacity in the existing worker VMs, then the Kubernetes kube-scheduler binds that pod into the running VMs.
​
​Step 3: Traffic keeps increasing, and HPA increases the number of replicas of the pod. But now, there is no capacity left in the running VMs, so the kube-scheduler can't schedule the pod(yet!). That pod goes into pending, unschedulable state
​
​Step 4: As soon as pod(s) go to pending unschedulable state, Kubernetes node scalers (such as Cluster Autoscaler, Karpenter etc.) provisions a new node. Cluster Autoscaler requires an Auto Scaling Group where it increases the desired VM count, whereas Karpenter doesn't require an Auto Scaling Group or Node Group. Once the new VM comes up, kube-scheduler puts that pending pod into the new node.

Pro tip: If you need to achieve scheduled scaling with Kubernetes, utlize KEDA which can adjust the number of pod replicas based on cron schedules. And if you want to pre-warm VMs before traffic burst, implement Cluster Overprovisioner. Both KEDA and Cluster Overprovisioner works in conjunction with the scaling mechanism explained above.

Next time, if you get this question in your interview, you can knock it out of the park! What other interview questions do you find confusing? Feel free to reply to this email, and I will cover them in future editions.

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​

AWS SA Bootcamp with Live Classes, Mock Interviews, Hands-On, Resume Improvement and more (Next cohort launching September): https://www.sabootcamp.com/​

​

Keep learning and keep rocking 🚀,

Raj