CLOUD SERVICE · AWS

AWS Verified Access - AWS Verified Access provides policy-controlled access to corporate applications without requiring a traditional VPN.

AWS Verified Access evaluates user identity and, when configured, device security posture before allowing access to private applications. It provides application-specific access controls for workloads in a VPC, using centralized policies rather than granting users broad network connectivity.

Cloud Services Hub →

What is AWS Verified Access

Read the extensive description

AWS Verified Access provides access to corporate applications without requiring users to join a corporate network through a traditional VPN. It places a managed access layer in front of applications and evaluates authorization using configured trust information and access policies. For browser-based applications, engineers can expose an HTTPS application hostname while keeping the application backend private inside an Amazon VPC.

The main configuration objects are Verified Access instances, trust providers, groups, and endpoints. An instance establishes the trust configuration used to evaluate access. Trust providers supply user identity or device posture information. A group collects endpoints that share a baseline policy, while each endpoint identifies an application backend and can have an additional application-specific policy. Access must satisfy the applicable group and endpoint policies.

User identity can come from AWS IAM Identity Center or a supported OpenID Connect identity provider. Device trust providers can supply security signals from supported device-management and endpoint-security systems. Policies use the Cedar policy language and reference attributes made available through the configured trust providers. For example, an engineering application can require membership in a particular identity group and a device compliance signal. Attribute names and available values depend on the provider, so inspect the actual context before writing production policies.

For HTTPS applications, endpoint configuration includes the application domain, a suitable TLS certificate, and connectivity to a supported backend such as a load balancer or network interface. Engineers must configure DNS, subnets, security groups, and backend connectivity correctly. Verified Access performs access enforcement, but it does not repair routing problems or replace application-level authorization. Applications should continue to enforce permissions for individual records, operations, and administrative functions.

AWS Verified Access also supports non-HTTP TCP access through supported endpoint configurations and an AWS-provided connectivity client. This differs from browser-based HTTPS access in deployment requirements, client behavior, and billing. Confirm protocol, client-platform, Region, and trust-provider support before selecting an architecture for database or other TCP-based access.

Operationally, enable access logging and monitor denied requests, policy changes, and backend failures. Access logs can be delivered to supported AWS logging destinations, and AWS CloudTrail records supported management API activity. Treat trust-provider configuration and Cedar policies as security-sensitive infrastructure: version them, review changes, and test both permitted and denied access paths. When migrating from a VPN, start with a limited application set, validate authentication and session behavior, and remove obsolete backend access paths so users cannot bypass the new controls.

Key AWS Verified Access Features

Application-specific access without a VPN

Expose individual applications through managed access endpoints instead of granting users general network access. For HTTPS applications, users can access the application through a browser without installing a traditional VPN client.

Identity-based authorization

Use AWS IAM Identity Center or a supported OpenID Connect identity provider to authenticate users and supply identity attributes. Policies can restrict an application to the appropriate users or groups.

Device posture signals

Integrate supported device trust providers to incorporate device security information into authorization decisions. Validate the provider's attributes and supported access modes before requiring a particular compliance signal.

Cedar access policies

Define access rules using Cedar and the context supplied by trust providers. Test policies with representative identities and devices, including cases with missing attributes.

Group and endpoint policy layers

Apply a shared policy to a group of applications and add endpoint-specific restrictions where necessary. Applicable group and endpoint policies must both permit access.

Private application backends

Connect endpoints to supported VPC backend configurations, including load balancers and network interfaces. Keep backend services private and restrict network access to prevent bypassing Verified Access.

Access logging and auditability

Deliver access logs to supported destinations such as Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose. Use AWS CloudTrail separately to audit management actions such as policy and endpoint changes.

Non-HTTP TCP access

Provide controlled access to supported TCP resources using compatible endpoints and the AWS-provided connectivity client. Evaluate this separately from browser access because client requirements, supported configurations, and pricing differ.

AWS Verified Access Use Cases

Internal web applications

