Zero Trust Architecture on AWS: Step-by-Step Guide

Kehinde Ogunlowo
2026-04-03T00:00:00-05:00

Implement Zero Trust on AWS with IAM Identity Center, VPC Lattice, Verified Access, and GuardDuty. Step-by-step guide for production environments.

More

Zero Trust Architecture on AWS: A Step-by-Step Implementation Guide

The perimeter-based security model — trusted internal network, untrusted external network — is dead. It has been dying for a decade, but the combination of remote workforces, cloud-native architectures, and increasingly sophisticated supply chain attacks has finally killed it. The 2024 NIST SP 800-207 revision and the 2025 CISA Zero Trust Maturity Model v2.1 both mandate Zero Trust as the baseline security posture for federal systems, and private sector adoption has followed.

Zero Trust operates on a simple principle: never trust, always verify. Every request — whether from a user, service, device, or network — must be authenticated, authorized, and continuously validated before granting access. On AWS, this translates to specific services and configurations that enforce identity-based access at every layer.

This guide walks through a production implementation of Zero Trust on AWS, covering identity, network, application, and data layers. The architecture draws from implementations at organizations handling FedRAMP High and HIPAA-regulated workloads.

[IMAGE: Zero Trust architecture diagram on AWS showing identity layer (IAM Identity Center), network layer (VPC Lattice, PrivateLink), application layer (Verified Access), and data layer (KMS, Macie) with verification checkpoints at each layer]

Layer 1: Identity — The Foundation

Zero Trust starts with identity. If you cannot definitively answer "who is making this request?" and "are they authorized for this specific action?", nothing else matters.

AWS IAM Identity Center (Successor to AWS SSO)

IAM Identity Center is the centralized identity management plane for multi-account AWS environments. Configuration:

1. Enable IAM Identity Center in your management account with AWS Organizations.

2. Connect your IdP: Integrate with your existing identity provider (Okta, Azure AD/Entra ID, Google Workspace) using SAML 2.0 or SCIM for automated user provisioning.

3. Define Permission Sets that map to least-privilege access patterns:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyEC2",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:Get*",
        "ec2:List*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        },
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Key elements in that policy: region restriction limits blast radius, and the MFA condition ensures human users have completed a second authentication factor.

Short-Lived Credentials Everywhere

Eliminate long-lived access keys entirely:

Human users: IAM Identity Center provides temporary credentials (default: 1 hour). No static access keys.

EC2 workloads: Instance profiles with IAM roles. Credentials auto-rotate via the instance metadata service (IMDSv2 only — disable IMDSv1).

EKS workloads: IAM Roles for Service Accounts (IRSA) or EKS Pod Identity (GA since EKS 1.28). Each pod gets a unique, scoped IAM role.

Lambda: Execution role with least-privilege policy. Credentials auto-managed by the Lambda service.

CI/CD (GitHub Actions): OIDC federation — GitHub's OIDC provider issues short-lived tokens exchanged for AWS temporary credentials. Zero stored secrets.

# GitHub Actions OIDC — no stored AWS credentials
permissions:
  id-token: write
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-arn: arn:aws:iam::123456789012:role/github-actions-deploy
      aws-region: us-east-1
      role-session-name: GitHubActions-${{ github.run_id }}

Enforce MFA and Device Posture

Use IAM Identity Center's access control attributes to require: - MFA on all human access (TOTP or FIDO2 hardware keys — prefer FIDO2) - Device compliance checks via AWS Verified Access device trust integrations (Jamf, CrowdStrike, Microsoft Intune)

Layer 2: Network — Micro-Segmentation

Traditional VPC security groups and NACLs provide coarse network controls. Zero Trust requires service-level micro-segmentation: Service A can communicate with Service B on port 443 with a valid identity, and nothing else.

AWS VPC Lattice

VPC Lattice (GA since 2023, significantly expanded in 2025) is AWS's service-to-service networking layer that combines service discovery, load balancing, and identity-based authorization:

1. Create a Service Network that spans VPCs and accounts:

aws vpc-lattice create-service-network \
  --name production-mesh \
  --auth-type AWS_IAM

1. Register services as VPC Lattice targets. Each service gets a DNS name (e.g., api-server.production-mesh.vpc-lattice.us-east-1.on.aws).

2. Define auth policies per service:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/order-service-role"
      },
      "Action": "vpc-lattice-svcs:Invoke",
      "Resource": "arn:aws:vpc-lattice:us-east-1:123456789012:service/svc-payments-api/*",
      "Condition": {
        "StringEquals": {
          "vpc-lattice-svcs:RequestMethod": "POST",
          "vpc-lattice-svcs:RequestPath": "/api/v1/process-payment"
        }
      }
    }
  ]
}

This policy allows only the order-service-role to call the POST /api/v1/process-payment endpoint on the payments API. Any other service, method, or path is denied by default.

Private Connectivity

VPC Endpoints (PrivateLink): All AWS service traffic stays on the AWS network. Deploy interface endpoints for S3, DynamoDB, SQS, SNS, KMS, ECR, CloudWatch Logs, and Secrets Manager. This eliminates internet gateway dependencies and reduces attack surface.

Transit Gateway: Hub-and-spoke connectivity between VPCs with route table isolation. Production, staging, and development VPCs route through separate transit gateway route tables with no cross-environment paths.

Security Groups as Identity Proxies

Reference security groups by ID rather than CIDR blocks. A security group for the payments database:

Inbound rule:
  Protocol: TCP
  Port: 5432
  Source: sg-0abc1234 (payments-service-sg)

Only instances in the payments-service-sg security group can reach the database. No IP-based rules that break when instances scale or replace.

