How to give developers full access without exposing anything publicly
By Jae S. Jung
Most breaches and mistakes don't start in production. They start in the places we treat as safe, where the guardrails come down and access controls get relaxed because it's just dev, where only our internal team uses it for development, prototyping, testing, and other pre-production functions.
The problem isn't that teams are careless. It's that non-production infrastructure is rarely given the same architectural discipline as production. Worse, non-production environments are often exposed publicly when they shouldn't be. Production environments need public DNS and accessible endpoints because browsers, mobile applications, and other external interfaces need to reach your APIs. That's expected and necessary. But non-production environments serve a completely different purpose, they exist for internal development, testing, and validation, and they should be closed to the public. Instead, what you typically see is a patchwork of access methods, inconsistent security postures, and infrastructure that doesn't mirror the production environment it's meant to prepare code for. When you finally promote to production, you discover that the security model is fundamentally different, the network topology has changed, and what worked in dev doesn't work in prod.
" Non-production environments are where mistakes are made, and where good infrastructure should quietly prevent them. "
In our earlier discussion on efficient DevOps workflows, we focused on how teams move code quickly through environments, how feedback loops stay tight, and how deployments become routine rather than risky. That's one side of the equation: the declarative model where you define the desired state and the system makes it happen. You declare what you want, the infrastructure applies it consistently, and version control gives you a perfect audit trail of every change.
This architecture focuses on the other side: governance. Efficient DevOps is about declaration and speed, but infrastructure discipline is about governance through guardrails and control. Both are required to scale teams without introducing risk. You need the declarative structure to move fast, but you also need the governance constraints that prevent fast movement from becoming reckless movement. Fast deployments with weak governance create liabilities, while governed infrastructure with slow deployments creates bottlenecks. The goal is to make governance transparent so it doesn't slow teams down, but also doesn't become something teams need to think about or work around. Governance should be enforced by the infrastructure itself, not by policy documents that developers need to remember to follow.
What should non-production infrastructure actually achieve? It must be accessible only from inside the network, with no public-facing API endpoints and no accidental exposure through misconfigured security groups. If you're not in the VPC or connected through an approved path like VPN or Direct Connect, you don't get access. Period. It must mirror production routing patterns so developers aren't guessing whether their code will behave differently in production because the network topology is fundamentally different. The routing logic, load balancing behavior, and request flow should match production as closely as possible. When you promote from staging to production, the only thing that should change is which environment your code is running in, not how the infrastructure handles it.
It must allow multiple services and paths without becoming a tangled mess. One API Gateway should be able to route to multiple backend services based on ports and paths, keeping the architecture clean and the routing logic centralized. As your system grows, adding a new service shouldn't require rearchitecting the entire network layer. And critically, it must require no special behavior from developers. If developers need to change their code, add environment-specific logic, or work around infrastructure limitations to make things work in dev, the infrastructure has failed. The whole point of having non-production environments is to validate that code works before it reaches production, and if those environments require special handling, they're not validating anything useful.
" If developers need workarounds to use your infrastructure, the infrastructure has already failed. "
The architecture is built around a private API Gateway that's accessible only within the VPC. Traffic comes in through VPC endpoints, gets routed through a network load balancer based on port numbers, and then distributed to application load balancers that handle path-based or domain-based routing to the actual services. This creates a clear separation of concerns where the network layer handles where traffic goes and the application layer handles what service processes it. Each layer does one job, and does it well, so when something breaks, you immediately know which layer is responsible.
The goal isn't complexity for its own sake, it's intentional separation of responsibility, which makes the system predictable, debuggable, and easier to secure. Complex systems are fine as long as each piece is simple and does exactly one thing.
The foundation of this architecture is the private API Gateway, which is scoped to the VPC and only reachable from within your network. You can use a public DNS name that points to the API, but the endpoint itself is private. If you're not on the VPC or connected through an approved path, the DNS resolves but the destination is unreachable. This gives you clean, memorable DNS names for your APIs without exposing them to the internet. The DNS is public, but access is controlled at the network layer, so someone outside your VPC can look up the DNS record but can't connect to it. This is intentional because you want normal DNS management and easy-to-remember URLs for your developers, but you don't want the actual endpoints accessible from outside your network.
This eliminates an entire class of security risks. Developers can't accidentally expose APIs publicly through a misconfigured security group, services can't be probed or exploited from the internet, and the attack surface is reduced to what's explicitly allowed within your network. If someone wants access, they need to be on your VPC or connected through a managed path that you control. VPC endpoints handle the connection between the API Gateway and the rest of the infrastructure, keeping traffic within the AWS network backbone and never traversing the public internet. This keeps latency low, avoids data transfer charges for internet egress, and ensures that even internal API calls don't leak information outside your perimeter. Your traffic never leaves AWS's internal network, which means it's not subject to the same risks as traffic that goes out to the internet and back.
The operational benefit here is critical: security posture is enforced by design, not by configuration. It's not something you have to remember to set correctly on every deployment because it's baked into the infrastructure itself. Even if someone misconfigures something, the network-level controls prevent exposure.
Setting up private API Gateway endpoints requires three specific pieces that must all be configured correctly. Miss one, and nothing works. Get two out of three right, and you'll spend hours troubleshooting because the error messages won't tell you which piece is wrong. First, the VPC itself needs DNS resolution and DNS hostnames both enabled. This isn't the default for all VPCs, and without it, the private DNS names for your endpoint won't resolve properly. Check this in your VPC settings before you start setting up endpoints.
Second, when creating the VPC endpoint for execute-api, you need to enable the Private DNS Name option. This setting makes requests to your API Gateway endpoint route through the VPC endpoint instead of attempting to go out to the public internet. If you miss this checkbox, your API calls will fail in ways that aren't immediately obvious, they'll look like network timeouts or DNS failures, and you'll waste time checking security groups and route tables when the actual problem is this one checkbox. Third, the API Gateway resource policy must explicitly allow access from your VPC endpoint. Even with everything else configured correctly, without this policy in place, requests will be denied. The policy needs to reference the specific VPC endpoint ID, you can't use a wildcard, you can't use a CIDR block, you need the exact endpoint ID.
These three requirements work together as a system. All three must be correct for anything to work. When you're troubleshooting, verify all three before assuming the problem is elsewhere. We've seen teams spend days chasing phantom network issues when the actual problem was one misconfigured setting in this chain.
Routing in this architecture happens in two distinct layers, and understanding why this separation exists matters for both performance and maintainability. The Network Load Balancer handles port-based routing, where traffic coming in on port 8080 goes to one set of services and traffic on port 8081 goes to another. This is fast, simple, and operates at the transport layer. The NLB doesn't parse HTTP headers, doesn't inspect paths, and doesn't care about application logic, it just routes packets based on port numbers, which makes it extremely fast and extremely reliable.
Once traffic reaches the appropriate Application Load Balancer, the application layer takes over. The ALB inspects HTTP requests, examines paths and domains, and routes to specific services based on those patterns. Traffic to /hello goes to one EC2 instance, traffic to /world goes to another, and traffic to /payment and /order might go to different services on different ports. The ALB understands HTTP semantics and can make intelligent routing decisions based on the content of the request. This separation keeps routing predictable and debuggable because if something isn't working, you can immediately narrow down whether it's a network routing problem or an application routing problem. Is traffic even reaching the right load balancer? That's a network issue. Is traffic reaching the load balancer but going to the wrong service? That's an application routing issue. Debugging becomes straightforward instead of a hunt through layers of configuration trying to figure out where things went wrong.
" This separation keeps routing predictable and debuggable across environments. "
The value of this architecture shows up in daily work, not just in security audits or architecture reviews. Developers work exactly as they would in production with the same API calls, routing logic, and network behavior. There's no special localhost setup, no environment-specific configuration that only works in dev, and no mock endpoints that behave differently than the real thing. When something works in development, you have reasonable confidence it will work in production because the infrastructure is consistent. You're not testing code in one environment and hoping it behaves the same way in a completely different environment.
QA tests real routing scenarios instead of testing against simplified mock endpoints or network paths that don't match production. If there's a routing issue, a load balancer misconfiguration, or a path conflict between services, QA catches it before production. That's the whole point of having staging environments that mirror production, and if staging doesn't actually mirror production, you're not learning anything useful from your testing. Staging becomes a genuine pre-production verification step, not just a checkbox on your deployment process. When you deploy to staging, you're deploying to an environment that matches production's network topology, security posture, and routing behavior, so issues get caught earlier, with less stress, and without the pressure of production downtime hanging over your head.
The quiet win here is that you don't need to undo bad assumptions at deployment time. There's no last-minute discovery that the development setup doesn't work in production because the network is configured differently. The path from development to production is smooth because the infrastructure doesn't change shape along the way. Code that worked in dev actually works in production, not because you got lucky, but because the environments are genuinely consistent.
Security often shows up in developer workflows as friction. VPN connections that time out mid-work, IP allowlists that need constant updating because someone is working from home or traveling, and configuration that differs between local development and deployed environments, requiring developers to maintain two different sets of connection strings and credentials. This architecture makes security largely invisible because there's no public ingress to non-production environments, so there's no risk of accidental exposure. IAM roles and network boundaries enforce access control automatically, and developers don't need to remember security rules or work around them because the infrastructure handles it transparently.
No VPN gymnastics where connections drop mid-work and you lose your train of thought reestablishing the connection. No brittle IP allowlists that break when someone works from a coffee shop or their home office. Access control is handled through AWS IAM and VPC security groups, which are centrally managed and don't require per-developer configuration. If you're in the VPC, you have access. If you're not, you don't. Simple. The best security doesn't announce itself, it doesn't show up as another step in your workflow or another credential you need to manage, it just makes bad things harder and good work easier.
" Good security should disappear into the infrastructure, not show up in tickets. "
The benefits of this architecture extend beyond technical correctness and show up in operations, compliance, and team productivity in ways that compound over time. When non-production environments mirror production, surprises at deployment time drop dramatically. Issues get caught early when they're cheap to fix, not in production when they're expensive, stressful, and visible to customers. The cost difference between fixing a bug in dev versus fixing it in production isn't just the time it takes to fix it, it's the cost of the incident, the reputational damage, the time spent in post-mortems, and the opportunity cost of your best engineers firefighting instead of building.
Code that works in staging actually works in production because the infrastructure is consistent. There's no guesswork about whether network behavior will change, whether routing will work differently, or whether security controls will suddenly block legitimate traffic. Deployments become routine instead of risky. When auditors or security teams review your infrastructure, you can confidently say that non-production environments are locked down, that access is controlled through IAM, and that there's no public exposure. You don't need to explain why dev has weaker security than production, because it doesn't. That clarity is worth its weight in audit fees and the peace of mind that comes from knowing your security posture is actually defensible.
New team members can start working without needing to understand complex network setups, learn environment-specific workarounds, or maintain different configurations for different environments. The infrastructure is consistent, the patterns are clear, and the documentation doesn't need to explain special cases. They can focus on learning your business logic instead of learning your infrastructure quirks. And perhaps most importantly, you have confidence that non-production stays non-production. There's no risk that a development environment accidentally becomes publicly accessible or that testing traffic leaks into production systems. The boundaries are enforced by architecture, not by policy documents that someone might forget to follow.
This aligns with the WAM DevTech philosophy around calm systems. Infrastructure should be predictable, it should exhibit consistent behavior, and it should not introduce surprises or require constant attention. When things go wrong, the problem should be obvious, and the fix should be clear. You shouldn't need to be an expert in your infrastructure to understand why something broke.
The best infrastructure rarely gets noticed. It doesn't announce itself with complex dashboards or extensive documentation, it simply makes mistakes harder, progress smoother, and production calmer. Nobody celebrates the incident that didn't happen or the deployment that went smoothly. Private API infrastructure for non-production environments is one of those invisible backbones. When it's done well, developers don't think about it, security teams don't worry about it, and operations teams don't get paged about it. It just works, quietly enforcing good practices and preventing entire classes of problems before they happen.
This is the kind of infrastructure discipline that separates mature engineering organizations from ones that are constantly firefighting. It's not flashy, it's not something you demo to customers or put in marketing materials, but it's the foundation that lets teams move quickly without accumulating risk. It's what makes the difference between a team that ships reliably and a team that's always one bad deploy away from a crisis. At WAM DevTech, this is the kind of invisible backbone we focus on. We build systems that let teams move fast without introducing risk, that enforce security without creating friction, and that scale gracefully without requiring constant attention. Because the best infrastructure is the kind you never have to think about.
Jae S. Jung is the founder and CTO of WAM DevTech, a consulting and development firm specializing in cloud architecture and legacy system modernization for enterprise-scale organizations and government contractors. With over 25 years of experience building and leading distributed development teams across North America, Europe, South America, and Asia, he helps organizations navigate the intersection of technical infrastructure and operational effectiveness at scale.
