Forem: Samia Khan

How blue/green deployments saved us from out of hours changes and downtime

Samia Khan — Mon, 09 Mar 2026 14:25:33 +0000

I was working on a project that provided a critical service to users that accessed the database (DB) throughout the day. In order to provide regular updates to the DBs, the DBAs would often perform these changes out of hours to avoid any impact to the live service. As the changes were required more frequently it became harder to coordinate these out of hours and fully test before the service became live the following day. This is where blue/green deployments came in.

What are blue/green deployments?

A blue/green deployment approach is a release management strategy that uses 2 identical production environments referred to as “blue” (live/production) and “green” (idle/new version to be updated). Only one environment serves traffic to users while the other remains inactive. This allows teams to deploy updates to the server that doesn’t handle live traffic yet which minimises downtime and reduces risk.

How was this implemented?

Firstly, a new database was spun up that was a replica of the current production (blue) environment which would act as the green server.

A Network Load Balancer (NLB) was also provisioned with 2 target groups with an IP address target type each pointing to the blue and green database server IPs. By default the deregistration delay on the NLB is set to 300 seconds for the existing connections to drain and close on their own, allowing for existing requests to complete successfully after which it will change the state of the target to unused. This delay was set to 0s as we wanted live traffic to be switched over immediately to use the updated database.

What was the impact?

A major advantage of implementing this approach was the ability to switch traffic from the blue to the green database instantly. With the NLB configured for immediate switching, we could deploy changes to the green database throughout the day, test them in a production like environment without impacting live traffic and switch back if necessary. This reduced the downtime we previously faced during out of hours deployments.

With the green database fully tested in parallel with the live environment, we could validate all changes before pushing them into production. This created a safety net as any issues that were identified during testing on the green server did not affect the live service. It also provided us with more time for testing as this could be done during the day whilst the blue server continued to serve live traffic.

In the past if a deployment failed, it was often a frantic scramble to fix issues before the service resumed the following day. Now with the ability to switch back to the blue environment by simply repointing the target group, rolling back a deployment became straightforward and low risk.

Whilst this meant that we had to ensure that the green environment was fully in sync with the blue environment and any discrepancies between the two could lead to unexpected issues when live traffic was switched over, it saved us a lot of time and improved the reliability of the overall deployment process.

Why I interviewed even when I was happy

Samia Khan — Sun, 08 Mar 2026 22:01:27 +0000

Things can change… very fast and you should always keep your options open.

I was working at a company I really liked. I had great managers and a supportive team, I enjoyed the work I was doing and felt like I grew so much as an engineer in a short amount of time. I saw myself growing there and staying long term. It was good… until it wasn’t.

One thing I look back on now is the fact that even when I was happy where I was, I would always do interviews. Not necessarily because I was intending on leaving but because I was using them to identify areas that I needed to grow in and how I was positioned in the market.

I didn’t think I would be needing those interviews any time soon. I was happy and had been put forward for promotion earlier than expected and thought that would be my path to becoming a senior engineer.

When I was told I wouldn’t be promoted as I hadn’t been at the company long enough, it was a shame but I could wait. I then received some not-so-great feedback a few months later, feedback that wasn’t given directly to me so there hadn’t even been a chance for improvement. I asked whether it would impact my promotion the following quarter and was assured it wouldn’t but when the time came, I was told they couldn’t justify promoting me because of that feedback along with additional feedback that had again not been shared with me directly.

That was all it took to change my view of things. The growth I had envisioned for myself for the next year or so suddenly seemed out of reach. It wasn’t even about the promotion anymore, it was the uncertainty and the constant moving target to become a senior engineer. I no longer knew what “good enough” looked like or even how to get there. The environment that once felt enriching and supportive slowly started making me feel like I was walking on eggshells. Even though I felt like I was doing good work, it still somehow wasn’t enough and no one could clearly tell me what “enough” actually was.

That’s when I realised why those practice interviews mattered. While internally my confidence shattered and I became hesitant to speak out and voice my opinions, externally I was reminded of my value. When you do these practice interviews, because theres no pressure to go above and beyond to get the job, it often ends up feeling like a normal conversation. The nerves dont kick in as much and you can actually focus on sharing your experience in its entirety without worrying about saying the ‘right’ thing. I was being asked thoughtful questions about my experience. I was being told that the work I thought was small or boring was actually impactful. It reminded me that one company’s timeline isn’t a universal measure of my ability and that growth doesn’t always look the same in every environment.

Here are some things I’ve learnt from these interviews:

A lot of the time I’m doing the right things in terms of engineering experience but I’m not communicating it in a way that gets my point across clearly.
I actually know a lot more than I think and I find myself talking about that seemingly boring piece of work I did a few months ago to rotate a bunch of EC2 SSH keys as valuable experience that taught me a lot about cloud security for example.
I can identify questions that I struggled to answer and what I can do to bridge that gap in my knowledge.