Layer 3: Application — Verified Access

For applications accessed by humans (internal tools, admin dashboards, developer portals), AWS Verified Access provides identity-aware application access without VPNs.

AWS Verified Access Configuration

1. Create a Verified Access Instance with your trust provider (IAM Identity Center, Okta, CrowdStrike, Jamf).

2. Define access policies using Cedar policy language:

permit(principal, action, resource)
when {
  context.identity.groups.contains("engineering") &&
  context.identity.verified_email == true &&
  context.device.managed == true &&
  context.device.os_version >= "14.0"
};

This policy grants access only when the user is in the engineering group, has a verified email, uses a managed device, and runs macOS 14+ or equivalent. Device posture is evaluated on every request — not just at session creation.

1. Create Verified Access Endpoints for each internal application, replacing VPN-based access patterns.

[IMAGE: Flow diagram showing a user request passing through AWS Verified Access, with identity verification (IAM Identity Center), device posture check (CrowdStrike), and policy evaluation (Cedar) before reaching the internal application behind a VPC]

Layer 4: Data — Encryption and Classification

AWS KMS with Key Policies

Every data store must use customer-managed KMS keys (CMKs) with key policies that restrict decryption to specific IAM roles:

{
  "Sid": "AllowPaymentsServiceDecrypt",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/payments-service-role"
  },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "rds.us-east-1.amazonaws.com"
    }
  }
}

The kms:ViaService condition ensures the key can only be used for decryption via RDS — even if the role is compromised, the key cannot be used to decrypt arbitrary ciphertext.

Data Classification with Amazon Macie

Enable Macie across all S3 buckets to automatically classify sensitive data (PII, PHI, financial data, credentials). Macie's ML classifiers identify data that should have additional access controls and alerts when sensitive data is stored in buckets with public access or overly permissive policies.

S3 Block Public Access

Enforce at the organization level through SCPs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3PublicAccess",
      "Effect": "Deny",
      "Action": "s3:PutBucketPolicy",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-acl": "private"
        }
      }
    }
  ]
}

Layer 5: Detection and Response

Zero Trust assumes breach. Continuous monitoring detects anomalies even after authentication succeeds.

Amazon GuardDuty

Enable GuardDuty across all accounts with these protections active: - S3 Protection: Detects anomalous data access patterns - EKS Audit Log Monitoring: Detects suspicious Kubernetes API calls - Lambda Protection: Detects compromised Lambda functions - RDS Protection: Detects anomalous database login activity - Runtime Monitoring (EKS, EC2, ECS): Detects runtime threats at the OS level

AWS Security Hub

Aggregate findings from GuardDuty, Macie, Inspector, IAM Access Analyzer, and Config into Security Hub. Enable the AWS Foundational Security Best Practices and CIS AWS Foundations Benchmark v3.0 standards for automated compliance scoring.

CloudTrail with Lake

CloudTrail logs every API call across all accounts. CloudTrail Lake enables SQL-based queries across historical data for incident investigation:

SELECT eventTime, eventName, sourceIPAddress, userIdentity
FROM cloudtrail_events
WHERE userIdentity.arn LIKE '%admin%'
  AND eventTime > '2026-04-01'
  AND sourceIPAddress NOT IN ('10.0.0.0/8')
ORDER BY eventTime DESC

Implementation Roadmap

Phase | Duration | Focus
Phase 1 | Weeks 1-2 | IAM Identity Center + MFA + eliminate static keys
Phase 2 | Weeks 3-4 | VPC endpoints + security group refactoring
Phase 3 | Weeks 5-6 | VPC Lattice for service-to-service auth
Phase 4 | Weeks 7-8 | Verified Access for human application access
Phase 5 | Weeks 9-10 | KMS key policies + Macie classification
Phase 6 | Ongoing | GuardDuty + Security Hub + continuous monitoring

Common Pitfalls

1. Overly broad IAM policies: Start with AWS IAM Access Analyzer to identify unused permissions, then scope down. Action: * is never acceptable outside sandbox accounts.

2. Ignoring service-to-service auth: Encrypting traffic (TLS) is not the same as authorizing traffic. Services must authenticate themselves, not just encrypt the pipe.

3. VPN as Zero Trust: Replacing a VPN with another VPN is not Zero Trust. The goal is per-request verification, not network-level trust.

4. Neglecting detection: Prevention fails eventually. Detection and response capabilities (GuardDuty, Security Hub, CloudTrail Lake) are not optional.

Next Steps

Zero Trust is not a product you purchase — it is an architecture you build layer by layer. The five-layer approach above (identity, network, application, data, detection) provides a structured path from perimeter-based security to continuous verification.

Citadel Cloud Management's Security Frameworks collection includes implementation templates for Zero Trust on AWS, Azure, and GCP — including Terraform modules for VPC Lattice, IAM Identity Center, and GuardDuty configuration. Our cloud security course covers NIST 800-207, CISA Zero Trust Maturity Model, and hands-on implementation labs. Browse the full product catalog for additional security resources.

Ready to build enterprise-grade security skills? Enroll free at Citadel Cloud Management and start implementing Zero Trust today.

ZeroTrust #AWS #CloudSecurity #IAM #VPCLattice #VerifiedAccess #GuardDuty #NIST #FedRAMP #CyberSecurity

Continue Learning

Explore 17 Free Cloud Courses

Browse Cybersecurity Frameworks

Cloud Certification Roadmap for Africa-Based Engineers

Zero Trust Security for Multi-Cloud Environments

AI Security Architecture: Protecting LLMs, Data Pipelines, and Model Endpoints