Provide browser access to private administrative portals, engineering tools, and business applications. Keep the application backend inside a VPC while applying identity-based access controls at its entry point.

Contractor and partner access

Authorize external personnel for specific applications through an integrated identity provider. Avoid granting broad network connectivity, and remove access through identity lifecycle controls and application policies.

Device-aware access to sensitive applications

Require supported device posture attributes in addition to a valid user identity. For example, restrict a financial operations application to an authorized group using devices that satisfy the configured compliance criteria.

Incremental VPN migration

Move selected applications behind Verified Access while retaining existing connectivity for workloads that have not yet migrated. Validate application behavior and remove legacy routes or permissions that would allow access around the policy enforcement point.

Controlled TCP resource access

Use supported non-HTTP endpoint configurations and the connectivity client for resources such as database services. Confirm protocol compatibility and client requirements before replacing an existing access path.

AWS Verified Access pricing models

Associated infrastructure and service charges

Budget separately for services such as load balancers, logging destinations, DNS, applicable data transfer, and third-party trust-provider subscriptions. These costs are not absorbed into the Verified Access endpoint charge.

Endpoint-based usage

Verified Access charges for provisioned endpoints using time-based meters. HTTP application endpoints and non-HTTP endpoint configurations have different pricing structures, so estimate costs using the applicable endpoint type and Region rather than a single per-user rate.

HTTP application data processing

HTTP application access includes charges for data processed through Verified Access, with pricing based on processed volume. Include expected application traffic, downloads, and other substantial response payloads in the estimate.

Non-HTTP connection usage

Non-HTTP access includes connection-based usage charges in addition to applicable endpoint charges. Estimate both connection duration and concurrency when evaluating long-lived database or other TCP sessions.

Services AWS Verified Access integrates with

A common HTTPS architecture places AWS Verified Access in front of an internal Application Load Balancer that routes requests to private application targets. IAM Identity Center supplies user identity, while an optional supported device trust provider supplies posture attributes. Group policies establish shared access requirements, and endpoint policies add restrictions for individual applications. VPC security groups and routing should prevent users from reaching the backend through an alternative, less-controlled path.AWS Certificate Manager supplies the certificate for the application's HTTPS hostname, and Route 53 publishes the DNS records directing that hostname to the Verified Access endpoint. Coordinate endpoint configuration, certificate coverage, DNS resolution, and application redirects during rollout. Authentication at the access layer does not remove the need for application-level authorization.For operations, send access logs to CloudWatch Logs for interactive troubleshooting or to S3 for longer retention and analysis. Keep management auditing through CloudTrail distinct from request-level access logging. Infrastructure automation should deploy networking, endpoints, policies, and logging together, with review controls for security-sensitive changes. Architectures using non-HTTP TCP access also require the compatible connectivity client and should be validated independently of browser-based deployments.

Amazon CloudWatch

Deliver Verified Access access logs to CloudWatch Logs for operational investigation and analysis. For example, use Logs Insights to investigate a rise in denied requests after a Cedar policy deployment. Configure log retention and access permissions because logs can contain identity and security context.

Open Amazon CloudWatch →

Amazon Route 53

Use Route 53 to publish the DNS records needed to direct an application hostname to its Verified Access endpoint. For example, configure portal.example.com to resolve to the endpoint's generated domain using the appropriate DNS record. Coordinate DNS changes with certificate validation and application-domain configuration.

Open Amazon Route 53 →

Amazon VPC

Verified Access uses VPC networking to reach application backends through supported endpoint configurations. For example, deploy an application on private EC2 addresses and use a network-interface endpoint configuration where appropriate. Validate subnet selection, available IP addresses, routing, and security groups as part of deployment.

Open Amazon VPC →

Amazon S3

Deliver access logs to Amazon S3 for durable retention and downstream security analysis. For example, retain logs in a centralized security account and query them with Amazon Athena after configuring an appropriate table. Apply bucket permissions, encryption, and lifecycle rules consistent with the sensitivity of access records.

Open Amazon S3 →