Well-Architected Security Pillar Deep Dive: From Design Principles to Real Controls (Azure WAF + AWS WA)

Most security reviews I get pulled into are a spreadsheet copied from a vendor PDF, run once at go-live, and never reopened. The Well-Architected Framework — Microsoft’s Azure Well-Architected Framework (WAF) and Amazon’s AWS Well-Architected Framework (WA) — offers a better contract: a security pillar that starts from how an attacker actually moves through a workload, then forces you to trace every design principle down to a control you can write in IaC and a signal you can alert on. This deep dive walks both lenses in parallel, because the principles are identical even when the service names differ, and most real estates today span both clouds.

The security pillar is not a product and not a checklist you satisfy once. It is a set of design principles plus a repeatable review method: you decompose the workload against those principles, surface risks as tradeoffs (usually against cost, operational excellence, or performance), and record decisions you can defend to an auditor and revisit when the threat model shifts. Azure expresses this as the WAF security pillar with design principles, checklists, recommendation guides, and the automated Well-Architected Review in the portal / Advisor. AWS expresses it as the WA security pillar with design principles, the Well-Architected Tool question sets, and the deep-dive Security Pillar whitepaper. Same spine, two vocabularies.

By the end you will be able to run a security design review across either cloud without hand-waving: name the design principles from memory, map each to identity, network, data, detection, infrastructure, and supply-chain controls with real config, articulate the design-review questions and the pillar tradeoffs they trigger, and produce a control matrix and checklist an assessor will accept. We treat the pillar as an operating model — assume breach, least privilege, defense in depth, automate everything, protect data end to end — and turn each abstraction into az, aws, and Terraform you can ship.

What problem this solves

The abstraction the cloud sells you — “we handle security” — is half true in a way that burns teams. The provider secures the substrate; you own identity, data, network configuration, and workload code, and the boundary moves with every service model. Nearly every breach I have reviewed lived on the customer side of a line the team assumed the provider covered: a storage bucket left public, an over-permissioned CI role, a database reachable from the internet, a secret in a Git history. The Well-Architected security pillar exists to make that boundary explicit and to give you a defensible method for filling your side of it.

What breaks without it: security becomes a point-in-time gate that a project passes and forgets. Controls are applied inconsistently across workloads, nobody can answer “what happens if this identity is compromised,” and the first real incident finds that logs were never centralized, the response runbook was never rehearsed, and the blast radius was never bounded. Teams over-invest in the visible controls (a WAF, a firewall) and under-invest in the ones that actually stop lateral movement (least-privilege identity, network segmentation, key custody). A design review that produces a slide deck instead of Terraform and alerts has changed nothing.

Who hits this: every team shipping to Azure or AWS, but hardest on those running regulated or multi-tenant workloads, those spanning both clouds (where “we do it this way in Azure” doesn’t translate), and platform teams who must set guardrails that dozens of app teams inherit. The pillar’s payoff is a workload where identity is the perimeter, the network shrinks blast radius, data is protected proportional to its classification, detection is instrumented and rehearsed, and every control is code that a pipeline enforces and an auditor can inspect.

Here is the whole pillar in one frame — the design principles, what each demands in practice, and the primary control plane on each cloud:

Learning objectives

By the end of this article you can:

• Recite the Azure WAF and AWS WA security-pillar design principles and map each to concrete identity, network, data, detection, infrastructure, and supply-chain controls on both clouds.
• Draw the shared responsibility boundary for IaaS/PaaS/SaaS and name which concerns never leave the customer’s side.
• Treat identity as the perimeter: kill standing privilege with PIM / short-lived roles, enforce phishing-resistant MFA via Conditional Access / IAM policy conditions, and give workloads managed identities / IAM roles instead of secrets.
• Design network segmentation and defense in depth: NSG/Security-Group default-deny, Azure Firewall / AWS Network Firewall egress inspection, Private Endpoint / PrivateLink, and WAF+DDoS at the edge.
• Make the data-protection decisions: classification, encryption at rest and in transit, and the platform-key vs customer-managed-key vs HSM key-custody tradeoff on Key Vault / KMS / CloudHSM.
• Build detection and incident response: centralize logs, write detections as queries, wire automated remediation, and rehearse a runbook.
• Embed security in the SDLC and supply chain: secret scanning, IaC static analysis, dependency/CVE gates, image signing, and management-group / SCP guardrails.
• Run a security design review: ask the pillar’s review questions, reason about the tradeoffs against the other four pillars, and produce a control matrix and checklist.

Prerequisites & where this fits

You should be comfortable with cloud fundamentals on at least one of Azure or AWS: what a subscription/account, resource group, VNet/VPC, and IAM/RBAC role are; how to run az, aws, and terraform; and how to read JSON/HCL. Familiarity with HTTP, TLS, and basic threat-modeling vocabulary (trust boundary, attack path) helps. You do not need to be a security specialist — this article is written for the architect who owns the design and must defend it.

This is the security pillar of a five-pillar framework, and it does not stand alone. It trades against the other four constantly, so read it alongside the Well-Architected Reliability Pillar Deep Dive, the Well-Architected Operational Excellence Pillar Deep Dive, and the Well-Architected Performance Efficiency Pillar Deep Dive. For the mechanics behind individual controls, it draws on Threat Modeling with STRIDE, Data-Flow Diagrams & Attack Trees, the Zero Trust Architecture Blueprint: Identity, Network & Data, and cloud-specific deep dives linked throughout. The Azure-native expression of this pillar lives in Azure Well-Architected Framework: Security Pillar; the AWS-native one in AWS Well-Architected: Security Pillar.

Where it fits in the review flow: you scope a workload, run the pillar’s questions, capture risks and their tradeoffs, and turn the accepted decisions into IaC and alerts. The two clouds’ tooling maps cleanly:

Core concepts

Six mental models make every control below obvious. Pin them before the deep sections.

Security is a pillar, not a phase. The Well-Architected security pillar is a lens you apply continuously, not a gate you pass. Its output is a set of decisions — each with a rationale and an accepted tradeoff — recorded so they can be defended and revisited. A review that ends in a document nobody enforces has produced nothing; a review that ends in Terraform, policy, and alerts has changed the system.

Identity is the perimeter. The network used to be the boundary; now the boundary is “who are you and are you allowed.” Every request should be authenticated and authorized on identity, evaluated against context (device, location, risk), and granted the minimum privilege for the minimum time. The classic breach chain — phished credential → over-permissioned identity → data — is broken at the identity layer far more cheaply than anywhere downstream.

