Securing an environment on Amazon Web Services (AWS) has as much to do with configuration as with defending against novel exploits. AWS gives a team a large surface to configure, and every service carries its own defaults and its own ways of going wrong, so a good deal of the work comes down to finding weak settings and correcting them. For a security leader, the harder task is getting a whole team fluent in that work instead of leaning on one or two people who happen to know where it usually breaks.
In short:
- Defending AWS is mostly about "security in the cloud": the customer's half of the AWS shared responsibility model, covering identity, network, compute, and data configuration rather than the physical infrastructure AWS runs and secures itself.
- The AWS exposures this guide covers fall into four practical areas: identity and access management (IAM), network and perimeter, compute, and storage and data.
- Reading AWS documentation builds awareness; fixing a live misconfiguration inside a sandboxed account is how a team builds familiarity with the actual fix. TryHackMe's Defending AWS path is built around the second, with 23 hands-on labs at the time of writing.
- Each scenario room follows the same arc, from a real-world incident through identification and remediation to rebuilding the service securely, so a learner practices the whole fix rather than only the detection step at the start of it.
What does defending AWS actually mean?
Defending AWS means securing the parts of an AWS environment the customer is accountable for: identities, permissions, network configuration, compute hardening, and data protection. Under the AWS shared responsibility model, documented in the AWS Well-Architected Framework's Security Pillar, AWS is responsible for "security of the cloud" (the hardware, software, networking, and facilities that run its services), while the customer is responsible for "security in the cloud" (how those services are configured and used). The configurations a defensive team can act on sit on the customer's side of that line.
Getting oriented on that division is the starting point for the work. A team new to AWS security tends to benefit from the same foundations before touching any scenario: how the platform is structured, how permissions actually resolve, and which native tools report on the environment. TryHackMe's Defending AWS path opens with those foundations across First Steps Into AWS, the Shared Responsibility Model, Introduction to IAM, Introduction to Cloud Networking, Introduction to Cloud Computing, Introduction to Cloud Storage, and Introduction to AWS Security Tools, before any hardening exercise begins.
What are the most common AWS misconfigurations a security team needs to defend against?
The AWS exposures this guide covers fall into four practical groups: over-permissioned identities, open network paths, unhardened compute, and exposed data. Each maps to a specific service and a recognizable failure pattern.
- Identity and access management. IAM controls who can do what in an account, and it goes wrong when permissions accumulate past what a role needs. Common cases include a user with far more access than the job requires, a long-lived access key nobody rotated, a role scoped too broadly, and a lack of visibility into who holds which permissions. These are practiced in The Over-Privileged User, The Forgotten Access Key, The Overpowered Role, and The Silence of the IAMs.
- Network and perimeter. AWS network controls decide what can reach a workload. Typical exposures are a security group opened to the whole internet, a subnet that is more public than intended, a network access control list (NACL) that no longer does its job, and traffic that flows with no logging to show it. These are covered in The Wide-Open Security Group, The Not So Private Subnet, The Forgotten NACL, and The Invisible Network.
- Compute. Elastic Compute Cloud (EC2) instances and containers carry their own hardening burden. Frequent issues include a port exposed to the internet, an instance left unpatched, an instance metadata service that leaks credentials, and a container sharing more than it should. These appear in The Exposed Port, The Unpatched Instance, The Leaky Metadata, and The Oversharing Container.
- Storage and data. Simple Storage Service (S3) buckets and disk snapshots are where data tends to leak. The recurring patterns are a publicly readable bucket, a bucket whose encryption does not meet the organization's key-management requirements (AWS now applies default encryption to every bucket, so the gap is usually the absence of a customer-managed KMS key where one is required), a bucket with no access logging to show who reached it, and a snapshot shared more widely than intended. These are the focus of The Leaky Bucket, The Plain Bucket, The Blind Bucket, and The Shared Snapshot.
How is defending AWS different from defending on-premises infrastructure?
Defending AWS asks a team to apply familiar security principles through unfamiliar controls, and it puts unusual weight on control-plane configuration. In AWS, an incorrect identity, network, or resource-policy setting can change who can reach or administer a resource without anyone touching the underlying hardware, and the same application programming interfaces that operate the environment can be used against a poorly secured account. The underlying goals (least privilege, segmentation, patching, encryption, logging) carry over from on-premises work; the mechanisms that deliver them are AWS-native and behave differently.
For a team with a traditional infrastructure background, part of the learning curve is mapping known controls onto their cloud equivalents.
| On-premises control | AWS equivalent the team configures |
|---|---|
| Network firewall rules | Security groups and network access control lists (NACLs) |
| Physical and network segmentation | Virtual private cloud (VPC) subnets and routing |
| Privileged and local admin accounts | IAM users, roles, and policies |
| File server permissions | S3 bucket policies and access controls |
| Server patching and hardening | EC2 patch management and machine image hygiene |
| Access and event logging | CloudTrail and VPC Flow Logs |
Why does hands-on practice matter for AWS cloud defense?
Practicing a fix inside a real account is different from reading about it. A team can read the AWS documentation on public S3 buckets and still hesitate when a live bucket is exposed during an incident, because knowing a control exists and having reversed the setting under time pressure are different kinds of knowledge. Practice in a sandboxed environment lets a team rehearse the fix without putting a production account at risk.
The quality of that practice is worth measuring against a clear bar, since not every format clears it. A strong cloud defense exercise puts the learner in a realistic environment, walks them from spotting the problem through to remediating it, and then asks them to stand the service back up in a secure state, so a learner practices the complete defensive workflow rather than stopping at detection. The scenario rooms in the Defending AWS path are structured on that arc: The Leaky Bucket, for example, moves through a real-world incident, identification, remediation, and a "build it securely" step that has the learner deploy the service safely from the ground up. Building that competence across a team, rather than in one or two specialists, is where a shared training environment tends to earn its place.
How can a team build AWS defensive training that maps to these misconfigurations?
Building team-wide AWS defense tends to work best as a structured path that starts with foundations and then drills each misconfiguration class in turn. The Defending AWS path is organized in that order across five sections: an introduction to AWS and its security tooling, then dedicated sets of scenario rooms for identity and access management, network and perimeter defense, securing compute, and storage and data security. It runs to 23 hands-on labs at an introductory difficulty, which makes it a fit for bringing a whole team to a shared baseline rather than only advanced practitioners.
For a decisionmaker, the training also needs to leave a record. The path awards a certificate of completion, and a team plan through TryHackMe for Business can group the relevant staff, assign the path, and track completion against it, which leaves a per-person record of who has been trained on what. That record tends to be easier to point to later than an assertion that the team "knows AWS."
FAQ
What is the AWS shared responsibility model?
The AWS shared responsibility model divides security duties between AWS and the customer. AWS is responsible for "security of the cloud," meaning the physical infrastructure, hardware, and managed services it operates. The customer is responsible for "security in the cloud," meaning how they configure identities, networks, compute, and data on top of that infrastructure. A defensive team's work sits on the customer's side of that split, since that is the part the customer configures and can directly control.
What are the most common AWS misconfigurations?
AWS misconfigurations commonly cluster into four practical groups. In identity and access management, over-privileged users, unrotated access keys, and overly broad roles are common. In networking, security groups open to the internet and subnets that are more public than intended recur often. In compute, exposed ports, unpatched instances, and leaking instance metadata appear regularly. In storage, publicly readable buckets, encryption that does not meet an organization's key-management requirements, and over-shared snapshots are frequent sources of data exposure.
How is cloud security different from traditional network security?
Cloud security applies the same principles as traditional network security, such as least privilege, segmentation, patching, and logging, but delivers them through provider-specific controls and puts heavy weight on control-plane configuration. An incorrect identity, network, or resource-policy setting can change who can reach or administer a resource without any change to the underlying hardware, and the provider's own management interfaces can be used against a poorly secured account.
How do you train a team to defend AWS?
A team learns to defend AWS most effectively by practicing on live environments rather than only reading documentation, starting with platform foundations and then working through each class of misconfiguration hands-on. TryHackMe's Defending AWS path is built for this: it opens with AWS fundamentals and its native security tooling, then runs scenario-based rooms across identity, network, compute, and storage, each following a fix-it arc from real-world incident through remediation to a secure rebuild. It comprises 23 hands-on labs at the time of writing and can be assigned and tracked across a team through TryHackMe for Business.
Do you need to know how to attack AWS in order to defend it?
Understanding how an attacker abuses a misconfiguration helps a defender prioritize and fix it, but the core of cloud defense is the ability to identify an exposure and remediate it correctly. Defensive training that shows the impact of a weakness and then walks through hardening the service builds that ability directly, without requiring a learner to become a specialist in offensive cloud techniques first.
Guidance on the AWS shared responsibility model and service hardening is published openly by AWS, and hands-on defensive practice can be planned and tracked across a team through TryHackMe for Business.
Joanna Duffy