Gain secure access to on-premises applications with AWS Verified Access

AWS Verified Access (AVA) provides secure access to applications from anywhere. AVA removes the need for a VPN, which simplifies the remote connectivity experience for end users and reduces the management complexity for IT administrators.

But does the application need to be running in AWS to use AVA? The answer is No.  If you have connectivity from Amazon Web Services (AWS) to your on-premises network, you can use AVA.  This avoids capital expenses to purchase hardware or add functional licensing to existing hardware.  Additionally, AVA provides a highly available and resilient service that you do not have to architect and maintain on your own.

In this blog post, I will show you how your remote users can access on-premises applications through a hybrid network using AVA.  The architecture shown can also be used to access an application deployed in another cloud provider.

A previous post, AWS Verified Access Preview — VPN-less Secure Network Access to Corporate Applications, shows the detailed steps to set up AVA with a web server running on an Amazon Elastic Compute Cloud (Amazon EC2) instance.

You can modify this setup by creating an AVA endpoint that uses an Elastic Load Balancer (ELB) to direct traffic to an on-premises server by IP address (IP Targets). AVA endpoints can attach to either an Elastic Network Interface (ENI) or an internal ELB, an Application Load Balancer (ALB) or a Network Load Balancer (NLB). I will select a Network Load Balancer, which allows us to specify an IP address as a target. This is what allows me to specify the target on my on-premises network.

Architecture overview

Before we look at the architecture, it is important to know how AVA works and its key components:

• Trust providers manage user identity and device security state.
• AVA instances handle application requests and allow access when security requirements meet the configured Access Policies. AVA instances join one or more Trust Providers and one or more AVA groups.
• AVA groups contain an access policy and one or more Verified Access endpoints.
• AVA endpoints contain an access policy and the connection details for the application being surfaced. These details include the public DNS name for the application, the attachment type (Load Balancer or Network Interface) and the details of the attachment.

The following figure, Figure 1, shows a high-level overview of key AVA components. Refer to the AVA documentation to learn more.

Figure 1: AVA key components

The configuration of the AVA endpoint is where we deviate from the setup described in the previous post. Instead of pointing to an ENI, I point to an NLB in a private subnet with a target IP address (IP Target) of the web server in the on-premises network, as shown in the following figure. The traffic is routed from over an AWS Site-to-Site VPN from the AWS Private subnet to the subnet in the on-premises network, as shown in Figure 2. The Site-to-Site VPN in the following figure can be replaced with an AWS Direct Connect connection and maintain identical functionality.

Figure 2: Architecture overview

Prerequisites

For this walkthrough, you should have the following prerequisites:

• Complete the steps in AWS Verified Access Preview — VPN-less Secure Network Access to Corporate Applications post, prior to the deployment of the AVA endpoint step.
• Set up an on-premises network connected to the Amazon Virtual Private Cloud (Amazon VPC) through Site-to-Site VPN. Follow the AWS VPN documentation on the configuration steps.
• Configure routing for connectivity between the AWS private subnet and the on-premises subnet.
• Set up a PiHole server (or any server with an HTTP/HTTPS web interface such as an Apache web server).
• Domain name that can be used with the AVA endpoint such as pihole.example.com.
• Domain Certificate for the Domain Name setup in AWS Certificate Manager.
• A security group for the AVA endpoint to allow inbound access on port 443 from anywhere (0.0.0.0/0).

Walkthrough

This walkthrough builds on the previous post, AVA Preview — VPN-less Secure Network Access to Corporate Applications. I have an on-premises network (192.168.10.0/24) connected to an AWS private subnet (10.25.2.0/23) through a Site-to-Site VPN. In my on-premises network, I have a server (192.168.10.11) running PiHole. I make the web management console available for secure access over the internet with AVA. Note that AVA takes the on-premises PiHole Admin console running on port 80 and securely exposes it to the internet over HTTPS port 443. All the steps described in the previous post up to AVA access group apply to this setup as well. The following steps are conducted in this setup:

• Create an NLB target group containing the PiHole server’s IP Address (IP Target)
• Deploy an internal NLB pointing to the new target group
• Create an AVA endpoint pointing to the NLB

Log in to your AWS Management Console in the AWS Region where the prerequisite resources have been set up, and follow these steps.

Step 1: Create Security Groups

We want to ensure that the traffic between the AVA endpoint and the NLB is secure.  We accomplish this by adding a Security Group to the AVA endpoint that can be granted access to the NLB by its Security Group.

1. In the console, go to EC2 > Security Groups and select Create Security Group.
2. Under Basic Details:
   1. Enter ava-endpoint-web for Security Group name.
   2. Enter Security Group for the AVA endpoint for Description.
   3. Select the VPC which contains the private subnet for hosting the Network Load Balancer under VPC.
3. Select Create security group to create the Security Group.
4. In the console, go to EC2 > Security Groups and select Create Security Group.
5. Under Basic Details:
   1. Enter nlb-web-app-sg for Security Group name.
   2. Enter Security Group to secure access to the NLB for Description.
   3. Select the VPC which contains the private subnet for hosting the Network Load Balancer under VPC.
