Cloud Security Training for Teams: AWS and Azure Security Skills

Many regulated organizations run AWS for core infrastructure alongside Azure for identity. Core principles like least privilege and log monitoring carry over between the two clouds, but a meaningful share of what a security team needs to know is still platform-specific: identity and access management works differently, the native monitoring tools are different, and a team that has only trained on one cloud may struggle to interpret the other's alerts and workflows the moment an incident touches it. Closing that gap across a whole team takes more deliberate planning than leaving individual analysts to pick it up on their own.

• AWS and Azure security skills do not transfer one-to-one. IAM (Identity and Access Management) policy logic, native monitoring tooling, and detection workflows differ enough that a team needs deliberate, platform-specific practice on both, not a single generic "cloud security" module.
• Building that practice safely takes a sandboxed, on-demand environment rather than production access, since a team learns IAM and Sentinel by working against a live environment, not by reading about one. TryHackMe's Defending AWS and Defending Azure paths give teams that kind of environment.
• Cloud skills build on top of core SOC (Security Operations Center) capability rather than replacing it: a team without solid alert triage and log analysis fundamentals, the kind built in TryHackMe's SOC Level 1 path, will often struggle with cloud-specific detection content, even when it knows the platform well.
• Hands-on lab completion, tracked against team-wide metrics, shows leadership what a team can actually do, rather than what they've studied or claimed on a CV. That kind of practical exposure is what builds real capability in the first place.

Why do security teams need both AWS and Azure security skills, not just one?

Because misconfiguration and identity failures show up differently on each platform, and a team trained on only one cloud may struggle to interpret the other platform's alerts and workflows during an incident.

The underlying risk is the same on both clouds: identity and access controls that are too permissive, configuration that drifts without anyone noticing, and logging that exists but isn't being watched closely enough to catch anomalies quickly. None of that is platform-specific. It is the same risk expressed twice, once in AWS's vocabulary and once in Azure's, which is why platform-specific, hands-on training for each is often more effective than one generic "cloud security" module: TryHackMe builds its AWS and Azure content as two separate tracks for this reason.

The shared responsibility model, the term for where a cloud provider's security obligations end and a customer's begin, works the same way conceptually on both platforms, but the specific controls a team is responsible for differ because the underlying services differ. On AWS, that means IAM policies, security group configuration, and what happens inside a VPC (Virtual Private Cloud). On Azure, it means Entra ID (formerly Azure AD) role assignments, network security groups, and Defender for Cloud configuration. TryHackMe's Defending AWS path opens with its own dedicated Shared Responsibility Model room before moving into AWS-specific misconfiguration scenarios, so a team gets that grounding upfront rather than assuming it. A team that has only practiced one side of that line may need additional time to interpret unfamiliar controls and workflows during an incident.

What should AWS security training for a team actually cover?

A comprehensive AWS security training programme typically covers identity and access management, network and perimeter controls, compute, and storage, since these are where most real-world AWS misconfigurations happen, and it needs to happen hands-on rather than through documentation alone. TryHackMe's Defending AWS path follows that same structure, running 23 hands-on labs across roughly 15 hours 30 minutes and awarding a certificate of completion on finishing.

Each room in the path follows the same format: a short real-world incident scenario, then identification, remediation, and rebuilding the service securely from scratch, so a team practices spotting a misconfiguration and fixing it, not just reading about the theory:

• Foundations. First Steps Into AWS, Shared Responsibility Model, Introduction to IAM, Introduction to Cloud Networking, Introduction to Cloud Computing, Introduction to Cloud Storage, and Introduction to AWS Security Tools cover the account model and vocabulary a team needs before any security-specific content makes sense.
• Identity and Access Management. The Over-Privileged User, The Forgotten Access Key, The Overpowered Role, and The Silence of the IAMs each work through a realistic IAM misconfiguration, one of the most frequent sources of AWS security misconfiguration, and how to scope it back down.
• Network and perimeter defense. The Wide-Open Security Group, The Not So Private Subnet, The Forgotten NACL, and The Invisible Network cover the network-layer mistakes that expose resources that were never meant to be reachable.
• Securing compute. The Exposed Port, The Unpatched Instance, The Leaky Metadata, and The Oversharing Container cover EC2 and container-level misconfigurations.
• Storage and data security. The Leaky Bucket, The Plain Bucket, The Blind Bucket, and The Shared Snapshotcover S3 and snapshot misconfigurations, one of the most commonly misconfigured categories of AWS services.