I still believe you can be happy somewhere and committed but those things aren’t mutually exclusive with keeping your options open. I realised that interviewing isn’t about leaving, it’s about staying ready so that when things suddenly change or don’t go as planned, you can be prepared for what’s next in your journey.

The worst position to be in is one where you’ve let your confidence quietly depend on a single outcome. I had placed so much emphasis in this one promotion that when I didn’t achieve it, it felt like I wasn’t good enough to begin with.

Interviewing even when you’re happy isn’t disloyal, it’s self awareness and preparedness to ensure that if the ground shifts beneath you, you already know you can stand somewhere else.

AWS Networking: Transit Gateway

Samia Khan — Wed, 22 Oct 2025 10:48:46 +0000

Transit Gateway (TGW) is a service that connects multiple VPCs and on premises networks using a single gateway. Before Transit Gateways if you had multiple VPCs that needed to talk to each other, you had to create multiple peering connections. Each connection required manual routing, was non-transitive and hard to scale. TGW solves this by acting as a regional layer 3 router which provides transitive connectivity between attached VPCs, centralised control over routing and propagation, and can scale to thousands of VPCs.

Attachments

TGW Attachments are the connections between the TGW and the VPCs or VPNs. Each attachment represents a link between a specific VPC or VPN and the Transit Gateway, allowing for efficient traffic routing. Without attachments the TGW doesn’t even know those VPCs exist.

Route Tables

A TGW by default has one route table and all other attachments use this for table for routing decisions. Routes are propagated from the attachments.

A route table can contain static routes, propagated routes automatically learned from attachments that you enabled to propagate into this table and blackhole route with “blackhole = true” to drop matching traffic and prevent specific paths.

TGW makes a routing decision based on the route table associated with the ingress attachment. This means that traffic entering from Attachment A will look at A’s associated route table to decide where to send the packet next. Return traffic will look at the returner’s associated table to avoid asymmetric routing.

Associations

An association binds one TGW route table to an attachment and determines which route table a connection (attachment) uses. That table governs egress from that attachment and you can re-associate an attachment to a different TGW route table at any time.

Propagations

Propagation lets an attachment advertise its network prefixes into a TGW route table automatically so other attachments associated with that table can reach it without manual static routes. You turn propagation on per attachment per TGW route table.

AWS Networking: SSL/TLS with Load Balancers

Samia Khan — Thu, 02 Oct 2025 10:46:18 +0000

I came across this question whilst preparing for the Advanced Networking exam:

A company wants a highly available web server that will sit behind an Elastic Load Balancer. The load balancer will route requests to multiple target groups based on the URL in the request. All traffic must use HTTPS. TLS processing must be offloaded to the load balancer. The web server must know the user’s IP address so that the company can keep accurate logs for security purposes.

The options involved choosing between an Application or Network Load Balancer and using a HTTPS or TLS listener and got me thinking about how TLS actually works and what it means to 'offload' the process to the load balancer.

What is SSL/TLS?

TLS is a protocol that encrypts data in transit between client and server.
It is the successor to SSL and provides a more advanced and secure protocol that provides encrypted communication over a network. TLS uses more robust hashing algorithms like SHA 256, a more efficient handshake process for establishing secure sessions and better data integrity to ensure data is not altered during transmission.

If SSL is deprecated and only TLS is used why do people still commonly refer to it as SSL or SSL/TLS is the question that was on my mind and here's what Chat said:

Excellent catch 👌 — this confuses almost everyone at first.
The short answer: TLS replaced SSL, but the name “SSL” stuck around in industry and tooling.
SSL is the old protocol (SSLv2, SSLv3) → insecure and deprecated. TLS is the modern replacement (TLS 1.2 / 1.3) → what we actually use today.
People still say “SSL/TLS” because:

Historical habit (TLS was once called “SSL 3.1”).

Vendors still market “SSL certificates” (really TLS certs).

Config files use old names (ssl_certificate in nginx, ACM “SSL cert”).

SSL became a generic term for encrypted web traffic.

The SSL/TLS Handshake Process

The SSL/TLS handshake is a process that establishes a secure connection between a client and a server. Here’s a simplified overview of the steps involved:

Client Hello: The client sends a “ClientHello” message to the server to establish a connection, proposing the supported SSL/TLS versions, cipher suites and a random number for session key generation known as the "client random."
Server Hello: The server responds with a “ServerHello” message, selecting the SSL/TLS parameters, the server's SSL certificate and the "server random."
Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it to confirm that the server is who it says it is.
Client Key Exchange: The client generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server. Session Keys Generation: Both the client and server generate session keys using the pre-master secret.
Finished: Both parties exchange encrypted messages to confirm that the handshake is complete.

