Guide G5 · DevOps path

Advanced AWS: Landing Zones, Network Hubs, and Security Services

Running AWS at company scale: Organizations, SCPs, Control Tower and landing zones, IAM Identity Center, Transit Gateway, PrivateLink and endpoints, WAF and Shield, and the detective services (CloudTrail, Config, GuardDuty, Security Hub, Inspector, Macie) wired together with EventBridge.

Advanced 55 min

Start here

The mental model

One AWS account is one apartment: fine for one person, chaotic for a company. A LANDING ZONE is the building: many accounts (apartments) with shared, centrally managed infrastructure: identity (the front door), networking (the corridors), logging (the CCTV), and rules nobody can break (the building code). Teams get their own accounts with freedom inside, and guardrails at the edges.

Go deeper

How it works inside

01Accounts as the unit of isolation

AWS ORGANIZATIONS groups accounts into ORGANIZATIONAL UNITS (OUs) such as Security, Infrastructure, Workloads/Prod, Workloads/Non-prod, and Sandbox. Separate accounts give hard blast-radius limits (a compromised dev credential can't touch prod), clean cost separation, and separate service quotas (AWS course, multi-account security baseline).

SERVICE CONTROL POLICIES (SCPs) set the MAXIMUM permissions for accounts in an OU. Even an account's admin can't exceed them: deny leaving the organisation, deny disabling CloudTrail or GuardDuty, deny regions you don't use, deny creating IAM users with access keys. RESOURCE CONTROL POLICIES (RCPs) add org-wide limits on resource policies (e.g. no S3 access from outside the org).

Accounts as the unit of isolationdiagram

Rendering diagram…

02Control Tower and identity

CONTROL TOWER sets up a best-practice landing zone: the OU structure, a log-archive and an audit account, organisation-wide CloudTrail and Config, preventive controls (SCPs) and detective controls (Config rules), and ACCOUNT FACTORY to vend new accounts with a baseline (Account Factory for Terraform, AFT, does it via Terraform pipelines). IAM IDENTITY CENTER gives people single sign-on into accounts with PERMISSION SETS mapped from your identity provider's groups, with short-lived credentials and no IAM users.

03Networking at scale

VPC peering (AWS course) is one-to-one and doesn't route transitively; with 30 VPCs it becomes a mesh. TRANSIT GATEWAY is a regional hub: attach VPCs and VPNs/Direct Connect, and control who talks to whom with TGW route tables (e.g. prod can't reach dev). A shared NETWORK ACCOUNT often owns the TGW, central egress (NAT + inspection with AWS Network Firewall), and ingress. PRIVATELINK exposes one service privately to other VPCs or accounts via interface endpoints without routing whole networks together, which is also how you reach AWS services and SaaS privately. RAM (Resource Access Manager) shares subnets, TGWs, and more across accounts.

04Edge protection

AWS WAF filters HTTP requests at CloudFront, ALB, or API Gateway with managed rule groups (common vulnerabilities, known bad inputs, bot control), rate-based rules, and geo rules. SHIELD Standard (free, automatic) absorbs common network-layer DDoS; Shield Advanced adds application-layer protection, cost protection, and a response team. Manage WAF across accounts with FIREWALL MANAGER.

05Detect, record, respond

CLOUDTRAIL records every API call (an organisation trail into the log-archive account, immutable with Object Lock). AWS CONFIG records resource configuration history and evaluates rules (e.g. 'EBS volumes encrypted'). GUARDDUTY detects threats from CloudTrail, VPC Flow Logs, DNS logs, EKS audit logs, and runtime signals. INSPECTOR scans EC2, ECR images, and Lambda for vulnerabilities. MACIE finds sensitive data in S3. SECURITY HUB aggregates findings from all of them into one place with standards scores (CIS, AWS Foundational Best Practices). KMS manages encryption keys with key policies and rotation. EVENTBRIDGE routes findings to automation: open a ticket, notify the owning team, or auto-remediate (e.g. block a public bucket) with a Lambda.

Do it

Hands-on lab

An SCP that protects the security baseline

Attached to the Workloads OUs. Even account admins can't turn off logging or detection, or use unapproved regions (global services excluded).