What should Azure security training for a team actually cover?

A comprehensive Azure security training programme typically centres on the tools an Azure-focused SOC actually uses day to day: Microsoft Sentinel, KQL (Kusto Query Language, the query language Sentinel and Azure Monitor use for log analysis), and Microsoft Defender XDR (Microsoft's extended detection and response platform for endpoints and identities). TryHackMe's Defending Azure path covers that same stack. It runs to roughly 19 hours across 19 hands-on labs and awards a certificate of completion, and it was designed to let teams simulate live attack scenarios and write real detection queries without needing enterprise Azure credentials or cloud billing set up.

The path is structured in four sections that build on each other:

• Microsoft Sentinel. Introduction, Deploy, Ingest Data, Detect, and Investigate take a team from standing up Sentinel through to actively investigating alerts inside it, the core workflow of an Azure SOC.
• KQL. Introduction, Basic Queries, and Advanced Queries build the query skill that everything downstream in Sentinel depends on. A team that cannot write KQL will have limited flexibility when building detections or investigating complex incidents.
• Microsoft Defender XDR. Introduction, Defense Evasion, Privilege Escalation, Lateral Movement, Execution, and Credential Access map directly to real attacker tactics, giving analysts practice recognising each one inside Defender's telemetry.
• Azure security challenges. MS Sentinel: Just Looking, Azure DevSecOps, Azure: Eyes Wide Shut, Azure: Hoppity Hop, and Azure: Tapper combine everything into scenario-based challenges that test whether the skills actually stick under more realistic, less signposted conditions.

How does AWS security training differ from Azure security training in practice?

They differ in three places that matter for how a team should plan its training time: the identity model, the native monitoring stack, and where the bulk of the skill-building effort goes.

• Identity and access control. AWS security work centres on IAM: policies, roles, and the permission boundary model, expressed as JSON policy documents attached to principals. Azure security work centres on Entra ID (formerly Azure AD): role-based access control, conditional access policies, and service principals, with identity far more tightly coupled to the rest of the Microsoft ecosystem than IAM is to AWS.
• Native monitoring and detection tooling. AWS visibility runs through CloudTrail (AWS's audit log of account activity) for control-plane logging and GuardDuty for threat detection, both of which a team typically pipes into an external SIEM (Security Information and Event Management) platform. Microsoft's native security stack for Azure centres on Sentinel as a cloud-native SIEM in its own right, paired with Defender XDR for endpoint and identity detection, meaning the detection tooling is far more built into the platform itself, though many Azure environments still route data into a third-party SIEM instead.
• Where the skill-building weight sits. AWS's breadth of individually configurable services means training for it tends to spend more time on service-by-service misconfiguration: identity, network, compute, and storage, each with its own attack surface. Azure's SOC-oriented native tooling means training for it tends to spend more time on the investigation workflow itself: writing KQL queries, triaging Sentinel alerts, and recognising attacker techniques inside Defender XDR telemetry.
• What a team is optimising for. A team optimising for cloud infrastructure and workload security leans AWS-heavy. A team optimising for detection and response inside a Microsoft-centric environment leans Azure-heavy. Many regulated organisations ultimately need capability across both, because they run AWS workloads behind Microsoft-managed identity and monitoring.

Should a team start with AWS or Azure first?

Start with whichever platform carries more of the organisation's production workloads today. The Defending AWS path opens with its own foundational section covering account setup and core cloud concepts, so a team doesn't need a separate cloud-fundamentals room before starting it; the Defending Azure path builds its foundations directly into its Microsoft Sentinel section instead.

For a government or financial services team running core infrastructure on AWS with Entra ID for identity, that usually means AWS first for the infrastructure-facing risk, followed by Azure once the team has bandwidth, since Entra ID and Microsoft Sentinel touch identity and detection across the whole organisation rather than a single workload. For a team running most of its estate inside Azure and Microsoft's ecosystem, the order reverses. Many organisations expand beyond a single cloud over time, so the real planning question is sequencing both, not choosing one permanently.

How does hands-on lab practice compare to reading documentation or watching a course?

It closes a different gap. Reading AWS or Azure documentation builds vocabulary and conceptual understanding. It does not test whether someone can recognise a real over-permissive IAM policy, spot a publicly exposed S3 bucket in an actual bucket policy, or write a KQL query that surfaces the right Sentinel alert under time pressure.

A team that has only read about IAM least privilege may still struggle to apply those concepts under operational pressure. A team that has repeatedly worked through a real over-permissive IAM policy in a sandbox, as TryHackMe's The Over-Privileged User room and the rest of the Defending AWS path's Identity and Access Management section have them do, is far more likely to catch the same mistake in a real environment before it ships.

Where does a team practice cloud incident investigation on AWS and Azure?

On AWS, the Splunk 3 room puts a team through a full incident investigation using real data from Splunk's own "Boss of the SOC" competition, working through AWS CloudTrail (AWS's audit log of account activity), IAM enumeration, and a cryptomining foothold that has to be traced back to its entry point. TryHackMe recommends completing Splunk: The Basics and the BOTSv2 room before attempting it. On Azure, that same investigation practice is already built into the Defending Azure path: the MS Sentinel: Investigate and Microsoft Defender XDR rooms are constructed as investigation exercises in their own right, so a team gets that same practice without needing a separate room for it.

For a broader intro to incident response and malware analysis work beyond either platform's own content, that sits in TryHackMe's SOC Level 2 path, which includes a dedicated Incident Response section and a Malware Analysis section.

How does a team track whether AWS and Azure training is actually working?

Through completion and performance data at the team level rather than individual self-assessment. TryHackMe's Management Dashboard is built to provide exactly that, tracking metrics like average dwell time and mean time to respond across a team, aligned to frameworks including MITRE ATT&CK and NIST, and giving a security leader an evidence base for board or regulator conversations rather than a list of completed modules with no indication of whether the skills actually transferred.

FAQ

What is the difference between training a team on AWS security versus Azure security? AWS security training focuses on identity, network, compute, and storage misconfigurations (IAM, security groups, EC2, S3), reflecting the platform's breadth of individually configurable services. Azure security training focuses on SOC-native tooling: Microsoft Sentinel, KQL, and Defender XDR, reflecting how tightly Azure's security tooling is integrated with its identity and monitoring stack. TryHackMe's Defending AWS and Defending Azure paths each reflect that difference.

How can a team practice cloud incident investigation on AWS and Azure? On AWS, the Splunk 3 room gives a full incident investigation exercise using real CloudTrail data, recommended after completing Splunk: The Basics and the BOTSv2 room. On Azure, the MS Sentinel: Investigate and Microsoft Defender XDR rooms already in the Defending Azure path serve the same purpose. For broader incident response and malware analysis training, TryHackMe's SOC Level 2 path covers that in depth.

Does a team need its own AWS or Azure subscription to do this training? No. TryHackMe provides sandboxed AWS and Azure environments as part of both paths, so a team practices against a live cloud environment without needing its own subscription, billing setup, or any risk to production infrastructure.

How long does it typically take a team to build baseline AWS and Azure security skills? This depends on the team's starting point and how much time is allocated weekly, but the Defending Azure path runs to roughly 19 hours across 19 labs, and the Defending AWS path runs to roughly 15 hours 30 minutes across 23 hands-on labs covering identity, network, compute, and storage. Teams generally see the most durable results from consistent, scheduled weekly practice rather than a single intensive push.

Is hands-on cloud security training suitable for regulated industries like government and financial services? Yes. Hands-on, sandboxed practice suits regulated environments particularly well, because it produces evidence of what a team can actually do rather than just what they've read, which is what audits and board reporting actually ask for. TryHackMe maintains dedicated training programs for government, financial services and insurance, and technology sector teams, with content and management dashboard reporting aligned to frameworks including MITRE ATT&CK and NIST, giving leadership a defensible, evidence-based answer for board and regulator conversations.

What is the shared responsibility model and why does it matter for AWS and Azure training? The shared responsibility model is the division between what a cloud provider secures (the underlying infrastructure) and what a customer is responsible for securing (identity, configuration, and data within their account). It matters for training because the specific controls that fall on the customer's side differ between AWS and Azure, since the underlying services differ, and a team that has only trained on one platform's version of that model is more likely to assume the wrong thing is the provider's responsibility on the other.

To see how AWS and Azure training fit alongside SOC and Threat Hunting simulators, tabletop exercises, and a full-team capability program, visit TryHackMe for Business.