Defense in depth means no single failure is fatal. You apply controls at every layer — edge (WAF/DDoS), network (segmentation), host, application, identity, and data — so that breaking one gets an attacker nowhere near the crown jewels. The network is not obsolete under zero trust; it is a layer that shrinks blast radius and buys detection time, sitting behind identity, not instead of it.

Classify before you protect. You cannot apply the right protection until you know the sensitivity. Classify data — public, internal, confidential, restricted — then let the tier drive the encryption and, crucially, the key custody decision: who can destroy access to this data? Over-protecting public data wastes money and operational pain; under-protecting restricted data is the breach.

Assume breach. Design as if an attacker is already inside. That single assumption reorders your investments toward detection, blast-radius containment, least privilege, and rehearsed response — and away from the fantasy of a perfect perimeter. “How fast do we see it and how much of the response runs without a human” becomes the operative question.

Automate everything: controls, remediation, evidence. Controls applied by hand drift, apply inconsistently, and produce no audit trail. Controls as code (IaC + policy) apply uniformly, are reviewed in pull requests, and are themselves the evidence. Remediation as code (deployIfNotExists / auto-remediation) closes the gap between detection and fix. This is where the pillar stops being aspirational.

The vocabulary in one table

Before the deep sections, the moving parts side by side. The glossary repeats these for lookup:

The design principles, made concrete

Both frameworks publish a short list of security design principles. They read as platitudes until you attach a control, a config line, and a tradeoff to each. This section does exactly that — it is the pillar’s spine, and every later section elaborates one row.

Azure WAF vs AWS WA security principles, aligned

The two lists use different words for the same ideas. Aligning them means one review method covers both clouds:

The practical reading: plan readiness = identity + governance baseline; protect the CIA triad as three explicit design goals; apply controls at every layer; automate; and keep humans out of the data path. Whichever cloud, the review walks these.

Principle-to-control map

The single most useful artifact from a review is a table that turns each principle into a specific control on each cloud. Keep this open during design:

The tradeoffs each principle triggers

No security control is free; the pillar’s honesty is that it names the cost. A review that pretends otherwise loses credibility with the app teams who feel the friction:

Identity: the primary perimeter

Identity is where defense in depth starts because it holds the cheapest, highest-leverage controls. Three moves, in order, on both clouds.

Kill standing privilege

Human administrative access should be just-in-time and approved, not a permanent role assignment sitting idle waiting to be phished. On Azure, that is Privileged Identity Management (PIM): assign roles as eligible, so elevation requires explicit activation, MFA, a justification, and optionally approval.

# Azure: make an ELIGIBLE (not active) role assignment; activation is governed by PIM policy
# (MFA + approval + time-bound) so the role is dormant until explicitly elevated.
az role assignment create \
  --assignee "$PRINCIPAL_ID" \
  --role "Contributor" \
  --scope "/subscriptions/$SUB_ID/resourceGroups/rg-prod-app" \
  --assignee-principal-type User
# Then configure the PIM role setting in Entra: eligible assignment, max 8h activation,
# require MFA + justification + approver group.

On AWS, the equivalent is IAM Identity Center with short-lived permission sets (session-scoped credentials, no long-lived keys) plus optional approval workflows, and no IAM users with attached admin policies:

# AWS: users assume a permission set for a bounded session; credentials are short-lived and
# vended by Identity Center. No standing IAM user with AdministratorAccess exists.
aws sso-admin create-account-assignment \
  --instance-arn "$SSO_INSTANCE_ARN" \
  --target-id "$ACCOUNT_ID" --target-type AWS_ACCOUNT \
  --permission-set-arn "$PERMSET_ARN" \
  --principal-type GROUP --principal-id "$GROUP_ID"
# Session duration on the permission set caps how long the elevated creds live.

The two models, side by side:

Enforce phishing-resistant MFA on context

Require strong authentication for privileged access and evaluate it against context. On Azure, Conditional Access is the enforcement plane; scope policies to role templates, not named users (people change, roles do not):

{
  "displayName": "Require phishing-resistant MFA for admins",
  "state": "enabled",
  "conditions": {
    "users": { "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"] },
    "applications": { "includeApplications": ["All"] }
  },
  "grantControls": {
    "operator": "OR",
    "authenticationStrength": { "id": "00000000-0000-0000-0000-000000000004" }
  }
}

The role GUID 62e90394-... is the built-in Global Administrator template ID; it is stable across every tenant. authenticationStrength id ...0004 is the built-in phishing-resistant MFA strength. Also create a policy that blocks legacy authentication — it bypasses MFA entirely and is the single most common gap.

On AWS you achieve the analog with IAM policy conditions (deny actions unless MFA is present) and, for the console/SSO, mandatory MFA in Identity Center. A representative “deny if not MFA-authenticated” boundary:

{
  "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "sts:GetSessionToken"],
  "Resource": "*",
  "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } }
}

Give workloads identities, not secrets

Application code should never hold a connection string or long-lived key. On Azure, use a managed identity and grant it a tightly scoped RBAC role:

# Azure: system-assigned identity, scoped to READ SECRETS from ONE Key Vault.
az webapp identity assign --name app-prod --resource-group rg-prod-app
PRINCIPAL=$(az webapp identity show -n app-prod -g rg-prod-app --query principalId -o tsv)
az role assignment create \
  --assignee-object-id "$PRINCIPAL" --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope "/subscriptions/$SUB_ID/resourceGroups/rg-prod-app/providers/Microsoft.KeyVault/vaults/kv-prod-app"

On AWS, the equivalent is an IAM role attached to the compute (an EC2 instance profile, an ECS task role, a Lambda execution role, or an EKS IRSA / Pod Identity), scoped to exactly the resources it needs:

# AWS: an ECS task role that can read ONE secret and nothing else.
resource "aws_iam_role" "task" {
  name               = "app-prod-task"
  assume_role_policy = data.aws_iam_policy_document.ecs_assume.json
}
resource "aws_iam_role_policy" "read_one_secret" {
  role   = aws_iam_role.task.id
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect   = "Allow",
      Action   = ["secretsmanager:GetSecretValue"],
      Resource = aws_secretsmanager_secret.db.arn   # one secret, not "*"
    }]
  })
}

The habit that closes the most attack paths: narrowest role, narrowest scope, no wildcards. Key Vault Secrets User on one vault — not Contributor on the resource group; GetSecretValue on one ARN — not secretsmanager:* on *. For CI/CD, go one step further and eliminate the stored cloud credential entirely with OIDC federation (see Workload Identity Federation for Secretless CI/CD). The identity anti-patterns to hunt and kill:

