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.

Somehow, it’s free - Sign up to get The Ultimate Claude Code Guide + 200 Free Engineering resources.

Powered by: Jobsurface.com

Browse 512 Worldwide Jobs Here →

If you’re not a subscriber, here’s what you missed last week.

How to Design API Gateway Security in AWS for Real World Systems

How to Design 3 Tier Architecture in AWS

To receive all the full articles and support TechOps Examples, consider subscribing:

One-time 25% OFF on all annual plans of memberships. Closes Soon.

kagent - Kubernetes native framework for building AI agents.

Designed to be easy to understand and use, and to provide a flexible and powerful way to build and manage AI agents.

Every time your browser shows a padlock in the address bar, TLS is doing its job. Transport Layer Security is the protocol that encrypts traffic between a client and a server, ensuring that a user's request to https://jobsurface.com cannot be read or tampered with in transit.

At its core, TLS works through a certificate issued by a trusted Certificate Authority (CA). The certificate proves the server's identity and contains the public key needed to establish an encrypted session. Without it, you are running plaintext HTTP, and anyone sitting between the client and your cluster can read every byte.

In AWS EKS, you have a Kubernetes cluster running real workloads. The question is not whether you need TLS but who manages the certificates. Doing it manually means generating keys, submitting CSRs to Let's Encrypt or your CA, downloading the cert, creating a Kubernetes Secret, and then repeating all of that before the cert expires in 90 days. That process is error-prone and does not scale.

cert-manager solves this entirely. It runs inside your cluster as a controller, watches for certificate requests, talks to your CA automatically, stores the issued certificate as a Kubernetes Secret, and renews it before expiry without any manual intervention. Pair it with the NGINX Ingress Controller on EKS and you get fully automated TLS from DNS to pod. Here is how the full architecture fits together.

A user types https://jobsurface.com into their browser. Route 53 resolves the hostname to the external IP of your AWS Network Load Balancer. Route 53 holds an A record or alias record pointing at the NLB.

The critical setup requirement here is that your domain must be managed in Route 53 so that cert-manager can use the DNS-01 challenge to prove domain ownership to Let's Encrypt or your chosen CA. cert-manager will use the Route 53 API to create a temporary _acme-challenge TXT record during the certificate issuance process.

The NLB receives the HTTPS request on port 443 and forwards it into the cluster. Unlike an Application Load Balancer, the NLB operates at Layer 4. It does not terminate TLS itself. It passes the raw TCP stream directly to the NGINX Ingress Service inside the cluster.

This is a deliberate design choice. TLS termination happens inside the cluster at the NGINX Ingress Pod, which means your cluster holds the private keys, not AWS. The NLB acts purely as a highly available entry point.

Inside the cluster, the NGINX Ingress Service receives traffic from the NLB and routes it to the NGINX Ingress Pod. The Service is of type LoadBalancer, which is what triggered the NLB provisioning in the first place via the AWS cloud controller manager.

This is where encryption ends and real routing begins. The NGINX Ingress Pod reads the TLS certificate from a Kubernetes Secret placed there by cert-manager, and uses it to decrypt incoming HTTPS traffic. From this point forward, traffic moves over private pod networking inside the cluster.

The Ingress resource is the configuration object that wires everything together. It specifies which hostname to serve, which Secret holds the TLS certificate, and which backend Service to forward decrypted requests to. The annotation cert-manager.io/cluster-issuer on that Ingress resource is the trigger that tells cert-manager to go fetch a certificate and write it into the named Secret automatically.

Once TLS is terminated, NGINX forwards the decrypted request to the Application Service, which load-balances across the running Application Pods. The pods handle the request, the response travels back through NGINX, gets re-encrypted, and returns to the user over the original TLS session.

cert-manager runs as its own pod inside the cluster namespace. It watches for Ingress resources carrying a cert-manager.io/cluster-issuer annotation. When it sees one, it initiates a certificate request to the specified issuer using DNS-01 challenge validation against Route 53.

The ClusterIssuer resource is what connects cert-manager to Let's Encrypt. It holds the ACME server URL, your email address for expiry notifications, a reference to the Secret where cert-manager stores your ACME account private key, and the DNS solver configuration pointing at your Route 53 region.

Once the Certificate resource exists in the cluster, cert-manager monitors its expiry. Let's Encrypt certificates expire every 90 days. cert-manager automatically renews the certificate approximately 30 days before expiry, overwrites the Secret, and NGINX picks up the new certificate on its next reload cycle. No engineer needs to touch it.

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

Looking to promote your company, product, service, or event to 55,000+ DevOps and Cloud Professionals? Let's work together.