{
  "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

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