Network segmentation and defense in depth

Even with identity as the primary perimeter, the network is a control layer you do not skip — it shrinks blast radius and buys detection time. The goal: nothing in the data tier is reachable from the internet, and lateral movement inside the network is denied by default.

Take data services off the public internet

PaaS data services default to public endpoints. Close them with Private Endpoints (Azure) / PrivateLink or VPC endpoints (AWS) and explicitly disable public access:

# Azure: storage with NO public endpoint, reachable only via Private Endpoint, TLS 1.2 min.
resource "azurerm_storage_account" "data" {
  name                          = "stproddata01"
  resource_group_name           = azurerm_resource_group.app.name
  location                      = azurerm_resource_group.app.location
  account_tier                  = "Standard"
  account_replication_type      = "ZRS"
  public_network_access_enabled = false          # no public endpoint
  min_tls_version               = "TLS1_2"
}

resource "azurerm_private_endpoint" "blob" {
  name                = "pe-stproddata01-blob"
  resource_group_name = azurerm_resource_group.app.name
  location            = azurerm_resource_group.app.location
  subnet_id           = azurerm_subnet.private_endpoints.id
  private_service_connection {
    name                           = "psc-blob"
    private_connection_resource_id = azurerm_storage_account.data.id
    subresource_names              = ["blob"]
    is_manual_connection           = false
  }
}

On AWS, the analog is a gateway or interface VPC endpoint plus a bucket policy that denies any access not arriving through it:

# AWS: deny all S3 access that does NOT come through the designated VPC endpoint.
data "aws_iam_policy_document" "bucket" {
  statement {
    effect    = "Deny"
    actions   = ["s3:*"]
    resources = [aws_s3_bucket.data.arn, "${aws_s3_bucket.data.arn}/*"]
    principals { type = "*" identifiers = ["*"] }
    condition {
      test     = "StringNotEquals"
      variable = "aws:sourceVpce"
      values   = [aws_vpc_endpoint.s3.id]
    }
  }
}

The private-connectivity primitives compared:

Micro-segment with default-deny

The most common mistake is allowing the whole address space east-west. Deny it, then allow only the specific tier-to-tier flow. On Azure, that is NSG rules; the deny rule at a high priority number is the backstop:

# Azure: app subnet may reach data subnet ONLY on 1433; all other east-west inbound denied.
az network nsg rule create -g rg-prod-app --nsg-name nsg-data \
  --name allow-app-to-sql --priority 100 --direction Inbound --access Allow \
  --protocol Tcp --source-address-prefixes 10.20.1.0/24 \
  --destination-port-ranges 1433 --destination-address-prefixes 10.20.2.0/24

az network nsg rule create -g rg-prod-app --nsg-name nsg-data \
  --name deny-vnet-inbound --priority 4000 --direction Inbound --access Deny \
  --protocol "*" --source-address-prefixes VirtualNetwork \
  --destination-port-ranges "*" --destination-address-prefixes "*"

On AWS the layered equivalent is Security Groups (stateful, instance-level, allow-only) plus NACLs (stateless, subnet-level, allow+deny) — the deep mechanics are in AWS Security Groups & NACLs Deep Dive. A security group that lets the app tier reach the DB tier and nothing else:

# AWS: DB security group accepts 5432 ONLY from the app tier's security group.
resource "aws_security_group_rule" "db_from_app" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.db.id
  source_security_group_id = aws_security_group.app.id   # reference, not a CIDR
}

The segmentation primitives are close but not identical — knowing the differences prevents porting a rule incorrectly:

Layer the edge and inspect egress

Put a WAF at the edge in Prevention/Block mode (Azure Front Door or Application Gateway WAF; AWS WAF on CloudFront/ALB) and enable a DDoS protection plan on internet-facing entry points (Azure DDoS Network/IP Protection; AWS Shield Advanced). Beyond ingress, control egress: an Azure Firewall or AWS Network Firewall with FQDN allow-listing stops a compromised workload from exfiltrating to an attacker’s server. The full layered picture — an attacker must defeat every layer, and each layer generates telemetry:

Layering matters because it decouples failures: breaking the WAF gets an attacker to a subnet that denies east-west; landing in the app subnet finds a data tier reachable only via private endpoint over TLS with data-plane RBAC still to defeat. For remote administration, never expose RDP/SSH — use Azure Bastion or AWS SSM Session Manager so management ports have no public listener at all.

Data protection: classification, encryption, key custody

You cannot apply the right protection until you know the sensitivity. Classify first — public, internal, confidential, restricted — then let the tier drive the encryption and key-custody decision.

Encryption at rest and in transit

Encryption at rest and TLS in transit are table stakes and largely on by default on both clouds (Azure Storage/SQL Service-Managed Keys; AWS S3/EBS/RDS with default encryption). The work is (a) enforcing a minimum TLS version, (b) ensuring nothing was created unencrypted, and © choosing key custody. The mechanisms compared:

The key-custody decision

The real decision is who can destroy access to the data. This is the pillar’s “protect confidentiality” principle turned into a concrete tradeoff against reliability and cost:

For restricted data, wire CMK with an enforced rotation policy and — non-negotiably — protect the key store from accidental destruction. On Azure:

# Azure: create a CMK with an enforced rotation policy.
az keyvault key create --vault-name kv-prod-app --name cmk-storage \
  --protection software --kty RSA --size 3072
az keyvault key rotation-policy update --vault-name kv-prod-app --name cmk-storage \
  --value '{"lifetimeActions":[{"trigger":{"timeAfterCreate":"P350D"},
            "action":{"type":"Rotate"}}],"attributes":{"expiryTime":"P365D"}}'

On AWS, KMS gives you managed annual rotation and key policies that constrain who can use versus administer the key:

# AWS: a customer-managed KMS key with automatic annual rotation and a scoped policy.
resource "aws_kms_key" "data" {
  description             = "CMK for restricted data"
  enable_key_rotation     = true          # annual rotation of backing material
  deletion_window_in_days = 30            # window to cancel an accidental delete
  policy                  = data.aws_iam_policy_document.kms.json
}

The kill switch is a loaded gun. CMK/HSM gives you crypto-shred: revoke or destroy the key and the ciphertext is unrecoverable even though it still sits in storage. Powerful — and a self-inflicted denial-of-service waiting to happen. On Azure, --enable-purge-protection true and soft-delete on the vault are mandatory for production CMK. On AWS, a key deletion window (7–30 days) is your grace period; treat KMS key availability as a reliability dependency of every dataset it protects, and replicate keys for multi-region data.

