When a client approached us with a legacy web application that was under frequent attack, the challenge was clear: protect the admin panel without rewriting the entire system — and do it on a constrained budget. The solution we engineered was pragmatic, effective, and leveraged AWS infrastructure in a way that delivered enterprise-grade security without enterprise-grade costs.

This post breaks down the exact approach we took, why we chose it, and how a similar strategy can protect your business-critical applications from unauthorized access.

The Problem: A Legacy Application Under Siege

The project was a mature web application — what the industry calls "legacy." It had been in production for years, built on older frameworks, and carried the kind of technical debt that makes modern security hardening extremely difficult. The application was hosted on AWS EC2 and served both public-facing users and internal administrators through the same deployment.

This single-deployment architecture meant that the admin panel — the most sensitive part of the system — was exposed to the public internet. Attackers knew it. The client was experiencing repeated intrusion attempts, including brute-force login attacks, credential stuffing, and probing for known vulnerabilities in the legacy stack.

Patching every vulnerability in a legacy codebase is a massive undertaking. The client's budget didn't allow for a full security audit and remediation of the application layer. We needed a solution that would eliminate the attack surface rather than try to armor it piece by piece.

The Constraint: Limited Budget, Maximum Impact

Budget limitations are a reality in every project, but they're especially acute with legacy systems. The client needed a solution that:

  • Could be implemented quickly without major code changes
  • Didn't require expensive third-party security tools or managed services
  • Provided a meaningful, measurable reduction in attack surface
  • Used infrastructure the client was already paying for (AWS)

We needed to think architecturally, not just tactically. Instead of adding more locks to a door that attackers kept finding, we decided to remove the door from public view entirely.

The Solution: Dual Deployments with AWS VPN

Our approach was straightforward in concept but required careful execution. We split the application into two separate deployments on AWS EC2:

1. The Public Deployment

This instance served the public-facing application — everything end users needed to interact with. Critically, we completely disabled and removed access to the admin panel on this deployment. There were no admin routes, no login pages, no endpoints that could be probed. From an attacker's perspective, the admin panel simply didn't exist.

This single change eliminated the most targeted attack vector overnight. Brute-force attempts against admin login pages dropped to zero — because there was nothing to target.

2. The Private Deployment

The second EC2 instance hosted the full application, including the admin panel. However, this instance was not accessible from the public internet. Instead, we placed it inside a private subnet and configured access exclusively through AWS Client VPN.

Only authorized team members with valid VPN credentials could connect to the private network and reach the admin interface. This meant that even if an attacker knew the admin panel existed somewhere, they couldn't reach it without first authenticating through the VPN — a completely separate security layer that the legacy application's vulnerabilities couldn't bypass.

How AWS Client VPN Fit the Architecture

AWS Client VPN was the right choice for several reasons:

  • Cost-effective: AWS Client VPN charges are based on active connections and subnet associations, making it affordable for small teams.
  • Native integration: It works seamlessly with VPCs, subnets, and security groups — no third-party configuration headaches.
  • Certificate-based authentication: We implemented mutual TLS authentication, ensuring that only devices with the correct certificates could establish a VPN connection.
  • Granular access control: Network-level security groups restricted traffic so that even within the VPN, users could only access the specific resources they needed.

Implementation: Step by Step

Here's a condensed view of the implementation process for technical decision-makers evaluating this approach:

Step 1: Network Architecture

We restructured the VPC to include both a public subnet (for the user-facing deployment) and a private subnet (for the admin deployment). The private subnet had no internet gateway attached — it was completely isolated from inbound public traffic.

Step 2: Deployment Separation

We created deployment configurations that allowed us to build two versions of the application from the same codebase. The public build excluded all admin modules, routes, and assets. The private build included everything. This was managed through environment variables and build flags, keeping the process maintainable without forking the codebase.

Step 3: VPN Configuration

We provisioned an AWS Client VPN endpoint associated with the private subnet. Certificates were generated using AWS Certificate Manager and distributed securely to authorized administrators. Connection profiles were configured for the client's team with detailed instructions for setup on macOS, Windows, and Linux.

Step 4: Security Group Hardening

The private EC2 instance's security group was configured to accept traffic only from the VPN's CIDR range. No SSH from public IPs, no HTTP/HTTPS from the open internet. We also maintained strict egress rules to limit the instance's outbound communication to only the services it required (database, internal APIs, and AWS services).

Step 5: Monitoring and Logging

We enabled VPN connection logging through CloudWatch to maintain an audit trail of every admin session. This gave the client visibility into who accessed the admin panel, when, and from which endpoint — critical for compliance and incident response.

The Results

The impact was immediate and significant:

  • 100% reduction in admin panel attack attempts — the public deployment simply had no admin surface to attack.
  • Zero unauthorized access incidents since implementation — the VPN layer added authentication that was completely independent of the legacy application's own security.
  • No disruption to end users — the public-facing application continued to operate exactly as before.
  • Minimal ongoing cost — the additional EC2 instance and VPN endpoint added a modest, predictable line item to the AWS bill, far less than the cost of a security breach or a full application rewrite.
"The most effective security measure isn't building higher walls — it's ensuring attackers can't find the door. By removing the admin panel from public access entirely, we eliminated the attack vector rather than trying to defend it."

When This Approach Makes Sense

This dual-deployment strategy isn't a universal solution, but it's highly effective in scenarios that many businesses face:

  • Legacy applications where comprehensive security hardening isn't feasible within budget or timeline constraints
  • Small to mid-sized teams where admin access is limited to a known group of users
  • Compliance-sensitive environments where segregating administrative access is a requirement
  • Businesses already on AWS that want to leverage existing infrastructure investments

If your application is modern and well-maintained, you might solve this problem with robust application-layer security, WAF rules, and IP whitelisting. But when you're dealing with a legacy system that can't easily be patched, architectural isolation is often more reliable and cost-effective than code-level fixes.

Key Takeaways for Decision-Makers

Security doesn't always require massive budgets or complete rewrites. Sometimes the smartest move is to rethink the architecture:

  • Separate your attack surfaces. If your admin panel doesn't need to be public, don't make it public.
  • Use network-level isolation. VPNs and private subnets provide a security layer that application vulnerabilities can't bypass.
  • Work with what you have. AWS-native tools like Client VPN, private subnets, and security groups are powerful, affordable, and already available in your account.
  • Prioritize impact over perfection. A focused, well-executed architectural change can deliver more security value than months of incremental patching.

We specialize in solving exactly these kinds of problems — finding practical, high-impact solutions for real-world constraints. Whether you're managing a legacy system, planning a migration, or building something new, our team brings the engineering depth and strategic thinking to protect and scale your product.