6. Under Inbound rules:
   1. Select Add rule.
   2. Select HTTP for Type.
   3. For Source leave Custom selected and select the Security Group named ava-endpoint-web created above.
7. Select Create security group to create the Security Group.

Step 2: Create a target group for the application server

Because the on-premises target server is running on HTTP port 80, we use a TCP target group instead of HTTPS. We are only using a single server for this demonstration, so the targets only contain one entry. This is shown in the following figure.

1. In the console, go to EC2 > Load Balancing > Target Groups and select Create target group.
2. On the Specify group details page:
   1. Select IP addresses as the target type.
   2. Enter PiHoleServer as the target group name.
   3. Select the VPC that contains the private subnet for hosting the NLB under the VPC.
   4. Select TCP for Protocol.
   5. Select Next.
3. On the Register targets page:
   1. For Step 1, select Other Private IP address for the Network.
   2. For Step 2, enter 192.1668.10.11 (or your server’s specific IP address) for the IPv4 address.
   3. Select Include as pending below.
   4. Select Create target group at the bottom of the page.

Figure 3 shows the details for the created Target Group.

Figure 3: NLB target group configuration details

Step 3: Create an internal NLB

The internal NLB is the target for the AVA endpoint. Connect it to the Target Group created in the previous steps as shown in the preceding post.

1. In the Console, go to EC2 > Load Balancing > Load Balancers and select Create load balancer.
2. On the Compare and select load balancer type page, select Create under NLB.
3. On the Create Network Load Balancer page:
   1. Enter PiHole as the load balancer name.
   2. Select Internal for Scheme.
   3. Select the VPC that contains the private subnet for hosting the NLB under the VPC.
   4. Select the Availability Zone (AZ) and private subnet under Mappings for placement of the NLB interface.
   5. Clear the items in Security groups, as we are not creating any security groups for the NLB.
   6. Select the target group created in the previous section for the target group under Listeners and routing.
   7. Select Create load balancer at the bottom of the page.
   8. Wait until the load balancer Status shows as Active

Figure 4 shows the details for the created load balancer.

Figure 4: Load balancer configuration details

Step 4: Create the AVA endpoint

The AVA endpoint exposes the load balancer and the attached application server for secure access by users.

1. In the Console, go to VPC > AWS Verified Access > Verified Access endpoints and select Create Verified Access endpoint.
2. On the Create Verified Access endpoint page:
   1. Enter vae-pihole under Name tag.
   2. Select the AVA group created previously.
   3. Under Application Details:
      1. Enter the domain name created (such as pihole.example.com) as part of the prerequisites as the Application Domain.
      2. Enter the domain name certificate created as part of the prerequisites as Domain Certificate ARN.
   4. Under Endpoint Details:
      1. Select VPC as the Attachment type.
      2. Select the AVA endpoint security group created as a part of the prerequisites as Security groups.
      3. Enter PiHole under the Endpoint domain prefix.
      4. Select Load balancer as the Endpoint type.
      5. Select the ARN named PiHole as the load balancer ARN.
      6. Select the subnet chosen for the load balancer as the Subnet.
   5. Under Policy Details:
      1. Enter a policy to grant user access to the endpoint. This policy depends on your specific needs. You can read more about syntax in the AVA policies documentation page. You can use the following as a starter to only allow access to users with a specific email address domain (amazon.com for my purposes):

         permit(principal, action, resource)
         when {
             context.awsnewsblog.user.email.address like “*@amazon.com”
         };

      2. Select Create verified access endpoint at the bottom of the page.
      3. Wait until the AVA endpoint status shows as Active.

Figure 5 shows the details for the created AVA endpoint.

Figure 5: AVA endpoint configuration details

Step 5: Testing secure access

After the final step, wait a few minutes for the updates to become active. Then go to your selected domain, https://pihole.example.com, in a browser. The browser is redirected to AWS Identity and Access Management (IAM) Identity Center (formerly AWS SSO). We enter the username and password of our test user, and then are redirected to the application server’s log in page, as shown in the following image.

Figure 6: PiHole accessed through AVA endpoint

Cleaning up

To avoid incurring unnecessary charges, delete the resources created as part of this post when you are done. When you are finished with an AVA instance, you can delete it. Before you can delete an instance, you must remove any associated trust providers, and delete the member AVA instances followed by the associated AVA groups. Next, delete the NLB followed by your Target Group.

Considerations

• Today AVA only supports HTTP/HTTPS
• Be aware of the AVA quotas when planning your deployment
• AVA pricing charges application hours for each endpoint and for GB of data processed
• Verify that AVA is available in the Regions you are operating in on the Global Infrastructure page

Conclusion

AWS Verified Access provides secure and trusted access to applications without the use of a VPN. You can use this powerful Zero Trust guided capability wherever you are in your cloud journey, regardless if your application is running in AWS, in your on-premises network or another cloud provider.  AVA provides a scalable pay as you go service so you only pay for what you use with no outlay of capital.  AWS runs and maintains the highly available and resilient infrastructure for you – extending the AWS Cloud Value Proposition to your on-premises web applications.

May 2, 2024 – Update: The on-premises subnet in Figure 2 was changed from “19.168.10.0/24” to “192.168.10.0/24.”