How does this work with Load Balancers and Offloading?

Offloading to the load balancer means that traffic is decrypted by the load balancer before it is forwarded to the target servers through a process known as SSL termination.

When a client connects over HTTPS, the load balancer performs the TLS handshake, validates the certificate, and establishes the encrypted connection. Once the connection is secure, the load balancer decrypts the incoming traffic and forwards it to the backend servers in plain HTTP. For high performance applications, decrypting SSL/TLS traffic at the load balancer can optimise performance and simplify SSL/TLS management. SSL termination helps speed up the decryption process and reduces the processing burden on backend servers.

Application Load Balancer (ALB):

Supports HTTPS listeners, TLS termination, and automatically injects the X-Forwarded-For header so backend servers can still log the real client IP.

Network Load Balancer (NLB):

Can also terminate TLS, but operates at Layer 4. If end-to-end encryption is required, NLB can forward encrypted traffic to backend servers (TLS passthrough) or terminate TLS at NLB (similar to ALB, but without HTTP header features). If mutual TLS (mTLS) is required, NLBs can support this to allow the load balancer and backend servers to authenticate each other.

Benefits:

Performance Optimisation:

TLS handshakes and encryption are computationally expensive. By shifting this work to the load balancer, backend servers no longer need to handle decryption, freeing up CPU and memory resources for application logic.

Centralised Certificate Management:

Instead of managing certificates across multiple servers, you only need to maintain them on the load balancer using AWS Certificate Manager (ACM), which can automatically renew and rotate certificates without downtime.

Scalability:

Termination at the load balancer makes it easier to scale backend servers in and out since each new instance doesn’t need its own TLS configuration. The load balancer ensures a consistent secure entry point.

Journey to the Golden Jacket: Passing the AWS Solutions Architect Professional Exam

Samia Khan — Fri, 26 Sep 2025 15:22:18 +0000

Let me start off by saying I think the golden jacket is ugly and I would never be caught dead wearing it in public. Do I still want it? Absolutely. Will I still end up wearing it out somewhere? Most probably.

For those who don’t know, the golden jacket is what you get when you complete all 12 AWS certifications. Some see it as a flex, others as a milestone that represents weeks of hard work and time taken to prepare. For me it's more of a personal challenge. I remember coming back from re:Invent in December, seeing people walking around wearing their golden jackets and then seeing this picture:

It got me thinking about not only the lack of women in that picture but also the lack of women who dress and look like me and it ignited a very small spark of wanting to achieve it myself.

The Solutions Architect Professional exam is probably the hardest (and what felt like the longest) exam I've ever taken. The questions are very detailed and really require you to read and understand what's being asked. There hasn’t ever been a certification exam where I've used all the time available, but this exam had me checking my answers until the very last second. Not many people (from what I've read online) seem to pass this exam first time and I wasn’t one of them either lol.

I am well aware that certifications are no match for practical experience, but I feel like this exam has definitely expanded my knowledge as an engineer. Even just learning the theory of how things work has made it easier for me to understand complex architecture diagrams and why things are architected the way they are even if I'm not the one implementing it.

The best way to see certifications is either:

Deepening existing skills by backing them up with the theory of why things work the way they do.
Building new skills by first learning the theory and then applying it through projects that bring that knowledge to life.

So let me give you a timeline of events:

I originally set out to prepare for the DevOps Professional exam back in December 2023, with the goal of passing it before the end of 2024. Life and work got in the way and that didn’t end up happening.

It came to December 2024 and someone in my team had just passed the Solutions Architect Professional exam, and I realised that my Solutions Architect Associate was expiring in June 2025. That’s when I decided to shift my focus from the DevOps Professional to the Solutions Architect Professional which would automatically renew my Associate.

In January, I started Adrian Cantrill’s course and was making decent progress. A few weeks go by, I get busy and I no longer have as much time to prepare for the exam.

It gets to April and I realise I'm only 7% done with Adrian's course and with 2 months left until my Associate expires I need to get back on track so I start using Tutorials Dojo mock questions to speed up my prep. I had a voucher from the AWS All Builders Welcome Grant which was expiring on 31st May that needed to be used so I booked my exam for 30th May.

It gets to mid-May and I am still nowhere near ready to take this exam but with the voucher expiring, there’s no chance of rescheduling. I suck it up and take the exam knowing I'll most likely fail and I did but.... I only failed by a few marks. I realise that my prep has been working and I wasn’t that far off so I plan to retake it in a few weeks just before my Associate expires.

June comes around, I was on holiday and generally busy so didn’t get as much study time as I’d hoped. I intended to sit the exam the week after I got back from holiday but who was I kidding? I was too tired and lazy so that didn’t happen and sadly my Solutions Architect Associate (and Cloud Practitioner) expired.