The custody deep dives are worth reading in full: Azure Encryption at Rest with CMK & Double Encryption and AWS KMS Encryption Deep Dive: Keys, Policies, Envelope, Rotation.

Secrets are data too

Application secrets follow the same discipline as data: store in a managed vault, reference (never copy) from the app, rotate on a schedule, and prefer a workload identity over any secret at all. On Azure that is Azure Key Vault: Secrets, Keys & Certificates with managed-identity references; on AWS it is Secrets Manager / Parameter Store with an IAM role. The secret-handling rules and their cross-cloud form:

Detection and incident response: assume breach

Assume breach. The question is not whether something gets through but how fast you see it and how much of the response runs without a human. Centralize telemetry, write detections as queries, and codify the response.

Centralize the telemetry

Ship control-plane, data-plane, identity, and network logs into one place. On Azure that is a Log Analytics workspace (via diagnostic settings) feeding Microsoft Sentinel; on AWS it is CloudTrail + service logs feeding Security Lake / a SIEM, with GuardDuty and Security Hub providing managed detections and posture. The telemetry sources you must not skip:

Detections as queries

Promote the high-signal patterns to analytics rules that create incidents. A detection I keep in every Azure environment — a risky sign-in immediately followed by a privileged role grant, because that pattern is the attack path:

// Azure Sentinel: risky sign-in followed by a privileged role assignment within 30 min
let risky = SigninLogs
  | where RiskLevelDuringSignIn in ("high","medium")
  | project riskUser = UserPrincipalName, riskTime = TimeGenerated, IPAddress;
AuditLogs
  | where OperationName has "Add member to role"
  | extend actor = tostring(InitiatedBy.user.userPrincipalName)
  | join kind=inner risky on $left.actor == $right.riskUser
  | where TimeGenerated between (riskTime .. (riskTime + 30m))
  | project TimeGenerated, actor, OperationName, IPAddress, TargetResources

The AWS analog watches CloudTrail for the same shape — a session from an unusual context calling AttachRolePolicy/PutRolePolicy or creating access keys. For the hunting discipline behind these queries, see KQL Threat Hunting: MITRE ATT&CK, UEBA & Notebooks.

Automated remediation for the unambiguous cases

Wire auto-remediation for findings with no judgment call — a publicly exposed storage bucket, a disabled encryption setting, a security group opened to 0.0.0.0/0 on 22. On Azure, Azure Policy with Deny or deployIfNotExists:

# Azure: enforce that storage restricts network access (run Audit first, then Deny).
az policy assignment create \
  --name "restrict-storage-network" \
  --policy "4fa4b6c0-31ca-4c0d-b10d-24b96f62a751" \
  --scope "/subscriptions/$SUB_ID" \
  --params '{"effect":{"value":"Audit"}}'   # flip to Deny after sizing the blast radius

Built-in policy 4fa4b6c0-... is “Storage accounts should restrict network access.” Run it as Audit for a sprint to size the blast radius, then flip to Deny. Shipping straight to Deny on a brownfield estate is how you take down production on a Friday. On AWS the equivalent is an AWS Config rule with an SSM auto-remediation, or an SCP that denies the misconfiguration outright.

The runbook automation cannot replace

Then write the runbook for what automation cannot decide: who declares the incident, how you preserve forensic snapshots, the comms tree, containment vs eradication, the rollback. A playbook nobody has rehearsed is a document, not a control — run a game day against it quarterly. The incident lifecycle and the tooling on each cloud:

For the full method, see Security Incident Response: Runbooks, Tabletops & Cloud Forensics.

Infrastructure protection and posture management

Infrastructure protection is the “apply security at all layers” principle applied to the compute and platform layer: harden hosts, patch continuously, reduce the attack surface, and measure posture over time so drift is visible.

Harden and patch

The controls that matter at the infrastructure layer, and where each lives:

Posture as a scored trend

Both clouds give you a security score that trends your posture: Microsoft Defender for Cloud Secure Score and AWS Security Hub (with foundational standards like CIS and AWS FSBP). Treat the score as a backlog generator, not a vanity metric — each finding is a specific, prioritized fix. The posture toolchain:

The pillar’s job is to make sure the score trends up and the top findings are on someone’s board. The platform-team baseline for Azure is Azure Landing Zone: Security; for AWS, AWS Control Tower Multi-Account Landing Zone.

Secure SDLC and software supply chain

Controls applied after deploy are remediation; controls applied in the pipeline are prevention. Shift every check left so insecure config and leaked secrets never reach an environment, and secure the supply chain so what you ship is what you built.

Gate the pipeline

A minimal but real gate set in CI — secret scanning, IaC static analysis, and dependency CVE checks — that fails the build on a finding:

# CI (GitHub Actions / Azure DevOps): hard gates before any deploy stage.
steps:
  - name: Secret scan
    run: gitleaks detect --source . --redact --exit-code 1

  - name: IaC static analysis
    run: |
      checkov -d ./infra --quiet --compact \
        --framework terraform \
        --soft-fail-on LOW        # fail build on MEDIUM/HIGH misconfig

  - name: Dependency + image CVEs
    run: trivy fs --severity HIGH,CRITICAL --exit-code 1 .

Secure the artifact and its provenance

Beyond the gate, the supply chain itself must be trustworthy: pin and scan base images, generate an SBOM, sign artifacts, and admit only signed images at deploy. The supply-chain controls and their cross-cloud form:

For the depth on consuming a trustworthy supply chain, see Software Supply Chain: SBOM, VEX & Admission Verification and the pipeline pattern in Secure CI/CD Supply Chain: Jenkins, Vault & Wiz.

Governance: guardrails, not gates

Pipeline gates catch what flows through the pipeline. Governance guardrails catch what does not — the resource someone clicks up in the portal, the account a team spins outside your templates. The pillar’s “automate” and “sustain your posture” principles demand both: preventive guardrails at the org boundary, plus detective guardrails that flag drift.

Preventive vs detective guardrails

On Azure, Azure Policy at the management-group scope enforces rules on every resource regardless of how it was created; on AWS, Service Control Policies (SCPs) at the Organization/OU level set the outer boundary, with AWS Config as the detective layer. The two models:

The critical property of both: they apply at the control plane, so a resource created outside your pipeline still cannot violate the rule. Defense in depth applies to your governance, not just your runtime — pipeline catches it pre-merge, policy/SCP catches it at creation. For the effect model, see Azure Policy Effects Explained: Deny, Audit, Modify, deployIfNotExists.

