Struggling with intranet vs. extranet in a cloud interview? Senior DevOps Engineer Darian Vance breaks down real-world implementations, from classic VPNs to modern Zero Trust architectures, to help you ace the question.

“How Do You Implement an Intranet and Extranet?” – An Interview Question That’s Deeper Than It Looks

I remember a frantic Slack message at 8 PM on a Tuesday. A junior engineer, brilliant but green, had just deployed our new internal metrics dashboard. In his rush, he’d used a Terraform module that defaulted to creating a public-facing Application Load Balancer. For about 15 minutes, our sensitive `internal-stats.techresolve.com` Grafana instance, showing real-time revenue and user data, was sitting wide open on the internet. We caught it fast, but my blood ran cold.

That’s why when an interviewer asks, “How do you implement an intranet and extranet?”, they’re not looking for a textbook definition. They’re testing if you understand how to draw secure lines in the sand. They want to know if you can prevent my 8 PM panic attack. This isn’t just about terminology; it’s about architecture, security, and trust in a world where the “office network” is a relic of the past.

First, Let’s Address the “Why”

At its core, this problem is about defining and enforcing boundaries. In the cloud, we don’t have a server room with a locked door. Our perimeter is a complex mesh of VPCs, subnets, security groups, and identity providers. The goal is simple, but the execution is nuanced:

• Intranet: Create a private space for “us”—our employees, our internal tools, our non-public services. Only trusted employees should be able to access things like the internal wiki, CI/CD pipelines (e.g., `jenkins.techresolve.local`), or direct database admin tools.
• Extranet: Create a semi-private, highly controlled space for “them”—trusted partners, vendors, or specific clients who need limited access to a subset of our resources. For example, allowing a partner’s data processing service to securely push files to an S3 bucket or call a private API endpoint.

The challenge is that “us” and “them” are all connecting from the public internet. Our job is to build the digital walls and checkpoints to let the right people in and keep everyone else out. Here are three real-world ways we do it.

Solution 1: The Fortress & Drawbridge (The Classic VPN)

This is the tried-and-true method, the one most people think of first. You treat your cloud environment (your VPC) like a medieval castle. You build high walls (Security Groups, Network ACLs) and then provide a single, heavily guarded point of entry: the VPN gateway.

How It Works:

You deploy a VPN server or use a managed service like AWS Client VPN. An employee (or a trusted contractor) on their laptop initiates a connection using a VPN client and a security certificate. Once authenticated, their laptop is issued a private IP address from within your VPC’s address space. To all the services inside the VPC, it looks like the user’s traffic is coming from a trusted, internal machine.

This is a great solution for giving your internal team access to resources that should have zero public exposure, like SSH access to bastion hosts or direct connections to a Redis cache on `prod-cache-01`.

Pro Tip: Managing individual client certificates for a large team is a special kind of hell. It’s error-prone and doesn’t scale. Whenever possible, integrate your VPN with your single sign-on (SSO) provider like Okta or Azure AD. This ties network access to user identity, which is a much cleaner model.

Solution 2: The Diplomatic Tunnel (VPC Peering & Transit Gateway)

This is my go-to for the “extranet” problem, especially when dealing with another company that also has a cloud presence. Let’s say we have a partner who needs to send us data directly from their application servers in their own AWS account to our Postgres database `prod-db-01`.

How It Works:

Instead of making them connect over the public internet, we create a private, secure link between our networks. We use services like VPC Peering (for a simple 1:1 connection) or AWS Transit Gateway (for a more complex hub-and-spoke model with multiple partners).

This allows traffic to flow between our VPCs over Amazon’s private backbone network. The key here is surgically precise firewall rules. We don’t just open the floodgates. We write a Security Group rule that says: “Only allow traffic from the partner’s VPC CIDR range (`172.20.0.0/16`) to port `5432` on this specific database instance.”

# Example Terraform for a highly specific Security Group rule
resource "aws_security_group_rule" "allow_partner_db_access" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  source_security_group_id = "sg-partner-app-servers" # Better than CIDR if possible!
  security_group_id        = aws_security_group.prod_db_sg.id
  description              = "Allow Partner App Servers to access Postgres"
}

Warning: The biggest “gotcha” with VPC Peering is overlapping CIDR blocks. Before you agree to peer, you MUST confirm that your partner’s private IP address range doesn’t clash with yours. Debugging routing issues caused by overlapping CIDRs is a nightmare you want to avoid at all costs.

Solution 3: The Bouncer at the Door (Identity-Aware Proxy / Zero Trust)

This is the modern approach and the one that will impress a forward-thinking hiring manager. The philosophy here is “Zero Trust,” which means we don’t automatically trust traffic just because it’s coming from inside our network. We authenticate and authorize every single request at the application layer.

How It Works:

Instead of a VPN, we place a service like Google’s Identity-Aware Proxy (IAP), Cloudflare Access, or AWS Verified Access in front of our internal web applications. The application itself (e.g., `metabase.internal.techresolve.com`) has no public IP address. Its security group blocks all inbound traffic.

When a user tries to access the URL, they are first redirected to our SSO provider (Okta, Google, etc.). They log in, and if their identity is verified (and maybe their device posture is checked), the proxy generates a signed header and forwards their request to the application. The user gets seamless access without ever touching a VPN client, and our application’s attack surface is virtually zero.

This is perfect for providing a contractor access to a single tool without giving them broad network access, or for giving all our remote employees a simple, secure way to reach internal dashboards.

Which One Do You Choose?

The “right” answer depends on the context. In a real-world environment, we use a mix of all three. Here’s a quick cheat sheet:

So, the next time you get this question in an interview, don’t just give a definition. Tell a story. Talk about trade-offs. Show them you’re not just someone who has read the manual, but someone who knows how to build the walls, guard the gates, and most importantly, how to avoid that 8 PM panic call.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions