Design Doc: Zero Trust on AWS for Internal Service Access

Most enterprise architectures on AWS still operate with a network-location-based trust model: if a resource is inside the VPC or connected via VPN, it receives implicit access to other internal services. This model was reasonable when network boundaries were well-defined and static. Today, it is architectural debt.

The problem manifests in concrete ways. Engineers with SSH access to a bastion host inside the VPC can reach production databases unrelated to their role. Services with overprovisionned IAM roles — created during a rushed sprint — accumulate permissions that are never revoked. Workloads in different accounts communicate via peering without any traffic inspection or identity validation. When an attacker compromises any point inside this perimeter, lateral movement is trivial.

The scenario this document addresses is representative of organizations at scale: multiple AWS accounts organized via AWS Organizations, engineering teams with federated access via corporate SSO, mixed workloads (ECS, Lambda, EC2), and a growing set of internal APIs that need to be accessible to developers, CI/CD pipelines, and other services — but not to everyone, not always, and not without traceability.

The solution is not to add more VPNs or more Security Group rules. It is to rethink the trust model from scratch: no entity — human or machine — receives access by default. All access is explicitly authorized, minimally privileged, contextually validated, and continuously audited. This is Zero Trust applied pragmatically, not as a buzzword.

The design is organized into four complementary layers that, together, implement Zero Trust principles without requiring a complete rewrite of existing infrastructure.

Layer 1 — Centralized and Federated Identity. AWS IAM Identity Center becomes the single entry point for human access to all AWS accounts. Federation with the corporate IdP (Okta or Azure AD) ensures that multi-factor authentication, password policies, and identity lifecycle are managed in the company's system of record. Permission Sets in Identity Center are mapped to IdP groups, and the principle of least privilege is applied by role: a backend engineer does not receive, by default, access to data production accounts. Elevated access (e.g., break-glass for production) is granted via an approval flow with a maximum TTL of 4 hours and automatic notification to the security team.

Layer 2 — Adaptive Access for Developers. AWS Verified Access replaces VPN for developer access to internal tools (dashboards, admin APIs, observability consoles). Each access request is evaluated in real time against three signals: identity verified by the IdP (with MFA), device posture via integration with the existing MDM/EDR agent, and session context (time, location, anomalies detected by GuardDuty). There is no persistent VPN session that, once established, grants broad access. Each request is a new authorization decision.

Layer 3 — Inter-Service Communication with VPC Lattice. For service-to-service communication, VPC Lattice provides a unified control plane that applies workload identity-based authorization policies (IAM roles) independent of network topology. A payments service in one account can call a notifications service in another account only if the caller's IAM role is explicitly authorized in the destination service's resource policy. There are no open Security Group rules between VPCs. Traffic is authenticated by SigV4 signature on each call. Services that do not yet support VPC Lattice use VPC endpoints with restrictive resource policies as a transition layer.

Layer 4 — Continuous Audit and Detection. CloudTrail with Data Events enabled across all accounts, centralized in a dedicated security account via AWS Organizations. Security Hub aggregates findings from GuardDuty, IAM Access Analyzer, and Config Rules into a unified dashboard. IAM Access Analyzer runs continuously to detect excessive permissions and unintentional external access. A set of custom Config Rules verifies security invariants: no IAM role with :, no Security Group with 0.0.0.0/0 on sensitive ports, no public S3 buckets in production accounts. Critical findings trigger automation via EventBridge for automatic revocation of suspicious sessions.

VPC Lattice vs. Service Mesh (Istio/App Mesh). The choice of VPC Lattice for inter-service communication is deliberate and deserves justification. A service mesh like Istio offers more granular traffic control (circuit breaking, retry policies, traffic splitting), but introduces a complex control plane that most platform teams cannot operate safely. VPC Lattice delegates operational complexity to AWS and integrates natively with IAM — meaning service authorization policies are expressed in the same language as all other AWS policies, are audited by CloudTrail, and are analyzed by IAM Access Analyzer. The trade-off is less traffic flexibility in exchange for much less operational surface area. For most Zero Trust security use cases, this is the correct trade-off.

Verified Access vs. Corporate VPN. VPNs create persistent sessions with broad network access. Once connected, a developer (or an attacker who compromised their credentials) has network reach to all resources in the VPC. Verified Access evaluates each request individually, meaning a compromised session does not automatically grant access to all resources. The cost is additional per-request latency (typically 5–15ms, estimate based on service characteristics) and the need for device posture agent integration. For low-frequency internal tools (dashboards, admin consoles), this cost is acceptable. For high-frequency internal APIs between services, VPC Lattice is the correct mechanism — not Verified Access.

IAM Database Authentication vs. Static Credentials. Enabling IAM Auth on RDS/Aurora eliminates the need to manage database passwords. Authentication is done via a temporary token generated by STS, valid for 15 minutes. The trade-off is that each new database connection requires an STS call to generate the token, which has implications for connection pooling. The solution is to use a proxy (RDS Proxy) that maintains the connection pool and renegotiates IAM authentication transparently. This pattern completely eliminates the class of vulnerability of database credentials leaked in code or environment variables.

SCPs as Guardrails vs. IAM Policies as Controls. Service Control Policies at the Organizations level are guardrails that define the maximum possible — they do not grant access, only limit what can be granted. IAM Policies are the actual controls. The correct combination is: SCPs restrict unauthorized regions, unapproved services, and high-risk actions (e.g., disabling CloudTrail, removing MFA from root) for the entire organization; IAM Policies implement specific least privilege per workload. Trying to do everything via SCPs results in large, brittle policies. Trying to do everything via IAM without SCPs leaves gaps that an account administrator can exploit.