The governance operating model

Governance is not a one-time policy push; it is an operating model with roles and a feedback loop:

Architecture at a glance

Read the reference architecture as concentric defense-in-depth: an attacker at the internet must defeat every layer, and every layer emits telemetry to a central detection plane while a governance plane enforces the whole thing as code.

Start at the public edge: internet traffic hits Front Door + WAF in Prevention mode with a DDoS plan on the internet-facing VNet — this handles the availability/DoS and L7-attack design goals before anything reaches your network. Behind it sits the identity foundation — Entra ID with Conditional Access, PIM for just-in-time admin, and managed identity for workloads — because every request is authorized on identity, not network position. Inside the network, the application tier lives in a VNet subnet governed by an NSG default-deny posture, permitted to reach only the next tier on the exact port. The data tier is fully private: Private Endpoints with public access disabled, data encrypted with Key Vault CMK, TLS 1.2 enforced, and data-plane RBAC still required even after the network is defeated. Cutting across all of it, a detection plane — Log Analytics, Sentinel analytics rules, and automated remediation — ingests control-plane, identity, network, and data telemetry and turns high-signal patterns into incidents and sub-minute containment. Governing everything, a policy plane (Azure Policy / SCP at the org scope) enforces the rules at the control plane so nothing drifts back. The AWS lens maps one-for-one: CloudFront+WAF+Shield at the edge, IAM/Identity Center as the foundation, Security Groups+Network Firewall for segmentation, PrivateLink+KMS for the private data tier, GuardDuty+Security Hub+CloudTrail for detection, and SCPs+Config for governance.

Real-world scenario

A platform team I worked with — call them Meridian Health — ran a regulated multi-tenant SaaS on AKS with a parallel analytics footprint on AWS. Their constraint was hard and auditor-driven: a compliance mandate required that no human could read tenant data at rest, they had to prove it to an assessor, and yet engineers still needed break-glass access to the cluster during incidents. The naive read — lock everyone out — was incompatible with operating the system at 2 a.m. during an outage. Their initial WAF/WA review scored badly on exactly the “keep people away from data” and “least privilege” principles, and the finding was flagged as a high-risk issue (HRI).

The resolution separated cluster access from data access using two different key custodies. Tenant data used CMK in a Managed HSM to which no human principal held unwrapKey rights — only the application’s managed identity held that permission. Engineers kept break-glass to the AKS control plane through PIM (eligible, MFA, approver-gated, 4-hour max), but that path could reach pods, not plaintext: the data stayed encrypted under a key humans literally could not use. Break-glass activation also fired a Sentinel analytics rule, so every human elevation generated an audited incident with a justification attached.

# Only the workload identity can unwrap; the break-glass admin group gets NO crypto role.
az keyvault role assignment create --hsm-name mhsm-prod \
  --role "Managed HSM Crypto User" \
  --assignee-object-id "$APP_IDENTITY_OID" \
  --scope "/keys/cmk-tenant-data"
# The engineer break-glass group is intentionally granted no crypto role on this key.

On the AWS analytics side they mirrored the pattern with a customer-managed KMS key whose key policy granted kms:Decrypt only to the analytics job’s IAM role, denied it to every human principal via an explicit Deny on the human SSO role ARNs, and logged every Decrypt to CloudTrail. The data lake buckets denied any access not arriving through the VPC endpoint, and GuardDuty watched for anomalous S3 access patterns.

The outcome the auditor accepted: the question “show me a human who can decrypt tenant data” returned nobody on both clouds, while on-call retained the access to run the platform. Cost impact was modest and defensible — Managed HSM plus a handful of KMS keys, a few private endpoints, and Sentinel/GuardDuty ingestion — roughly ₹85,000–1,10,000/month across both footprints, dominated by the HSM and log ingestion, which the mandate fully justified. The HRI closed, both posture scores trended up, and the review became a quarterly ritual rather than a go-live gate. That is the security pillar working as designed: least privilege and assume breach turned into a key-custody boundary and an audited break-glass path, not a slide.

Advantages and disadvantages

The security pillar is not free, and pretending otherwise is how you lose the room. The honest ledger:

When each side matters: the advantages dominate for anything holding regulated, personal, or financial data, or any internet-facing multi-tenant system — there the cost of a breach dwarfs the friction and spend. The disadvantages bite hardest on early-stage internal tools where the data is low-sensitivity and velocity is everything; there you still do the cheap, high-leverage controls (identity, no public data, centralized logs) and defer the expensive ones (HSM, deep packet inspection, full-fidelity SIEM) until the data classification justifies them. The pillar’s discipline is matching control cost to data sensitivity — which is why classification comes first.

Hands-on lab

Run a mini security design review against a two-tier workload and prove three controls on Azure, all free-tier-friendly. You will confirm no standing privilege, prove a data service is private, and prove a CMK vault cannot be silently destroyed. Run in Cloud Shell (Bash). (The AWS analog commands are noted for reference; do the Azure path to keep it free-tier.)

Step 1 — Variables and resource group.

RG=rg-secpillar-lab
LOC=centralindia
SUB_ID=$(az account show --query id -o tsv)
az group create -n $RG -l $LOC -o table

Step 2 — Prove there are no standing privileged assignments at subscription scope. This is the first review question in code:

az role assignment list --all --scope "/subscriptions/$SUB_ID" \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor'].{principal:principalName, role:roleDefinitionName, scope:scope}" \
  -o table
# Review finding: any human Owner/Contributor here should be PIM-eligible, not permanent.

Step 3 — Create a storage account with public access disabled and TLS 1.2 (private-by-default).

ST=stseclab$RANDOM
az storage account create -n $ST -g $RG -l $LOC \
  --sku Standard_LRS --min-tls-version TLS1_2 --public-network-access Disabled -o table

Step 4 — Prove the public endpoint is actually closed. Do not trust the intent; verify:

az storage account show -n $ST -g $RG \
  --query "{public:publicNetworkAccess, tls:minimumTlsVersion}" -o table
# Expect: public=Disabled, tls=TLS1_2

Step 5 — Create a Key Vault with soft-delete and purge protection (no silent kill switch).

KV=kvseclab$RANDOM
az keyvault create -n $KV -g $RG -l $LOC \
  --enable-purge-protection true --retention-days 7 -o table

Step 6 — Prove purge protection is on. This is the control that stops a CMK kill switch from becoming your own outage:

az keyvault show -n $KV \
  --query "{purge:properties.enablePurgeProtection, softDelete:properties.enableSoftDelete}" -o table