Anyways, end of June and I continue with my prep and rebook my exam for end of July. This time I'm prepared (or so I think) for what's to come and I focus on using Tutorials Dojo and AWS documentation to prepare. I also start using the QA Cloud Platform labs and my personal AWS account to practice some of the concepts I'm learning about. Super grateful to the AWS Community Builders programme for the free subscription and the AWS account credits.

It's the end of July, finally time for my second attempt at this beast of an exam, I am incredibly nervous, and my family is sat somewhere praying for me (mostly so they don't have to deal with my tears if I fail again). I knew there were still areas I wasn’t strong in but I didn’t want to drag it out any longer and reschedule the exam.

I felt like the questions on the second attempt were much harder than the first time. I was asked about services I hadn’t even heard of and I finished that exam with the sinking feeling that I had failed yet again. A few hours go by and I get an email from Credly "Samia! You just earned a badge from AWS." and I am in shock but so relieved. This time it was a PASS!!!

So here I am, one step closer to earning this golden jacket that I will probably wear a grand total of once but when I do, I will be representing all the underrepresented women in tech who look and dress the way I do and hope that it serves as a reminder that women like us do belong.

The team member who passed and inspired me to take this exam has promised to be on this journey with me and one day we shall wear our golden jackets together and feel slightly less embarrassed. He just needs to give me some time to catch up to him (Please Johnny I beg, take a break).

Anyways here are some lessons learned:

Be consistent with your prep wherever you can — even small chunks add up
AWS Docs are your best friend (not just for this exam but in general)
Have more confidence in yourself — you probably know more than you think
Don’t listen to people who tell you certifications are pointless. Yes sometimes they can be because they wont be relevant to the work you're doing and realistically you don’t need to know about every service that exists but for me this journey of achieving the certification rather than the certification itself has been so helpful as an engineer in helping me understand architectural design decisions.

Next up: AWS Security Specialty

AWS Networking: Understanding CIDR Notation

Samia Khan — Wed, 24 Sep 2025 15:10:40 +0000

Having a solid grasp of networking fundamentals is essential to understanding complex AWS architectures. I first came across CIDR notation in my early days of working as a Network Engineer and it took me a while to wrap my head around it.

I've decided to revisit core networking concepts focusing particularly on how they apply in the AWS ecosystem, and where better to start than with refreshing my knowledge on a topic that was a pain to initially understand.

CIDR Calculation

An IPv4 address is a 32-bit number and each of those four decimal numbers is a group of 8 bits (an octet).

For example 10.1.3.0 is:

10 → 00001010 (8 bits)

1 → 00000001 (8 bits)

3 → 00000011 (8 bits)

0 → 00000000 (8 bits)

If you put them all together, you get a 32-bit binary string:

00001010 00000001 00000011 00000000

When it comes to CIDR notation, what we're trying to understand is how many of those bits are reserved for the network and how many are left for hosts. The way to calculate the number of addresses in a range is:
1: 32 - (CIDR prefix) = Host bits
2: 2^(Host bits) = Total IPs
3: Total IPs - 2 = Usable IPs

/8
32 - 8 = 24
2^24 = 16,777,216
Usable = 16,777,214

We subtract 2 because one IP is reserved for the network address and one for the broadcast address

A useful site to help you visualise this -> cidr.xyz

How does this relate to AWS?

When you create a new VPC it must be assigned a CIDR block which defines the IP address range that your subnets will be created from. For example you can create a VPC using 10.0.0.0/16 with /24 subnets inside it.

AWS reserves 5 IPs in every subnet so the usable count is actually:

/24 subnet → 251 usable (instead of 254).

/28 subnet → 11 usable (instead of 14).

The reserved addresses are:

Network address
VPC router
AWS DNS
Future use
Broadcast address

If you create a /28 subnet in AWS, you only get 11 usable IPs which might not be enough if you’re planning to launch multiple EC2 instances, a NAT Gateway, and other services in the same subnet.

AWS often recommends starting with /16 VPCs and then carving them into /24 or /20 subnets depending on your workload size.

AWS Security: KMS Keys

Samia Khan — Wed, 27 Aug 2025 16:54:48 +0000

I've been doing a lot of security related work recently so here's a summary of KMS keys and the different types.

Types of encryption:

Symmetric Encryption - Uses the same key for both encryption and decryption, commonly used for encrypting large amounts of data.

Asymmetric Encryption - Uses a public key to encrypt and a private key to decrypt, useful for secure key exchange and digital signatures.

Envelope Encryption - Encrypts data with a data key (symmetric) and then encrypts that data key with a master key (asymmetric). Top level key must remain unencrypted.

