Lesson 185 · AWS Learning Path

AWS 185: Architecture: apply identity, network, data, detection, and compliance controls in layers

Anil Jalela · Published Dec 27, 2025 · 8 min read

Why this lesson matters

Apply identity, network, data, detection, response, and compliance controls to threats and responsibilities without relying on one perimeter.

What you will be able to do

By the end, you can:

• explain architecture: apply identity, network, data, detection, and compliance controls in layers in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+----------------------+
|   Asset and threat   |
+----------------------+
           |
           v
+----------------------+
|  Preventive control  |
+----------------------+
           |
           v
+----------------------------------+
|  Detective and response control  |
+----------------------------------+
                 |
                 v
+------------------------------------+
|  Recovery and compliance evidence  |
+------------------------------------+

Start with threats, assets and responsibilities

Defense in depth is not buying one service per layer. Identify data/assets, actors, entry points, trust boundaries, abuse cases, regulatory duties, business impact and shared-responsibility owner. Then select controls that prevent, detect, contain, recover and prove. Every control needs scope, operator, evidence, failure mode, cost and exception lifecycle.

Apply controls to the request path

For an internet application, trace: authoritative DNS → CloudFront/Shield/WAF → ALB/API endpoint → workload identity and SG → secret retrieval → encrypted database/object store → logs/findings → response workflow → backup restore. At every arrow ask who authenticates whom, what is encrypted, what policy allows it, how bypass is prevented, what logs prove it, and what happens when that dependency fails.

Preventive controls reduce likelihood but can fail or be bypassed. Detective controls must have signal, owner and response SLA. Corrective controls should be reversible and tested. Recovery controls need RTO/RPO evidence. Compensating controls require a documented gap and expiry, not permanent exception language.

Multi-account security architecture

Use workload accounts to reduce blast radius, a Log Archive account for protected organization logs, a Security Tooling account for delegated security administration and findings, and dedicated Network/Shared Services accounts where scale justifies them. Keep the Organizations management account minimally used. Delegate services only where supported and verify each account/Region; aggregation is not collection.

Central controls can create a new concentration of privilege. Protect security/log accounts with restricted break-glass access, hardware-backed MFA, immutable/retained logs, key separation, monitored policy changes and tested recovery. Disable unused Regions or deploy baseline logging/detection there.

Threat-to-control decisions

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open IAM Access Analyzer, VPC controls, KMS, security findings, Config, and Audit Manager read-only views; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws accessanalyzer list-analyzers --query 'analyzers[].{Name:name,Type:type,Status:status}' --output table
aws ec2 describe-security-groups --query 'SecurityGroups[].GroupId' --output text
aws kms list-aliases --query 'Aliases[].AliasName' --output text
aws guardduty list-detectors --output text
aws configservice describe-configuration-recorders --output table

Expected interpretation

A secure architecture ties each control to a threat, asset, owner, observable event, tested response, exception, and recovery path. More products do not automatically mean better security.

Practical work

Threat-model the P05 application for stolen credentials, public exposure, injection, data theft, malicious dependency, DDoS, insider change, deleted data, and audit request. Assign preventive, detective, responsive, and recovery controls.

Diagnose this topic from its own evidence

• A service enabled in one Region is a coverage claim, not organization proof; enumerate accounts, Regions, resource eligibility and delegated status.
• If a preventive control blocks production, use break-glass and rollback evidence, then correct policy safely - do not permanently bypass it.
• If findings have no owner/SLA, detection is not an operating control; route and test failure delivery.
• If compliance report says passed but restore/incident tests fail, the control design or evidence is insufficient.
• During review, identify single points of control-plane privilege, log tampering, key deletion, DNS/origin bypass and untested recovery.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Apply identity, network, data, detection, response, and compliance controls to threats and responsibilities without relying on one perimeter.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Layered security architecture.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Layered security architecture.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid check-box security, overlapping tools without ownership, or controls that cannot be tested and recovered.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Produce a threat model and end-to-end request/data/evidence diagram for P05.
• Map every major threat to preventive, detective, responsive and recovery controls with owners.
• Separate workload, management, security tooling, logs, network and shared services account duties.
• Prove account/Region/resource coverage and identify aggregation-versus-collection gaps.
• Present costs, residual risks, exceptions, rollback and test evidence - not just a list of AWS services.

Official sources

• AWS Security Reference Architecture
• AWS security best practices
• AWS SRA account structure
• Apply security services across an organization
• AWS security documentation