Secure Remote Access with AWS Verified Access

#aws #security #backend #iam

Managing secure connectivity to private workloads has always been a challenge. Traditionally, organizations relied on VPNs or bastion hosts. While functional, these methods expose larger attack surfaces and lack context-aware access control.

AWS introduced** Verified Access (VA)** to solve this — providing Zero Trust access to your workloads, without requiring VPNs.

What is AWS Verified Access?

AWS Verified Access is a Zero Trust Network Access (ZTNA) service that allows you to securely provide access to your internal applications without requiring a VPN. It evaluates each request based on policies, user identity, device security posture, and other contextual signals before granting access.

Instead of granting blanket network access, VA ensures that only verified and trusted requests reach your applications.

Key Components of Verified Access

AWS Verified Access is built around four main components:

1. Verified Access Instance

The top-level resource that hosts all other VA resources. It defines the scope for trust providers, groups, and endpoints.

2. Verified Access Trust Providers
External sources of identity or device posture used to evaluate requests. Examples include:

OIDC Providers (Amazon Cognito, Okta, Ping, Auth0)
IAM Identity Center
Device-based providers (Jamf, CrowdStrike)

3. Verified Access Groups
Logical collections of endpoints with associated policies. Policies are written in the Cedar policy language and enforce access decisions (e.g., allow only verified emails, restrict by device posture).

https://www.cedarpolicy.com/en/aws-verified-access

permit(principal,action,resource)
when {
    context.cognitopolicy.email_verified == "true"
};

4. Verified Access Endpoints
Connectors to your internal applications. These endpoints can integrate with Application Load Balancers (ALBs), Network Load Balancers (NLBs), or Elastic Network Interfaces (ENIs), depending on the target application.

Supported Protocols for Verified Access Endpoints

Verified Access endpoints support multiple protocols depending on your workload:

HTTPS – Ideal for web applications that require encryption and authentication.
HTTP – Supported for non-encrypted internal apps (though TLS/HTTPS is strongly recommended).
TCP – For non-HTTP workloads, such as database, RDP, or CIDR Ranges.

👉 This flexibility allows you to use Verified Access not just for web apps, but also for secure connectivity to non-web internal services.

How to Set Up Verified Access (High-Level)

Here’s how I set up AWS Verified Access for an internal application:

Created a Cognito User Pool – to manage application users.

Configured Trusted Providers – opted for OIDC and integrated Cognito; device-based providers like Jamf and CrowdStrike are also supported.

3.Deployed a Verified Access Instance – the root container for all VA resources.

4.Defined a Verified Access Group – applied a policy to allow only users with a verified email domain to access.

5.Created a Verified Access Endpoint – attached it to an internal ALB that fronted my application.

6.Updated Route 53 – mapped a friendly DNS name to the Verified Access endpoint.

Once this was complete, users could access the application securely via Verified Access, without a VPN.

User → Route 53 → Verified Access Endpoint
             │
             ▼
   IAM Identity Center (SSO)
             │
     [Policy evaluation]
             │
             ▼
        Internal ALB
             │
             ▼
         Backend App

Why Verified Access Matters

Zero Trust – Every request is authenticated and authorized.
No VPN Hassle – Users connect directly to apps with browser-based access.
Fine-Grained Access – Policies can evaluate user identity, device posture, and session context.
Protocol Flexibility – Works for web and non-web applications (HTTPS, HTTP, TCP).
Better User Experience – Fast, seamless access with improved security posture.