AWS Cloud Security Foundations: Week 1 notes
Security Objectives, Design Principles and Operational Ecosystem.
Series: AWS Cloud Security (4 articles)
- 1AWS Cloud Security Foundations: Week 1 notes This article
I have been building on AWS for a while and i realised there is so much more in just building, there is a need in securing what you actually built. That's what actually lead to my Journey in AWS Cloud Security. This is my first week and here are key takeaways from this week's class:
The Security Objectives
Security in the cloud isn't just a static perimeter; it is a continuous operational baseline built around five core pillars:
Controllability: Who (or what) can take action, and under what conditions?
Auditability: Can I reconstruct what happened, when, and by whom, after the fact?
Visibility: Do I have real-time insight into the state of my environment?
Agility: Can I adapt controls quickly as threats and requirements change?
Automation: How much of this can run without a human in the loop, reliably?
What I found useful is that these aren't independent — they trade off. More automation often improves agility but can reduce controllability if guardrails aren't tight. Auditability underpins both visibility and controllability, since you can't govern what you can't see or reconstruct.
Security Design Principles
There are seven principles that form the backbone of the AWS Well-Architected Framework (Security Pillar). They define how to design systems that reduce risk while maintaining high operational velocity in the cloud and they include:
- Apply the Principle of Least Privilege
- Enable Traceability
- Secure All Layers (Defense-in-Depth)
- Automate Security
- Protect Data in Transit and Data at Rest
- Prepare for Security Events
- Minimize the Attack Surface
Attack Mechanics: SYN Flood and UDP Reflection
This was the part I found most valuable, because it's where theory meets protocol behavior:
SYN Flood is a type of DDos attack that floods a server by making a multiple connection requests until the server resources has been exhausted. Mitigations like SYN cookies avoid holding state until the handshake completes, which is a neat example of a design principle (don't trust unconfirmed state) applied directly to a protocol weakness.
UDP Reflection is Dos technique whereby an attacker asks the target computer for information by using a forged source address. The service replies to the victim — and because many of these protocols return responses much larger than the request, the attacker gets free amplification. Mitigations here lean on network-level controls like BCP38 source-address filtering, since the vulnerability lives at the protocol/network layer rather than the application.
Working through both side by side made it clear why "understand the attack before the defense" is worth the time investment — the mitigations stop being a checklist and start being obvious responses to a specific weakness.
Operational Ecosystem
Last piece this week was distinguishing a Managed Service Organization (an internal team within the company handling day-to-day operations/security) from a Managed Service Provider (an external, contracted entity providing similar services). The distinction matters for accountability: shared responsibility looks different depending on whether the "manager" is inside or outside your org boundary, and that affects contracts, SLAs, and incident response ownership.
Next up is diving deeper into IAM and the shared responsibility model in more depth. If anyone else is working through this course or has notes/resources on SYN flood or UDP reflection mitigations at scale, I'd love to compare notes.
Series: AWS Cloud Security (4 articles)
- 1AWS Cloud Security Foundations: Week 1 notes This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article