Nazli Singh

Study • Certification Diaries

Certification Diaries #1 — AWS Security Specialty

August 09, 2025

I’m starting a series to document my AWS certification journey. In this post I outline my study blueprint, resources I’ll use, and how I’ll evaluate progress.

  • Target: AWS Certified Solutions Architect – Associate
  • Resources: official exam guide, whitepapers, re:Invent sessions
  • Practice: hands-on labs + notes

Expect weekly updates in this series.

I started the AWS Security Specialty this week and, honestly, my brain wanted to back out so quickly, I got mental whiplash. What Am I Doing?! I can’t possibly understand something this complicated… But, when starting anything scary or daunting, I took a deep breath, and promised to take it one step at a time and see what happens. For the sake of the journey, that’s all.

I’ve started this blog series, “The Certification Diaries” to take you all along my certification journey and share insights and lessons I learn along the way.

To preface this series, I would like to state for the record that there is no RIGHT way or WRONG way to study. Yes, many people will have their opinions and advice, but ultimately, I believe that the way that works for you IS the way that works. I am not working with a strict deadline but I am working with a structured routine to keep myself on track and focused for the next 90 days. I’ll see how far I get. No pressure!

Ready? Deep Breath. Off we go.

To start the journey off, I am doing the **SCS-C02: AWS Certified Security - Specialty Specialization on Coursera.** This course attracted me as it starts off with covering the fundamentals and then moves on to the harder concepts and further deep dives.

This first week has been looking at how to keep hosts and networks secure. Or, to put it another way: How to keep the machine itself safe (host security) and keep the streets around it calm and secure (network security).

Host Security

I used to think “host security” meant making sure that it had everything it needs to stay secure - SSM Agent, CloudWatch Agent, Antivirus, Encryption, Backups, Security Groups, NACLs and a big sign saying “KEEP OUT”. Now I see it more like how to keep a child/or pet safe whilst trying to keep the house clean: less stuff, fewer messes, easier to spot what’s off.

Let’s take the EC2 service for example. This would translate into a few very practical moves:

  • No long-term access keys on the box. IAM Roles only. If a key lives on disk, sooner or later it’ll end up in a log, a screenshot, or a repo for all the world to see. Can’t be too careful with these kinds of things!
  • IMDSv2 or bust. It’s the seatbelt for instance credentials. It’s cheap, invisible, and the one time you need it, you’ll be glad it’s on.
  • Patch without babysitting. Systems Manager (SSM) Patch Manager on a schedule. If I have to “remember” to patch, I won’t.
  • Prefer Session Manager to SSH. Fewer open ports, proper audit trail, no juggling key files. It just removes so many sharp edges. If you’ve got to have it though, make sure to lock it up tightly with the right rules.
  • Encrypt by default. Turn EBS default encryption ON at the beginning of creating a new EC2 instance and at the account level.
  • Least privilege everywhere: tiny IAM policies, minimal packages, minimal opened ports. Teeny tiny chance of terrible things happening to the EC2 instance.
  • Central logs: send OS logs somewhere I’ll actually read them (CloudWatch Logs or a SIEM). Like a post-it on the fridge reminding me to get milk and read my logs.
  • Known-good baselines: use Systems Manager State Manager or an AMI hardening pipeline so new instances can start securely. Give the instance it’s best start by giving it values and configurations it can serve by.

:rubberduck: “Give the machine just enough to do its job (IAM Roles), keep it tidy, and don’t leave spare keys under the mat.”

Some services to help keep your Host secure

Amazon Inspector is the service that scans through your instance for any software vulnerabilities and unintended network exposure. Have you left the metaphorical door unlocked or are you using a rope to secure your side gate? It’ll create a detailed report about the status and issues with the instance or other resources you have within AWS, such as EC2, ECR and Lambda Functions.

GuardDuty does what you’d think it would from its name. Think of it like a neighbourhood watch for your resource logs and data sources. It doesn’t scream unless it sees something actually suspicious. It’s main job is to continuously analyse, monitor and process your data and logs by using threat intelligence feeds to protect and prevent potentials threats from effecting your resources within your AWS environment.

CloudWatch Logs is like the messy drawer where I toss all the logs from EC2, CloudTrail, Route 53 etc… but now it’s a messy drawer I can search and actually find things!

You can view, search for any particular error codes or patterns, filter the logs using specific fields or archive for later. Helps to have everything in one place, doesn’t it?

Network Security

Network security was always an enigma to me. No idea what it was but knew that it’s important and people who understand it are wizards. Now I understand that if i think about it like making sure that the streets in my neighbourhood are secured and safe, that my home is more likely to stay safer too.

Safety and security aren’t flashy and they aren’t supposed to be.