What is a KMS key?

A KMS key is a logical representation of a cryptographic key in AWS Key Management Service. It is used to encrypt and decrypt data across AWS services and applications and contains key material, metadata, and policies that control access. The key material can be generated by AWS or imported by the customer. KMS keys can be symmetric or asymmetric and support auditing through CloudTrail for compliance and security.

Key types:

1. AWS Managed Keys

Encryption keys created, owned, and managed by AWS for use in AWS services. Customers can't manage their properties directly.

When using an AWS Managed Key, it is theoretically possible for AWS to decrypt your data without you being aware of it and AWS is contractually forbidden from using all AWS KMS keys (including AWS Managed Keys) to access or decrypt your data except as required to operate the service or comply with the law.

2. Customer Managed Keys (CMK)

Customer-created keys in KMS with full control over permissions, rotation, and lifecycle. The customer is responsible for creating, updating, revoking, and deleting a CMK. Using a CMK may be required for regulatory or compliance reasons for workloads handling sensitive types of data like healthcare data.

Key Rotation

AWS Managed Keys - These keys are automatically rotated every year
CMK - Automatic key rotation can be enabled for Symmetric CMKs that don't have imported key material
Asymmetric CMKs – Must be rotated manually by creating a new key and updating aliases
CMKs with Imported Key Material – Must be rotated manually by re-importing or creating a new key

Deploying a Voting App on AWS EKS

Samia Khan — Sat, 12 Jul 2025 15:18:20 +0000

I wanted to refresh my EKS knowledge and deploy an app manually to a cluster.

I followed this video and decided to experiment with EKS Auto Mode. The app uses a MongoDB backend with persistent EBS volumes deployed as a StatefulSet with a primary and two secondary replicas. When deploying this on a cluster with Auto Mode for some reason it wouldn't schedule the pods for creation. I spent a bit of time troubleshooting but decided instead to create a new cluster without Auto Mode and created a node group with 2 nodes. I might revisit this project again and reattempt it with Auto Mode. These are roughly the steps I followed:

Created an EKS role and cluster
Created another role for the node group and created the node group with 2 nodes
Added the EBS add on which is needed for the persistent volumes
Created the MongoDB and API deployments
Created the Load Balancer service
Created the App deployment

After creating the Load Balancer service, I couldn't reach the endpoint when doing a curl. This was because even though the service was created, it had no endpoints because there was a label mismatch in my service configuration. My service was defined like this:

spec:
  selector:
    app: api

which meant it was looking for all pods in this namespace with the label app=api and trying to route traffic to them but my pods were labelled like this:

labels:
  role: api
  env: demo

So the load balancer was unable to find any pods with app=api and had nowhere to forward traffic to. Once the label was fixed and the service redeployed i could see the endpoints and reach the URL.

Labels are Important!

Pod selection: Services and controllers use labels to select target Pods.
Resource grouping: Organise objects by app, environment, team, etc.
Deployment strategies: Enable canary, blue/green, and version-based rollouts.
Monitoring & logging: Filter metrics and logs in tools like Prometheus or Grafana.
Network policies: Apply security rules based on Pod labels.

What is a StatefulSet?

A StatefulSet is a Kubernetes controller used to manage stateful applications. Unlike Deployments which are for stateless apps, StatefulSets give each Pod a unique, stable identity and persistent storage.
StatefulSets provide the following features, typically in combination with a Headless Service:

Stable Pod Names: e.g. mongo-0, mongo-1, mongo-2
Stable Network Identity: Each Pod has a unique DNS name
Persistent Volumes: Each Pod gets its own persistent volume claim (PVC) that is not reused by other Pods
Ordered Deployment and Scaling: Pods are created or terminated in order

What is a Service?

Since Pods are ephemeral and have dynamic IPs, a Service provides a consistent way to communicate with them. It is a method for exposing a network application that is running as one or more Pods in your cluster.
A Service allows:

Load balancing across matching Pods
Service discovery within the cluster
Decoupling between application components

Service Types:

ClusterIP: Exposes the service on an internal IP within the cluster and is only accessible from within the cluster.
NodePort: Exposes the service on a static port on each node.
LoadBalancer: Provisions an external IP via the cloud provider’s load balancer for applications needing external access.
ExternalName: Maps the service to an external DNS name (e.g. example.com). Doesn’t proxy traffic, just returns the DNS name.
Headless Service (ClusterIP: None): No ClusterIP is assigned. Used to expose each Pod’s DNS directly, essential for apps like StatefulSets or databases needing direct Pod-to-Pod communication.

AWS Auto Scaling and Load Balancing Basics

Samia Khan — Tue, 08 Jul 2025 17:28:06 +0000

This post will go over the basics of automating EC2 instance provisioning through the use of launch templates, auto scaling groups and load balancers.

