Zero Trust | Cloud Concepts

What is Zero Trust

Zero Trust treats internal and external networks as potentially hostile and requires authentication, authorization, and appropriate protection for each resource interaction. It reduces the impact of stolen credentials and compromised devices by combining least-privilege access, workload identity, segmentation, encryption, and ongoing evaluation of security signals.

Zero Trust replaces the assumption that being inside a corporate network makes a user or workload trustworthy. Access decisions instead depend on an authenticated identity, the requested resource and action, and relevant context such as device posture or session attributes. Network controls remain important, but network location alone is not sufficient evidence of trust. The objective is to make unauthorized access difficult and limit the damage when an identity, device, or application is compromised.

In cloud environments, apply this model to both people and workloads. Federate human identities, require multifactor authentication where appropriate, and issue short-lived credentials instead of distributing permanent access keys. Give applications dedicated workload identities with permissions restricted to their actual operations. A reporting application that only reads one storage location should not receive account-wide storage permissions merely because it runs in a private subnet.

For workforce access to private applications, an identity-aware access service can enforce application-specific policies without granting broad network access. For example, AWS Verified Access can protect an internal application using identity information and, when configured, device trust signals. An engineer working from an office or home network can be evaluated against the same application policy. Secure the application backend so that users cannot bypass the access enforcement point through another reachable address.

Private connectivity and Zero Trust solve related but different problems. AWS PrivateLink provides private connectivity through interface VPC endpoints for supported services without requiring public internet access. Gateway VPC endpoints provide private access to Amazon S3 and DynamoDB but do not use PrivateLink. Neither endpoint type makes a caller trustworthy or replaces service authorization. Combine private access with least-privilege identity and resource policies, endpoint policies where supported, and TLS with certificate validation. Private routing is not a substitute for encryption.

AWS Client VPN provides encrypted remote network access, but connecting successfully should not grant unrestricted access to reachable resources. Use appropriate authentication, destination authorization rules, routes, security groups, and application-level authorization. Choose application-scoped access when users need only specific applications; choose VPN connectivity when the requirement genuinely includes broader network access or protocols that the application-access design does not support.

For hybrid workloads, separate connectivity requirements from trust decisions. An on-premises application reaching an AWS service through an interface endpoint needs working routes, endpoint security-group rules, and DNS resolution that returns the intended private addresses. It still needs a valid workload identity and authorization. AWS Direct Connect does not encrypt traffic by default, so assess TLS or another supported encryption mechanism separately. A private circuit or site-to-site VPN does not establish trust in every workload behind it.

Operate the model continuously by collecting identity, access-decision, application, and network telemetry. Review excessive permissions, revoke compromised sessions or credentials, and reevaluate access as supported signals change. Continuous verification does not necessarily mean prompting users to authenticate for every packet. It means avoiding permanent trust and enforcing decisions at appropriate request and session boundaries.

The trade-offs include policy complexity, identity-provider dependencies, device integration, logging costs, and potential availability impacts when enforcement components fail. Troubleshoot authentication, authorization, DNS, routing, encryption, and backend reachability separately rather than weakening every layer to restore connectivity. Zero Trust is an architectural approach, not a product purchase, a replacement for firewalls, or a guarantee that breaches cannot occur.

Key aspects of Zero Trust

Zero Trust combines explicit verification, least privilege, containment, protected communications, and ongoing evaluation without treating network location as proof of trust.

Explicit, context-aware verification

Authenticate the requesting user or workload and authorize access to the specific resource. Incorporate device posture and other relevant signals when the enforcement system supports them.

Least-privilege access

Limit permissions to necessary actions, resources, and conditions. Prefer temporary credentials and application-specific access over persistent credentials or broad network access.

Assume compromise and limit propagation

Design controls so that one compromised device or identity cannot freely reach unrelated resources. Combine application authorization, workload isolation, and network segmentation to restrict lateral movement.

Separate private connectivity from trust

Use private endpoints and hybrid connectivity to reduce exposure, not to establish authorization. Require valid identities and resource permissions even when requests originate inside a VPC or corporate network.

Protect communications

Use appropriately configured TLS and certificate validation for sensitive traffic, including private paths. Evaluate encryption on each connection segment rather than assuming that a VPN, proxy, or private circuit protects the entire path.

Ongoing evaluation and observability

Record access decisions and monitor changes in identity, device, and workload risk. Define practical procedures for credential revocation, session termination, policy updates, and investigation.

Cloud services for Zero Trust

AWS Verified Access provides application-scoped workforce access, while AWS Client VPN addresses requirements for remote network connectivity; they are alternative or complementary access mechanisms, not mandatory layers in one connection. IAM governs access to AWS resources through identities and permissions. PrivateLink reduces network exposure for supported service connections but does not replace authorization or TLS. In hybrid designs, routing and DNS must make private destinations reachable without granting unnecessary access. Combine these services with backend restrictions, application authorization, certificate validation, and access logging so that successful connectivity never becomes the sole basis for trust.

AWS Verified Access

Enforces access policies for applications using identity information and optional device trust context without requiring a VPN. Restrict backend reachability to prevent users from bypassing the enforcement point, and retain application-level authorization.

Open AWS Verified Access →

AWS PrivateLink

Provides private connectivity through interface VPC endpoints to supported services and endpoint services. Combine it with service authentication, applicable policies, security groups, and TLS; a private endpoint alone does not provide a Zero Trust architecture.

Open AWS PrivateLink →

AWS Client VPN

Provides encrypted remote-access connectivity with authentication and destination authorization controls. Apply restrictive routes, authorization rules, security groups, and application permissions because VPN admission alone does not establish resource-level trust.

Open AWS Client VPN →