org/scp-baseline.jsonwhole filejson

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
        "guardduty:DeleteDetector", "guardduty:DisassociateFromMasterAccount",
        "config:StopConfigurationRecorder", "config:DeleteConfigurationRecorder",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*", "budgets:*", "waf:*"],
      "Resource": "*",
      "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["ap-south-1", "ap-southeast-1"] } }
    }
  ]
}

terminal

$ aws organizations create-policy --name baseline-guardrails --type SERVICE_CONTROL_POLICY --content file://org/scp-baseline.json --query Policy.PolicySummary.Id --output text

aws organizations attach-policy --policy-id p-abcd1234 --target-id ou-ab12-workloads

── expected output ──

p-abcd1234

2
Enable GuardDuty and Security Hub organisation-wide
Delegate administration to the security account, then auto-enable for every current and future member account.
terminal
$ aws guardduty enable-organization-admin-account --admin-account-id 222222222222
aws securityhub enable-organization-admin-account --admin-account-id 222222222222
# from the security account:
aws guardduty update-organization-configuration --detector-id <id> --auto-enable-organization-members ALL
aws securityhub update-organization-configuration --auto-enable --auto-enable-standards DEFAULT
3
Route high-severity findings to the owning team
An EventBridge rule in the security account forwards GuardDuty findings with severity ≥ 7 to an SNS topic that pages security on-call. Add targets for Slack or ticketing via Lambda.
security/guardduty-high.jsonwhole filejson
```
{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [{ "numeric": [">=", 7] }] }
}
```
terminal
$ aws events put-rule --name guardduty-high --event-pattern file://security/guardduty-high.json
aws events put-targets --rule guardduty-high --targets Id=page,Arn=arn:aws:sns:ap-south-1:222222222222:security-oncall

Operate it

Knobs that matter

Setting	Default	What it does	When to change it
OU structure	flat	How accounts are grouped for policy.	Separate prod/non-prod/sandbox/security/infrastructure OUs; attach SCPs at OU level.
Permission set session duration	1 hour	SSO credential lifetime.	Short for admin sets (1h), longer for read-only (8h).
TGW route table associations	default route table	Which attachments can reach which.	Separate route tables per environment; disable default propagation for isolation.
GuardDuty protection plans	foundational only	Extra data sources (S3, EKS, runtime, RDS, Lambda, malware).	Enable EKS and runtime monitoring for Kubernetes estates.

3am practice

Failure drills

Each drill is a real failure mode. Read the scenario and the output, decide what's wrong, then reveal the diagnosis.

Drill #1

Access denied, even as admin

A team lead with AdministratorAccess in the dev account tries to launch a test instance in us-east-1.

terminal

$ aws ec2 run-instances --region us-east-1 --image-id ami-0abc... --instance-type t3.micro

── what you'll see ──

An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation. User: arn:aws:sts::333333333333:assumed-role/AWSReservedSSO_AdministratorAccess_.../lead is not authorized to perform: ec2:RunInstances ... with an explicit deny in a service control policy

Decide

Connecting VPCs

Option	Topology	Transitive routing	Best for
VPC peering	1:1	No	A few VPCs, lowest latency/cost
Transit Gateway	Hub and spoke	Yes (controlled by route tables)	Many VPCs/accounts, on-prem connectivity
PrivateLink	Service endpoint	N/A (exposes one service)	Sharing a service privately without network merging, overlapping CIDRs
VPC Lattice	Service network	Application-level	Service-to-service connectivity and auth across accounts

The bigger picture

Connects to

System Design · Multi-tenancy

Shared infrastructure, isolated tenants — the SaaS operator's architecture, with a real isolation decision.

AWS · Multi-account security baseline

The fundamentals this guide builds on.

AWS · Connecting VPCs & flow logs

Peering and Transit Gateway basics.

Terraform · Accounts & provider aliases

Managing many accounts from Terraform.

DevSecOps · Runtime detection

Detection inside workloads, complementing GuardDuty.

Prove it

Interview questions

Why use multiple AWS accounts, and how do you govern them?

Transit Gateway vs VPC peering vs PrivateLink?

Which AWS services would you enable for security visibility?

Command Palette