What are Launch Templates?

Launch templates are reusable configuration templates for launching EC2 instances. They allow you to specify how you want your instances to be deployed by defining the AMI, instance type, security groups, user data etc and are especially useful in Auto Scaling groups, Spot Fleets, and EC2 Fleet setups.

Benefits:

Allows for consistency across instances provisioned by ensuring that resources are created with the required configurations.
Reduces the risk of errors and misconfiguration by using predefined templates.
Easily manage and update the configuration of your EC2 instances by updating the launch template and new instances created from the template will inherit the updated changes
Template versioning improves version control by allowing you to track changes made to a template and revert to earlier versions if needed.

What is an Auto Scaling Group?

An Auto Scaling Group (ASG) uses launch templates to automatically launch or terminate EC2 instances based on user-defined policies to ensure applications have the right amount of capacity to handle traffic.

Scaling types:

Manual scaling - Manually increase or decrease instance count

Dynamic Scaling - Automatically adjusts capacity based on metrics like CPU, memory, or custom metrics

Scheduled Scaling - Scales at specific times (e.g. add 5 EC2s every Monday at 9 AM)

Predictive Scaling - Uses machine learning to forecast traffic and scale in advance

Benefits:

High availability - Ensures enough instances are running to meet demand
Cost-efficiency - Terminates unnecessary instances when demand is low
Fault tolerance - Automatically replaces failed instances
Elasticity - Adds or removes EC2s based on metrics like CPU

What is an Application Load Balancer?

An Application Load Balancer (ALB) accepts incoming traffic from clients and distributes it across various targets such as EC2 instances.

Benefits:

ALB automatically spreads traffic across multiple Availability Zones, ensuring your application remains available even if one AZ fails.
Works seamlessly with ASGs by updating the target group to only send traffic to healthy instances as they scale up and down.
Allows for advanced routing based on paths, headers and and hostnames which enables microservices and multiple apps on a single EC2 to share the same ALB.

What is a Target Group?

A target group is a group of resources (targets) that a load balancer routes traffic to. You can define the health check settings for the targets, the port and protocol to use to route traffic and the target type such as EC2, IP address, Lambda or Application Load Balancer. It is the bridge between a load balancer and your application infrastructure.

How does it work?

When you register a target e.g. EC2 instances to a target group, you can attach the group to a listener rule on an ALB, NLB, or Gateway Load Balancer. When a request hits the load balancer, it uses listener rules to match the request and forward it to the appropriate target group. Health checks are used to monitor target availability. If a target fails, it is automatically removed from routing.

How do these services work together?

When you create a launch template to define your EC2 configuration, an ASG uses this template to launch instances based on the min, max and desired capacity specified. The ALB doesn't send traffic directly to your ASG, it does this through an ALB listener rule which forwards the request to the Target Group.

In summary:

1️⃣ A user accesses your app via the ALB DNS name.
2️⃣ ALB receives the request on port 80 or 443.
3️⃣ ALB listener rule forwards request to the Target Group.
4️⃣ Target Group checks which EC2s are healthy.
5️⃣ Target Group sends the request to one of the healthy EC2s in the ASG.
6️⃣ ASG monitors performance and scales EC2s up or down using the Launch Template.

AWS re:Invent: How I Finally Found My Sense of Belonging

Samia Khan — Thu, 03 Jul 2025 12:19:25 +0000

AWS re:Invent is one of the largest tech conferences hosted annually in Las Vegas with the aim of bringing together cloud computing professionals, developers, and industry leaders for a week of keynote presentations, technical deep dives, and hands-on learning.

In December 2024, I had the opportunity to attend AWS re:Invent as part of the All Builders Welcome Grant. This is a long-overdue post on how the experience not only expanded my technical knowledge but helped me find the sense of belonging I’d been searching for since I started my career.

But first, what is the grant and what does it offer?

The grant gives people in the first 5 years of their technology career the opportunity to attend AWS re:Invent for free by eliminating the financial barrier and promoting diversity in tech.

The grant includes:

Ticket to AWS re:Invent
Return flight to Las Vegas
5 nights accommodation
$75 Uber voucher for airport transfers in Vegas
$250 gift card for any expenses
Exclusive lounge and mentoring sessions
Reserved seats for keynote talks
Certification exam voucher
Dedicated mentor to support you throughout the week

What did I get up to during the week?

If you’ve ever been to an AWS Summit, you’ll know how huge these events are but nothing could’ve prepared me for just how massive re:Invent was! With multiple venues hosting various talks and workshops there was truly something for everyone.

I attended some talks around DevOps, CI/CD and Kubernetes and although these were quite interesting, my key highlights from the week and what I gained the most value from were live sessions and the interactions I had with other people. Being able to learn from and hear the stories of such a diverse group of people from all walks of life was incredibly inspiring.