# Expect: purge=true, softDelete=true

Step 7 — Turn on a detective governance guardrail (Audit mode). Assign the “storage restricts network access” policy in Audit so drift is flagged without breaking anything:

az policy assignment create \
  --name seclab-restrict-storage \
  --policy "4fa4b6c0-31ca-4c0d-b10d-24b96f62a751" \
  --scope "/subscriptions/$SUB_ID/resourceGroups/$RG" \
  --params '{"effect":{"value":"Audit"}}' -o table

Validation checklist. You ran three review questions as code and got defensible answers: no un-governed standing admin at the scope, a data service with its public endpoint provably closed and TLS floored at 1.2, and a key store that cannot be silently purged — plus a detective guardrail watching for drift. What each step proved:

AWS analog (reference). The mirror is: aws iam list-policies + Access Analyzer for standing privilege; aws s3api put-public-access-block + a deny-non-VPCE bucket policy for private data; a customer-managed KMS key with a 30-day deletion window for the kill-switch grace period; and an AWS Config rule (s3-bucket-public-read-prohibited) as the detective guardrail.

Cleanup.

az group delete -n $RG --yes --no-wait
# Purge-protected vaults are recoverable but not permanently deletable until retention lapses — expected.

Cost note. LRS storage and a standard Key Vault are a few rupees; an hour of this lab is well under ₹20. The purge-protected vault lingers in soft-deleted state until the 7-day retention lapses — that is the control working, not a leak.

Common mistakes & troubleshooting

The failure modes I see most in real security reviews — symptom, root cause, how to confirm, and the fix. Bookmark the table; read the prose once.

The three that cause the most damage, expanded:

3. Public data-plane exposure. The most common serious finding, and the one an attacker’s scanner finds in minutes. It is not just storage — managed SQL, Cosmos/DynamoDB, Redis, and search all default to public endpoints. Confirm with publicNetworkAccess/public-access-block per service; fix by disabling public access and reaching the service via Private Endpoint / PrivateLink with private DNS. This is the single control that closes the classic “public bucket → dump everything” incident.

7. CMK availability as a reliability landmine. Customer-managed keys give you crypto-shred as a kill switch — and a way to lose your own data forever. On Azure, a production CMK vault without enablePurgeProtection can be soft-deleted and then purged, and the data it protected becomes unrecoverable. On AWS, scheduling a KMS key deletion with a short window (or an accidental disable) breaks every dataset using it. Confirm purge protection / deletion window; treat key availability as a hard reliability dependency, replicate keys for multi-region data, and never let a human hold the only path to unwrapKey/Decrypt for restricted data without a tested recovery.

11–12. Governance that only lives in the pipeline. A pipeline gate is necessary but not sufficient: it catches nothing created outside the pipeline. The portal, a rogue script, or a new account will happily create a public bucket the pipeline never saw. Preventive guardrails at the org boundary (Azure Policy Deny at management group, SCP Deny at OU) enforce at the control plane so it cannot happen regardless of origin — but ship them via Audit first on a brownfield estate, remediate the surfaced violations, and only then flip to Deny, or you convert a governance win into a Friday-night outage.

Best practices

• Classify data first, then match control cost to sensitivity. Every downstream decision — encryption, key custody, network isolation, logging fidelity — flows from the classification. Do the cheap high-leverage controls everywhere; reserve HSM, deep inspection, and full-fidelity SIEM for restricted data.
• Make identity the perimeter. No standing privileged access (PIM-eligible / short-lived roles), phishing-resistant MFA on context via Conditional Access / IAM conditions, legacy auth blocked, and workloads on managed identities / IAM roles — never secrets.
• Narrowest role, narrowest scope, zero wildcards. Secrets User on one vault, GetSecretValue on one ARN. Wildcard actions or subscription/account-wide data roles are findings, not shortcuts.
• Take data planes off the internet. Private Endpoint / PrivateLink with public access disabled and TLS 1.2 minimum on every sensitive data service, with private DNS to match.
• Default-deny east-west. Segment by role; allow only explicit tier-to-tier flows. WAF in Prevention and a DDoS plan on internet-facing entry points; egress inspection for exfiltration.
• Own your keys deliberately. CMK/HSM for restricted data with enforced rotation, soft-delete/purge protection (Azure) or a sane deletion window (AWS), and key HA treated as a reliability dependency.
• Centralize telemetry before you need it. Control-plane, identity, network, and data logs into one workspace/lake; high-signal patterns promoted to analytics rules that create incidents.
• Automate remediation for the unambiguous, runbook the judgment calls. Auto-fix public buckets and disabled encryption; write and rehearse the runbook for containment, forensics, comms, and rollback.
• Gate the pipeline and secure the supply chain. Secret scanning, IaC static analysis, and CVE gates that fail the build; sign artifacts and admit only signed, scanned images.
• Enforce guardrails at the control plane. Azure Policy Deny at management group / SCP Deny at OU so the portal and rogue scripts cannot violate the standard — audit first on brownfield.
• Trend your posture and own the backlog. Secure Score / Security Hub score with a named owner; top findings become a sprint, not a slide.
• Run the pillar as a recurring review, not a go-live gate. Re-run the questions when the threat model shifts, record decisions and their tradeoffs, and game-day the response quarterly.

Security notes

The pillar is the security notes, but a few controls guard the security machinery itself:

• Protect the audit trail. Central logs are an attacker’s first target — an intruder who can delete CloudTrail or the Log Analytics workspace erases their tracks. Make the trail immutable and cross-account/subscription: an AWS Organization trail with S3 Object Lock and a separate log-archive account; a Log Analytics workspace in a locked-down subscription with delete-protection and RBAC that no workload identity holds.
• Break-glass accounts, excluded and monitored. Keep two emergency accounts excluded from Conditional Access / SSO dependencies so a misconfigured policy or IdP outage cannot lock you out — but alert on every use, store the credentials offline, and review them after any incident.
• Least privilege on the security tooling itself. The identity that runs auto-remediation, the SIEM’s data connectors, and the posture scanner all need scoped, audited access — not Owner. A compromised remediation identity is a control that now works for the attacker.
• Don’t leak internals through detection endpoints. Health, metrics, and status endpoints return status, never topology, versions, or dependency hostnames — those are reconnaissance gifts.
• Guard the key vault as the crown jewel. Vault/KMS access is the master control over all encrypted data; put it behind RBAC (not sprawling access policies), enable firewall + trusted-services, log every key operation, and separate use (unwrapKey/Decrypt) from administer so no single role does both.
• TLS everywhere, always. Enforce HTTPS-only and a minimum TLS version; a security review is no excuse to disable TLS “temporarily.” Prefer mTLS for service-to-service on integrity-critical paths.

