TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

This live Karpenter session shows you the proven techniques modern Kubernetes teams use to operate effectively at scale.

You will learn:
→ Key resource efficiency techniques with Karpenter.
→ Practical hacks for disruption budgets, DaemonSet overhead, Graviton adoption, and more.
→ How to cut hidden infrastructure costs without impacting performance.
→ Multi-layer automation with Karpenter

Powered by: Jobsurface.com

Browse 614 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 48,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Most teams configure a node security group when they first stand up EKS and move on. It works well enough early on. The problems appear later, when different workloads on the same cluster need fundamentally different levels of network access. Understanding why requires starting with what a security group actually does.

A security group is a virtual firewall that AWS attaches to a network resource. Every packet flowing in or out of that resource is evaluated against its rules before anything else happens. Inbound rules control what traffic is allowed to reach the resource. Outbound rules control what the resource is allowed to send out.

AWS blocks all inbound traffic by default and allows all outbound. You write explicit allow rules to open access. There is no deny rule, if a packet does not match any allow rule, it is dropped. Security groups are stateful, so return traffic for an established connection is automatically permitted without a separate outbound rule.

To make this concrete: you have an EC2 instance and you want to SSH into it. You add an inbound rule allowing port 22 from your specific IP address. Anyone else attempting to reach port 22 is dropped at the security group layer before touching the instance. The instance itself can initiate outbound connections freely, because all outbound is allowed by default.

In a real deployment, security groups work in layers. An Internet Gateway accepts incoming traffic from the internet and passes it into the VPC. An Application Load Balancer distributes that traffic across EC2 instances in an Auto Scaling Group spread across multiple Availability Zones. The ALB has its own security group allowing port 443 from the internet. The EC2 instances have a separate security group that only allows traffic sourced from the ALB's security group, not from the internet directly. Nothing reaches the instances without going through the load balancer first.

This layered model is how security groups chain together in practice. Instead of maintaining lists of IP addresses that change as instances scale, you reference one security group from another. The application tier trusts the ALB security group. The database tier trusts the application security group. The rules stay stable even as the underlying instances come and go.

With this basic understanding of security groups, let's move on to the EKS context.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)