I attended fireside chats with senior engineers and leaders, had a peer talk with Jeff Barr where I got to ask him some questions and even speed mentoring sessions in the exclusive All Builders Welcome lounge.

I particularly enjoyed the DevOps GameDay where I worked as a team to solve problems on AWS exploring services like EKS and ECR. This session really helped me understand my strengths, the various tools I like working with and gave me a steer on the direction I want my career to progress.

Other highlights:

Attending the AWS Partner Awards
Participating in sessions focused on women in tech
AI and ML quizzes in the Certification lounge
Networking at the expo and adding to my collection of tech related socks. I even got a cookie with my face on it!

So how exactly did I find my belonging?

Through community!😊

I started working as a Network Engineer a few months before Covid and was going into the office 4-5 days a week, having workshops and whiteboarding sessions with different teams to learn as much as I could. I even got the chance to configure a physical switch and take it to a data centre to rack and stack it. I went from that to working from home completely and having to get used to the world of teams calls and limited interactions.

When I transitioned to DevOps, it was hard to ask people for advice or find mentors to help me grow as I could no longer tap someone on the shoulder for a quick chat and didn't know who to reach out to. I often felt like an imposter and as though I wasn’t good enough to be a DevOps Engineer. So, thanks to covid (and no thanks to me being an introvert) I was able to hide away at home, have limited interactions with team members and little to no networking events. I hadn’t found (or looked hard enough clearly) for any online communities that resonated with me and was very isolated from many people out there who are willing to contribute and help others grow.

That all changed from the very first night I landed in Vegas. I met a wonderful lady at the airport who is an active member of the AWS Community. She introduced me to others and thanks to her, I found myself at various events including an AWS Women in Cloud bus tour meeting like-minded people from career changers to seniors who shared their stories. I was also fortunate to have an amazing mentor throughout the week who guided me on how to make the most of re:Invent and offered valuable career advice. It was then that I realised I wasn’t alone in feeling this way.

These interactions reminded me that feeling out of place or uncertain at times is something we all experience regardless of how far along we are in our careers. What matters is how we learn from those moments and continue to improve. Being surrounded by this energy really gave me the push I needed to keep going.

I now have dedicated communities that I’m part of which play a huge role in giving me that sense of belonging I’d been searching for. Through these connections, I’ve not only grown my network but also my confidence as an engineer and woman in tech. I’ve since had the chance to get involved in incredible opportunities like the AWS New Voices public speaking programme and the AWS Community Builders programme. Both have given me a platform to learn, contribute, and connect with others who share similar passions, reminding me that there’s a place for everyone no matter where they are in their journey.

What would I advise first time attendees?

Network as much as you can! You never know where it might lead you
Attend live sessions over ones that will be recorded
Make use of the reflection rooms. Whether you're looking for a place to pray, relax with some colouring and puzzles or even take a nap, these rooms were my refuge any time I was feeling overwhelmed.
Start your day fuelled. Each day can get really busy so make sure you start with breakfast every morning which is provided across all the venues. It's also a great chance to meet new and very interesting people. It was over breakfast that I met someone who introduced me to the Irish tradition of putting raisins in curry. Pineapple on pizza I can excuse (sorry Italians) but raisins in curry?? HORRIFYING.
Bring moisturiser, lip balm and stay hydrated! The air is very humid and your skin will get incredibly dry
Bring comfortable shoes - you’ll be walking A LOT. I averaged 20k-25k steps a day with my highest being 28k!
Have fun! Re:Invent isn't just about networking and learning, it's a chance to experience new things. Sign up for after conference events and arrive a few days early or stay for longer after the event if you can to explore Vegas and surrounding areas. I did a 2 day tour around Arizona and got to explore LA too!

If you have any questions about the application process or the grant feel free to leave a comment and I'll try my best to help out.

Linux Fundamentals for DevOps

Samia Khan — Fri, 06 Jun 2025 01:24:57 +0000

I decided to go back to basics and refresh my Linux knowledge. Here I'm recapping everything I've learnt. Useful notes here

I created a docker container running Ubuntu to practice using:

docker run -dit --name linux-learning --hostname ubuntu-dev --restart unless-stopped --cpus="2" --memory="4g" --mount type=bind,source="C:/ubuntu-data",target=/data -v /var/run/docker.sock:/var/run/docker.sock -p 2222:22 -p 8080:80 --env TZ=Europe/London --env LANG=en_GB.UTF-8 ubuntu:latest /bin/bash

Some important directories