Cost & sizing

The security bill has a few big drivers, and the pillar’s discipline is spending on them in proportion to data sensitivity — not uniformly.

• Log ingestion dominates variable cost. Sentinel / Log Analytics and AWS SIEM/Security Lake bill per GB ingested and retained. Full-fidelity logging of a high-traffic estate can run tens of thousands of rupees a month. Tier it: hot retention for active detection, cheap archive for compliance; sample verbose sources; and never log secrets. Budget roughly ₹8,000–40,000/month for a mid-size estate depending on traffic and retention.
• Key custody is a step function. Platform-managed keys are free. Customer-managed keys in Key Vault / KMS are a few rupees per key per month plus per-operation charges — negligible. Managed HSM / CloudHSM is the jump: a dedicated HSM runs on the order of ₹1,00,000+/month, so reserve it for data with an explicit FIPS 140-2 L3 or crypto-erase mandate.
• Private connectivity has a per-endpoint cost. Private Endpoints / interface VPC endpoints bill hourly plus per-GB — small individually, but they add up across dozens of services. Reserve private endpoints for sensitive data planes; a shared/hub pattern amortizes them.
• Defender / GuardDuty / Security Hub plans are per-resource or per-event and cheap relative to a breach — enable them on production; they are the detection you cannot retrofit mid-incident.
• Deep packet inspection (Azure Firewall / Network Firewall) carries an hourly + per-GB-processed charge and adds latency; scope it to egress and north-south, skip low-risk east-west.

A rough monthly picture for a mid-size regulated workload on one cloud: Defender/GuardDuty + Security Hub (~₹5,000–15,000), Sentinel/SIEM ingestion (~₹8,000–30,000), a handful of CMK keys (~₹500), 10–20 private endpoints (~₹5,000–10,000), and a firewall for egress (~₹15,000–30,000) — call it ₹35,000–90,000/month, with Managed HSM adding ₹1,00,000+ only if the mandate requires it. The cost drivers and what each buys:

Interview & exam questions

1. What are the design principles of the Well-Architected security pillar, and do Azure and AWS agree? Both frameworks converge on: a strong identity foundation, least privilege, defense in depth (security at all layers), protecting data in transit and at rest, keeping people away from data, detecting and responding (assume breach), automating security, and preparing for events. Azure frames some as protecting the CIA triad (confidentiality/integrity/availability) as explicit design goals; the intent is identical.

2. Why is “identity is the perimeter” the starting point, and what three moves implement it? Because the cheapest, highest-leverage place to break an attack chain is before it reaches the network or data. The three moves: kill standing privilege (PIM-eligible / short-lived roles), enforce phishing-resistant MFA on context (Conditional Access / IAM conditions, block legacy auth), and give workloads managed identities / IAM roles instead of secrets — narrowest role, narrowest scope.

3. Explain the key-custody decision and its tradeoff. Platform-managed keys mean the provider holds them (fine for internal data); customer-managed keys (CMK) mean you hold them in Key Vault / KMS (needed for restricted data or a key-control mandate); HSM-backed keys give FIPS 140-2 L3 assurance and crypto-erase. The tradeoff is against reliability and cost: CMK/HSM makes key availability a hard dependency of the data, so purge protection / deletion windows and key HA are mandatory, and HSM is expensive.

4. What does “defense in depth” mean if identity is already the perimeter — isn’t the network obsolete? No — the network is a layer, not the perimeter. Defense in depth means no single failure is fatal: edge WAF/DDoS, then network segmentation (default-deny), then private data endpoints, then data-plane RBAC, then encryption. Breaking one layer gets an attacker to the next, and each layer shrinks blast radius and generates detection telemetry.

5. How do you keep governance from being bypassed by someone clicking in the portal? Enforce guardrails at the control plane, not just the pipeline: Azure Policy Deny at the management-group scope, or an SCP Deny at the AWS Organization/OU level. These apply to every resource regardless of how it was created. Ship them via Audit first on brownfield estates, remediate, then flip to Deny to avoid breaking existing workloads.

6. What is the “assume breach” posture and how does it change your design? You design as if an attacker is already inside, which reorders investment toward detection, least privilege, blast-radius containment, and rehearsed response — and away from a perfect perimeter. Concretely: centralize logs before you need them, wire automated containment for unambiguous signals, bound what any one identity can reach, and game-day the runbook.

7. Map the pillar’s tradeoffs against the other four Well-Architected pillars. Phishing-resistant MFA + JIT trades against operational excellence (friction); private endpoints and full-fidelity logging trade against cost; CMK/HSM trades against reliability (key availability) and cost; deep packet inspection trades against performance efficiency (latency) and cost; deny-by-default on brownfield trades against operational excellence (can break things). The pillar’s honesty is naming these and resolving them (break-glass, tiered logs, key HA, audit-first).

8. How do you protect a data service so an internet scanner can’t reach it, on Azure and AWS? Disable public network access and reach the service privately: Azure Private Endpoint with public_network_access_enabled=false and private DNS; AWS interface/gateway VPC endpoint plus a resource policy that denies any access not arriving through the endpoint (aws:sourceVpce), with S3 public-access-block on. Enforce TLS 1.2 minimum and keep data-plane RBAC in place regardless.

9. What belongs in a CI security gate versus an org-level guardrail, and why both? The CI gate (secret scanning, IaC static analysis, CVE checks) fails the build pre-merge — but only catches what flows through the pipeline. The org guardrail (Policy/SCP at the boundary) enforces at the control plane and catches everything, including portal-created and out-of-band resources. You need both: defense in depth applied to governance itself.

10. Your review finds a workload where a human can decrypt restricted data. How do you close it while keeping break-glass for operations? Separate cluster/control-plane access from data access using key custody: grant unwrapKey/Decrypt only to the workload’s managed identity / IAM role, explicitly deny it to human principal ARNs, and keep human break-glass to the control plane (PIM / Identity Center) — which can reach compute but not plaintext. Fire an alert on every break-glass elevation for an audited trail.

11. How do you keep the audit trail trustworthy during an incident? Make central logging immutable and out of the workload’s blast radius: an AWS Organization CloudTrail to an S3 bucket with Object Lock in a separate log-archive account; a Log Analytics workspace in a locked subscription with delete-protection and RBAC no workload identity holds. An attacker who can delete your logs has erased the investigation.