The design I like is boring (in a good way):

  • Only the load balancer is public. App and data tiers sit in private subnets. The ALB talks in; nothing else faces the internet.
  • Security Groups over NACLs for most work. SGs are stateful (like a bouncer at the nightclub knows you going in and when coming out) and easy to maintain; NACLs are stateless (like a door that only opens from one side) are great when you want a hard deny at the subnet edge. Each type has its uses but they’re not my daily go to.
  • VPC Endpoints are underrated. Hitting AWS services over private connections feels oddly satisfying and reduces your “whoops, that went over the internet” risk.
  • SGs that reference other SGs keep things readable: ALB-SG → App-SG on app ports, App-SG → DB-SG on the DB port, and that’s it. You can almost read it out loud.

The best “aah, gotcha” moment was around egress rules. In my head, outbound traffic was harmless; in reality, clamping it down plus using endpoints forces apps to talk only where they should. No traffic talking to strangers on the internet streets on my watch!

VPC Flow Logs were the hero. I turned them on, broke a rule on purpose, watched the “REJECT” entries appear, and then fixed the exact line that caused it. That feedback loop trains your intuition fast.

Add ALB access logs when you want HTTP detail; add Route 53 Resolver query logs when you’re chasing weird egress traffic by domain names instead of IPs.

Some key takeaways from the sticky notes I literally kept beside me:

  • “Roles, not keys.” If I need to copy a secret onto a server, I stop and ask why.
  • “IMDSv2 on every instance.” Set the requirement and forget about it.
  • “Does SSH have to come to the party?” If I really need to SSH onto the EC2 instance then fine, but try to use Session Manager first.
  • “Encrypt everything you can’t afford others to see.” EBS default encryption makes it more secure if there is a leak from a server/application or mis-shared unencrypted snapshot. Save yourself some embarrassment.
  • “SGs tell a story.” If I can’t read my Security Groups like a sentence (“ALB can talk to App on 443”), they’re too complicated.
  • “Logs before cleverness.” Turn on Flow Logs and ALB logs; save the packet mirroring and fancy tooling for when you have a clue where to aim them.

:rubberduck: “Rubber Duck says: “One front door only (LB). Everything else stays inside. Let the bouncers who remember faces (Security Groups) handle day‑to‑day access; save the one‑way doors (NACLs) for hard stops at the street. Take the private hallways (VPC Endpoints), not the sidewalk. Keep the guest list simple.”

What surprised me most was how often “security work” was just removing optionality. Take a bit off and see what breaks. Put it back and see what works. Locking things down didn’t make the system rigid; it made it predictable and maintainable.

Mini Lab Time!

1. Launch a Free Tier EC2 in a private subnet

  • Type: t2.micro or t3.micro (Free Tier eligible)
  • AMI: Amazon Linux 2 (already has the SSM Agent preinstalled)
  • IAM role: Create one with the AmazonSSMManagedInstanceCore policy attached and assign it to your instance.
  • Tip: Make sure the subnet is private (no Internet Gateway route).

2. Connect with Session Manager (no open ports!)

  • In the EC2 console, do not add an inbound SSH rule.
  • From the EC2 console, select your instance → Connect → Session Manager tab → Connect.
  • This works over AWS’s control plane — no public IP or open ports needed.

3. Turn on VPC Flow Logs (narrow scope)

  • Scope: Enable Flow Logs only on the instance’s network interface (ENI).
  • Destination: Send to CloudWatch Logs.
  • Retention: Set retention to 1 day so logs don’t pile up.
  • Filter: Choose ALL so you see both accepted and rejected traffic.

4. Tighten a security group rule too far

  • Edit your security group to block something the instance needs (e.g., outbound HTTPS).
  • Try to connect to the internet from the instance (via SSM session) — it should fail.
  • Check the Flow Logs for REJECT entries.

5. Loosen the rule just enough

  • Fix the security group so it allows the necessary traffic.
  • Test again — the Flow Logs should now show ACCEPT for those connections.

6. Clean up when you’re done!

  1. Delete the EC2 instance.
  2. Remove the security group you created.
  3. Delete the Flow Log and CloudWatch log group.

This keeps you within the AWS Free Tier and avoids surprise charges.

Thank you for making it this far!

I’m eager to hear your stories! How have your study journeys fared? What obstacles have you encountered and conquered? What lessons have you learnt?

If you’re looking to dive deeper into these topics or just want to share your own story, I’m all ears (eyes?). Follow me on LinkedIn at @NazliSingh. I can’t wait to connect and learn from each of you — your stories are what truly bring these conversations to life!

#AWS Security Specialty #certification #devops #AWS #SCS-C03 Series: Certification Diaries Study