Table of Contents
Welcome to Solution Architect Talk (SA Talk)—where our solution architects break down cloud security, architecture best practices, and innovative solutions for modern enterprises. In this post, we dive into AWS Verified Access and how it’s shaping the future of secure internal service access.
Cybersecurity Is More Critical Than Ever
Recently, the tech industry has been hit with some major cybersecurity breaches. One of the biggest? A multinational corporation got hacked simply because an old remote access credential had expired—giving attackers a way in. They stayed undetected for months, leading to a massive data leak that cost the company millions and wrecked its reputation.
And this isn’t a one-off incident. In 2024, cybersecurity threats surged, with businesses losing an average of $4.88 million per data breach—a record high. Even more worrying? A third of these breaches were caused by untracked, unsecured “shadow data.” Clearly, businesses need a better way to protect their internal services.
Why Companies Keep Critical Services on Internal Networks
With cyber threats growing and compliance regulations tightening, businesses are doubling down on security. One key strategy? Keeping critical services within internal networks rather than exposing them to the internet.
Hosting sensitive applications internally provides an extra layer of security—acting as a strong first line of defense. It keeps threats out, gives businesses full control over who can access what, and makes security management easier.
But this also creates a challenge: how do you securely grant remote access without opening the door to attackers?
The Remote Access Dilemma: VPN vs. Zero Trust
With remote work now the norm, companies need reliable ways to connect employees, contractors, and partners to internal resources. Traditional VPNs (Virtual Private Networks) have been the go-to solution, but they come with major drawbacks:
- Clunky setup – Installing and managing VPN clients can be a hassle.
- High maintenance – Managing VPNs across a global workforce gets expensive and complex.
- Security risks – VPNs often provide broad access, meaning a single compromised account can expose an entire network.
This is where Zero Trust comes in—a security model built on the idea of “never trust, always verify.” Instead of assuming that a logged-in user is safe, Zero Trust continuously checks their identity, permissions, and device security. AWS has stepped into this space with AWS Verified Access—a new way to bring Zero Trust security to internal applications.
AWS Verified Access: A Simple Way to Secure Internal Services
In April 2023, AWS introduced Verified Access, a service designed to make Zero Trust security easy for businesses using AWS.
With Verified Access, users can securely log into internal web apps without needing a VPN. It continuously verifies identity and permissions, ensuring users get only the access they need—nothing more.
Setting it up is straightforward, and AWS provides a step-by-step documentation guide here: AWS Verified Access Setup[1]
User Experience Flow:
Below is the process flow for accessing internal network services after implementing AWS Verified Access.
Let’s assume the following scenario:
- The service is placed in the internal network and uses an internal load balancer
- The load balancer is already configured
- Identity Center has been enabled and corresponding users are set up
Related architecture diagram as follows:
(Excerpted from document [1])
After completing the setup according to document [1], websites that previously required VPN access can now be accessed by first entering an authentication page without VPN, and then accessing the internal network services after verification.
Below are screenshot explanations of the usage process.
- Attempting to access internal website
- AWS SSO authentication screen appears
- After successful authentication, access to the page will be determined based on the configured Policy. The following example determines whether to allow access to the internal page based on whether the logged-in user belongs to a specific Identity Center Group. This enables very fine-grained access control. For more detailed syntax about control settings, please refer to [2]。
- If the Policy does not allow access, the following screen will appear
- If the Policy allows access, you can successfully use the service. Below is a customized screen showing successful testing, which will vary depending on the internal service being routed to.
How Much Does It Cost?
While AWS Verified Access brings a ton of security benefits, cost is a factor to consider.
- Pricing model: Pay-as-you-go, with charges based on usage.
- Breakdown:
- $0.27/hour per application (drops to $0.20/hour after 148,800 hours)
- $0.02 per GB of data processed
Example: If you run 10 applications for one hour and process 5GB of data, you’d pay $2.80. But for larger deployments (e.g., 300 applications running 24/7 for a month), costs can skyrocket to $55,062.
Key cost considerations:
✔️ Partial hours are billed as full hours
✔️ Standard AWS data transfer fees still apply
✔️ For 200+ applications, traditional VPNs might be more cost-effective
✔️ Start small and track costs before scaling up
✔️ Set cost alerts to avoid unexpected expenses
More details: AWS Pricing
Is AWS Verified Access Right for You?
AWS Verified Access is a great fit for:
- Startups & growing teams (under 100 employees, ~50 internal applications)
- Project-based teams needing temporary, secure access
- Companies with remote or outsourced workers who need access to specific internal apps
However, large enterprises (200+ applications, high data transfer needs) may find traditional enterprise-level Zero Trust solutions more cost-effective.
Final Takeaway
If you’re considering AWS Verified Access, start with a small-scale pilot. Test it with a single department or project, evaluate the costs, and see if it meets your security needs before rolling it out company-wide.
For businesses looking for a simple, scalable Zero Trust solution without the headaches of VPNs, AWS Verified Access is worth exploring.
Written by Cloud Engineer: Greg Ke
Greg entered the cloud service industry in 2021, beginning his role as a cloud engineer. He has not only amassed rich experience in the cloud domain but also exhibits a keen interest in learning new technologies. To date, he has assisted over 100 clients in solving their problems. Greg’s career objective is to become an exceptional cloud security engineer, contributing significantly to the cloud security of enterprises. In his spare time, he leverages his expertise to run algorithmic trading through the cloud.