12. Which certs and frameworks does this map to? The pillar underpins AZ-500 (Azure Security Engineer) and SC-100 (Cybersecurity Architect) on the Azure side, and AWS Certified Security – Specialty and the Solutions Architect Professional on the AWS side. The design-principles-and-review framing maps directly to the Azure Well-Architected and AWS Well-Architected assessments, and the controls align to CIS Benchmarks, NIST, and the cloud CIS Foundations standards.

A compact cert mapping for revision:

Quick check

1. Name any four design principles of the Well-Architected security pillar, and give one concrete control for each.
2. “Identity is the perimeter” — what three moves implement it, and what does each stop?
3. You must protect restricted data with customer-managed keys. What is the one reliability control you must enable, and why?
4. A resource created in the portal violates your encryption standard even though CI passed. Why did CI miss it, and what enforces the rule regardless of origin?
5. Your security review must prove no human can read tenant data at rest, but engineers need break-glass to the cluster. How do you satisfy both?

Answers

1. Any four of: strong identity foundation (Entra/IAM SSO + MFA + PIM/roles), least privilege (scoped RBAC/IAM, no wildcards), defense in depth (NSG/SG default-deny + WAF + private endpoints + encryption), protect data (classification + CMK/HSM + TLS 1.2), assume breach / detect + respond (centralized logs + Sentinel/GuardDuty + rehearsed runbook), automate (Azure Policy / SCP + IaC), prepare for events (break-glass + game days).
2. Kill standing privilege (PIM-eligible / short-lived roles — stops a phished credential from being instant admin), phishing-resistant MFA on context + block legacy auth (Conditional Access / IAM conditions — stops credential replay and MFA bypass), and managed identities / IAM roles for workloads (stops secrets in code/config from leaking). Narrowest role, narrowest scope throughout.
3. Purge protection / a sane key-deletion window (soft-delete + purge protection on Azure Key Vault; a 7–30 day deletion window on KMS). Because CMK gives you crypto-shred — destroy the key and the data is unrecoverable — an accidental key delete becomes a permanent data-loss incident, so key availability is a hard reliability dependency of the data.
4. CI only inspects what flows through the pipeline; a portal-created (or out-of-band) resource never hit the gate. Enforce the rule at the control plane with an Azure Policy Deny at management-group scope (or an SCP Deny at the AWS OU), which applies to every resource regardless of how it was created. Audit-first on brownfield, then flip to Deny.
5. Separate data access from control-plane access via key custody: grant unwrapKey/Decrypt only to the workload’s managed identity / IAM role, explicitly deny it to every human principal, and keep human break-glass to the cluster control plane through PIM / Identity Center — that path reaches compute but not plaintext. Alert on every break-glass elevation for an audited trail.

Glossary

• Well-Architected Framework (WAF / WA) — Microsoft’s and Amazon’s structured guidance across five pillars (security, reliability, cost, performance, operational excellence); the security pillar is a design lens plus a review method.
• Design principle — a foundational rule of the pillar (e.g. least privilege, assume breach) that each concrete control traces back to.
• Shared responsibility model — the division of security duties between provider (substrate) and customer (identity, data, config, code); the line moves with IaaS/PaaS/SaaS.
• Identity as the perimeter — authorizing every request on identity + context rather than network location; the zero-trust core.
• PIM (Privileged Identity Management) — Azure feature that makes admin roles eligible (dormant) until activated with MFA/approval; the JIT-admin control.
• Conditional Access — Azure policy engine that grants/blocks access based on user, app, device, location, and risk; where phishing-resistant MFA and legacy-auth blocking are enforced.
• Managed identity / IAM role — a workload’s own cloud identity, used instead of a stored secret; scoped to least privilege.
• Least privilege — granting the minimum permission, at the narrowest scope, for the shortest time; no wildcard actions or scopes.
• Defense in depth — layered controls (edge, network, host, app, identity, data) so no single failure is fatal.
• Private Endpoint / PrivateLink — a private IP for a PaaS service so it is reachable on the VNet/VPC and not the public internet.
• Default-deny — a network posture that blocks all traffic unless explicitly allowed; applied east-west to stop lateral movement.
• Key custody — who holds the encryption key: platform-managed, customer-managed (CMK), or HSM-backed; determines who can crypto-shred the data.
• CMK (customer-managed key) — an encryption key you control in Key Vault / KMS; enables crypto-erase and key-control mandates, at the cost of making key availability a reliability dependency.
• Managed HSM / CloudHSM — a dedicated FIPS 140-2 Level 3 hardware key store for highest-assurance custody.
• Crypto-shred — rendering data unrecoverable by destroying its encryption key rather than the ciphertext.
• Assume breach — designing as if an attacker is already inside, prioritizing detection, containment, and rehearsed response.
• SIEM (Security Information and Event Management) — the central correlation/detection/response system (Microsoft Sentinel; Security Lake + tooling on AWS).
• Auto-remediation — code that fixes an unambiguous finding automatically (Azure Policy deployIfNotExists; AWS Config + SSM).
• Guardrail — a preventive (Deny) or detective (Audit) control at the org boundary (Azure Policy at management group; SCP at OU) that enforces at the control plane.
• Secure Score / Security Hub score — a trended posture metric summarizing config compliance; a backlog generator, not a vanity number.
• HRI (high-risk issue) — a Well-Architected Review finding flagged as high risk that should be prioritized for remediation.

Next steps

You can now run a security design review across Azure and AWS and turn every principle into code. Build outward:

• Next: Azure Well-Architected Framework: Security Pillar and AWS Well-Architected: Security Pillar — the cloud-native expressions of everything above, with each vendor’s exact question set.
• Related: Threat Modeling with STRIDE, Data-Flow Diagrams & Attack Trees — the method that feeds the review by enumerating the attack paths the controls must break.
• Related: Zero Trust Architecture Blueprint: Identity, Network & Data — the identity-as-perimeter model in full, and Zero Trust with Conditional Access & PIM for the Azure enforcement.
• Related: AWS KMS Encryption Deep Dive and Azure Encryption at Rest with CMK & Double Encryption — the key-custody mechanics behind the data-protection decisions.
• Related: Security Incident Response: Runbooks, Tabletops & Cloud Forensics — turn the assume-breach posture into a rehearsed response.
• Related: Software Supply Chain: SBOM, VEX & Admission Verification and Workload Identity Federation for Secretless CI/CD — secure what you ship and how you ship it.
• Related: the other pillars — Reliability, Operational Excellence, and Performance Efficiency — because security is a tradeoff against each and the review weighs all five together.