/sbin -> System binaries for administrative commands
/bin -> Essential user binaries
/lib -> Shared libraries and kernel modules
/boot -> Stores files needed for booting the system
/usr -> Contains most user-installed applications and libraries.
/var -> Stores logs, caches, and temporary files that change frequently.
/etc -> Stores system configuration files.
/opt -> Used for installing optional third-party software

Understanding User Management

Creating users

There are 2 ways you can create a new user: useradd or adduser
useradd-> Directly modifies system files like /etc/passwd, /etc/shadow, and /etc/group to create a new user but you need to specify all options manually and by default it doesn't create a home directory unless you specify the -m flag. You also have to manually set the password for the new user using the passwd command after creating the user. Useful when writing scripts as it doesn't prompt for additional details.

adduser-> It provides a user-friendly, interactive experience by prompting you to enter a password and additional user details like full name, phone, etc. It automatically creates the home directory and uses configuration from /etc/adduser.conf for defaults.

In my case this command wasn't available by default and I had to install it using apt install adduser. You can check if you have it installed in /sbin

To see which users have been created you can check the /etc/passwd file.
User passwords are encrypted and stored in the etc/shadow file. Passwords cant be decrypted once created but can be reset using sudo passwd username.

Switching users

When switching to another user you can use either su username or su - username.
su username allows you to become that user but keep your current environment such as paths and variables and is useful for quick command execution.
su - username means you fully switch to the other user's environment including their paths, shell settings and any startup scripts.

Groups

Groups are used to organise users and manage permissions their collectively.
groupadd-> to create a new group
cat /etc/group -> to view groups
usermod -aG groupname username -> to add a user to a group
gpasswd -d username groupname -> to remove a user from a group

Understanding File Management

File Navigation

h – Move left
l – Move right
j – Move down
k – Move up
0 – Move to the beginning of the line
^ – Move to the first non-blank character of the line
$ – Move to the end of the line
w – Move to the next word
b – Move to the previous word
gg – Move to the start of the file
G – Move to the end of the file
:n – Move to line number n

Editing Text

x – Delete a character
X – Delete a character before cursor
dw – Delete a word
dd – Delete a line
d$ – Delete from cursor to end of line
d0 – Delete from cursor to beginning of line
D – Delete from cursor to end of line
u – Undo last action
Ctrl + r – Redo an undone change
yy – Copy (yank) a line
yw – Copy (yank) a word
p – Paste after the cursor
P – Paste before the cursor

Working with Multiple Files

:e filename – Open a new file
:w – Save file
:wq – Save and exit
:q! – Quit without saving
:split filename – Split screen horizontally and open another file
:vsplit filename – Split screen vertically
Ctrl + w + w – Switch between split screens

File Permissions

Change file permissions with chmod for users, groups and others.
r = 4
w = 2
x = 1

Change ownership using chown
Change user: chown user filename
Change user and group: chown user:group filename
Change group: chown :group filename or chgrp newgroup filename

Process Management

ps aux - shows a detailed list of all running processes on the system
ps aux | grep nginx - runs ps aux and pipes the output to grep which filters and shows only the lines containing nginx.
ps: the process status command
a: show processes for all users, not just the current user
u: display the process' user/owner.
x: include processes not attached to a terminal (e.g. background daemons)

kill -9 PID - forcefully kill a process
kill -STOP/-CONT PID - stop or resume a process

More commands here --> https://github.com/iam-veeramalla/ultimate-linux-guide/tree/main

Understanding AWS RAM: Benefits and Use Cases

Samia Khan — Tue, 03 Jun 2025 16:18:24 +0000

Have you ever needed to manage resources in multiple accounts and felt frustrated with provisioning the same resource multiple times and keeping them up to date?

With AWS Resource Access Manager (RAM), you can share resources you create in a central account across multiple accounts or Organisational Units in your Organisation, or accounts outside of your Organisation. It reduces operational overhead by allowing you to create a resource once and make it usable in other accounts.

Setting up AWS RAM

Creating a resource share in AWS RAM is super easy. Choose the resource you want to share, select the managed permissions to assign, and principals that you want to share it with and you're all set! AWS RAM will send invitations to the specified accounts to allow them to view the shared resources.

Benefits of AWS RAM

No Duplication: Share resources from a central account instead of duplicating them
Cost Efficiency: Avoid unnecessary costs from duplicate resources
Improved Security: Share resources with fine-grained access controls with only authorised accounts or principals

AWS RAM Use Cases

Sharing VPC subnets across multiple AWS accounts for shared network resources
Private hosted zones in one account can be shared and associated with VPCs in another account to enable DNS resolution for EC2s in the other account
Enabling cross-account access to data lakes and analytics resources for machine learning and data processing
Facilitating centralised security tooling by sharing resources like Security Hub findings or AWS Firewall Manager configurations
Enabling resource sharing for multi-account disaster recovery setups, improving resilience and failover strategies