# Secure Infrastructure Design with Private Subnets and Endpoints

> Chapter 19 of the Courseiva AWS-SECURITY-SPECIALTY curriculum — https://courseiva.com/learn/aws-security-specialty/secure-infrastructure-design

**Official objective:** 6.4 — Design and implement secure network infrastructure

## Introduction

Secure Infrastructure Design with Private Subnets and Endpoints. It solves the fundamental problem of how to keep your most sensitive data and servers hidden from the public internet while still allowing them to communicate with the AWS services they need. For the SCS-C02 exam, understanding this concept is critical because the majority of secure infrastructure scenarios on the test demand that you choose an architecture where private resources never touch the internet, and VPC Endpoints are the correct way to enable that communication.

## The Fort Knox Package Delivery Analogy

A bank vault is the most secure place in a building. Its walls are thick, the door is heavy steel, and only authorised employees can walk through the access-controlled entrance. Now imagine the vault also had a secret, tiny mail slot built into one wall, a slot that connects directly to a secure receiving room inside the vault itself. The bank’s main public lobby is the internet-facing network, full of public IP addresses where anyone can try to send a package. The vault is a private subnet, a network segment with no direct routes from the public internet. In a traditional setup, if you wanted to receive a package inside the vault, you would be forced to cut a door into the vault wall and open it to the lobby, effectively exposing the entire vault to the public. This door would be an Internet Gateway, and it would destroy security. 

But the AWS equivalent of a secure, direct mail slot is a VPC Endpoint. A VPC Endpoint allows a resource inside a private subnet, like a database server, to securely reach a specific AWS service, such as Amazon S3 or DynamoDB, without ever leaving the AWS network and without requiring a public IP address. The bank vault never opens a door to the lobby. Instead, the package travels from the sender (AWS service) directly to the vault's own secure mail slot. This eliminates the risk of the package being intercepted, tampered with, or the vault door being left ajar. The bank teller (the application in the private subnet) uses the mail slot to request the package, and it arrives fully inside the security perimeter, untouched by any public network path. This is the essence of private subnet design: secure, controlled communication with the outside world without exposing internal resources to it.

## Core explanation

At its core, secure infrastructure design in AWS is about controlling network traffic. The goal is to place your most valuable assets, your databases, your internal applications, your secret keys, inside a private space where they cannot be reached from the public internet. This private space is a Virtual Private Cloud (VPC), and within that VPC, you create subnets. A subnet is simply a range of IP addresses, but the critical distinction is whether that subnet is public or private. A public subnet has a route to the internet via an Internet Gateway (IGW). A private subnet has no such route. Resources in a private subnet, such as an Amazon EC2 instance (a virtual server), do not get a public IP address. They are invisible from the outside world. This is your first line of defence.

But here is the core problem: a server in a private subnet is not completely isolated. It still needs to do things like download software patches, store files in S3 (Simple Storage Service), send logs to CloudWatch, or authenticate users via AWS Identity and Access Management (IAM). In the old days, the only way to let a private server reach these AWS services was to give it a public IP address or place it behind a NAT (Network Address Translation) gateway. A NAT gateway acts like a private postbox: the server sends a request to the NAT gateway, and the NAT gateway forwards it to the internet using its own public IP, then returns the response. While this works, it exposes the server to the public internet during the connection and requires the server to have a route to the NAT gateway, which itself is in a public subnet. This is more secure than a fully public server, but it is still not ideal because the traffic leaves the AWS network and travels over the public internet.

VPC Endpoints solve this problem completely. A VPC Endpoint is a virtual device that allows you to privately connect your VPC to supported AWS services, without requiring an Internet Gateway, NAT device, VPN connection, or a public IP address. Traffic between your VPC and the AWS service never leaves the Amazon network. There are two types of VPC Endpoints: Gateway Endpoints and Interface Endpoints. A Gateway Endpoint is a target for a route in your route table. You set up a route in your private subnet’s route table that sends traffic destined for a specific AWS service, like S3 or DynamoDB, directly to the Gateway Endpoint. This is the simplest and cheapest option because it does not cost extra per hour, only per GB of data processed. An Interface Endpoint is an elastic network interface (ENI) with a private IP address that acts as an entry point for traffic to a specific service. You attach it directly to your subnet. This is used for services like KMS (Key Management Service), CloudWatch Logs, SNS (Simple Notification Service), and many others. Interface Endpoints cost per hour and per GB of data processed.

The security impact is huge. With VPC Endpoints, you can enforce that your S3 buckets, for example, can only be accessed from your specific VPC and never from the public internet. This is done by attaching a bucket policy that denies all access unless the request comes from the VPC Endpoint. You can also use VPC Endpoint Policies to control which specific resources (like particular S3 buckets) the endpoint can access, adding a layer of fine-grained control. Additionally, you can use AWS PrivateLink, which is the underlying technology for most Interface Endpoints. PrivateLink allows you to create your own service endpoints in your VPC that other VPCs can connect to, enabling secure cross-account communication without exposing anything to the internet.

In summary, the architecture is this: place your application servers and databases in private subnets. Use a NAT gateway only if you need your private servers to access the public internet for updates (and many organisations use VPC endpoints for all necessary services to eliminate even this need). Then, for every AWS service your private resources need to reach, create a VPC Endpoint. This gives you the highest level of security because your traffic stays within Amazon’s private network backbone and your resources remain completely invisible to the public internet.

## Real-world context

Let us walk through a realistic scenario. You work for a healthcare company that stores patient medical records in an Amazon RDS (Relational Database Service) database running PostgreSQL. You need to design the infrastructure for a new application that processes these records. The compliance requirements, HIPAA (Health Insurance Portability and Accountability Act), demand that patient data never travel over the public internet and that the database itself is not directly accessible from the internet. Your manager, a senior architect, tells you to design the most secure network configuration.

Your first step is to create a VPC with a CIDR block, a range of IP addresses, such as 10.0.0.0/16. Within this VPC, you create two subnets: a public subnet (10.0.1.0/24) and a private subnet (10.0.2.0/24). You launch an Application Load Balancer (ALB) in the public subnet to handle incoming user requests from the internet. The ALB acts as the front door. You then launch your application servers (EC2 instances) in the private subnet. These servers are configured to only accept traffic from the ALB’s security group, a virtual firewall. The RDS database is also launched in the private subnet and is configured to only accept traffic from the application servers’ security group. So far, so good. The database is hidden.

Now, the application servers need to do several things. They need to store and retrieve images from S3, send log data to CloudWatch, and use AWS KMS to encrypt and decrypt the medical records. Without VPC Endpoints, you would have to launch a NAT Gateway in the public subnet and route the private subnet traffic to the internet. This would mean your EC2 instances, which hold sensitive processing logic, would be making requests that leave Amazon’s network and go out to the public internet to reach S3 and CloudWatch. That violates HIPAA because the data is traversing the public internet, even if it is encrypted.

Instead, you create VPC Endpoints. You create a Gateway Endpoint for S3 and add a route to the private subnet’s route table that points traffic destined for Amazon S3 (the prefix list for the service) to the gateway endpoint. You create an Interface Endpoint for CloudWatch Logs, attaching it to the private subnet with a private IP address. You create another Interface Endpoint for KMS. You also attach a VPC Endpoint Policy to the S3 endpoint that allows only access to a specific bucket, named medical-records-bucket-prod, and denies access to any other bucket. This is a safety measure in case an application server is compromised. On the S3 bucket itself, you add a bucket policy that says, “Allow all actions, but only if the request comes from the VPC endpoint.” Even if someone steals your AWS keys, they cannot access the data from outside your VPC.

The result is a fully private architecture. The application servers in the private subnet never have public IP addresses. Data to S3, CloudWatch, and KMS travels over the AWS backbone, not the public internet. The database is untouched by any public path. This architecture passes the strictest security audits and is exactly the kind of design the SCS-C02 exam rewards. As an IT professional, you would document each endpoint, its associated policy, and the route table changes, and you would use AWS CloudFormation or Terraform to automate the entire setup to ensure consistency across environments.

## Exam focus

The SCS-C02 exam absolutely loves testing VPC Endpoints and private subnet design. Expect at least one scenario question that explicitly asks how to connect a private subnet resource to an AWS service without using an Internet Gateway or NAT Gateway. The correct answer is almost always a VPC Endpoint. The exam also frequently tests the difference between Gateway Endpoints and Interface Endpoints, and you must know which services use which type. You should memorise that S3 and DynamoDB are the only two services that currently offer Gateway Endpoints. Everything else (KMS, CloudWatch, SNS, SQS, etc.) uses Interface Endpoints.

Common question traps include:
- A scenario describing a need to connect from a VPC to an on-premises data centre. The trap answer is a VPC Endpoint, but the correct answer is a VPN Connection or AWS Direct Connect. VPC Endpoints only connect to AWS services, not to your own data centre.
- A scenario that describes a public subnet talking to an AWS service. The trap is adding a VPC Endpoint when a simpler route through an Internet Gateway already works perfectly. VPC Endpoints are only needed when the resource is in a private subnet.
- A question about cost optimisation: Interface Endpoints have an hourly cost and a per-GB data processing fee, whereas Gateway Endpoints have no hourly cost, only data processing fees. The exam may ask you to choose the cheaper option for high-volume S3 access.
- A question asking about security: VPC Endpoint Policies are often tested. The exam will ask how to restrict access from a VPC Endpoint to a specific S3 bucket. The correct approach is to combine a VPC Endpoint Policy that allows only that bucket ARN with a bucket policy that requires traffic to come from the specific VPC endpoint ID.
- A question about PrivateLink: The exam tests that PrivateLink is the technology powering Interface Endpoints and that you can use it to expose your own service securely. The answer choices might confuse AWS Direct Connect, VPC Peering, and PrivateLink. Know that PrivateLink uses ENIs in a VPC to expose a service, and it does not require the two VPCs to have overlapping IP ranges (a common problem with VPC Peering).

Key definitions to memorise for the exam:
- Private Subnet: A subnet with no route to an Internet Gateway.
- VPC Endpoint: A virtual device that enables private connectivity to AWS services.
- Gateway Endpoint: A route table target for S3 and DynamoDB.
- Interface Endpoint: An ENI with a private IP for most other services.
- VPC Endpoint Policy: An IAM-like policy attached to the endpoint to control which resources can be accessed.
- PrivateLink: The underlying service for Interface Endpoints and your own services.

## Step by step

1. **Design the VPC and subnets** — Create a VPC with a non-overlapping CIDR block (e.g., 10.0.0.0/16). Then create at least two subnets: one public (with route to IGW) and one private (without route to IGW). The private subnet will host your secure resources.
2. **Launch your private resources** — Place your EC2 instances, RDS databases, or other sensitive resources into the private subnet. Ensure they do not have public IP addresses assigned. Configure security groups (stateful firewalls) to only allow traffic from trusted sources like a load balancer.
3. **Determine which AWS services your resources need** — Identify every AWS API your private resources will call, such as S3 (for storage), CloudWatch (for logging), KMS (for encryption), or SQS (for queuing). Each service you need will require a VPC Endpoint.
4. **Create VPC Endpoints for each required service** — For S3 and DynamoDB, create Gateway Endpoints and add them as targets in your private subnet’s route table. For all other services, create Interface Endpoints and attach them to your private subnet. Attach a VPC Endpoint Policy to restrict access to specific resources.
5. **Update resource-based policies for defence in depth** — For services like S3 or KMS, add a policy that denies access unless the request originates from your VPC Endpoint. This ensures that even if an IAM user has full permissions, they cannot access the resource from outside your VPC.

## Comparisons

### Gateway Endpoint vs Interface Endpoint

**Gateway Endpoint:**
- Only supports S3 and DynamoDB
- No hourly cost; pay per GB of data processed
- Configured as a route table target

**Interface Endpoint:**
- Supports many AWS services (KMS, CloudWatch, SNS, etc.)
- Has an hourly cost plus per-GB fee
- Configured as an Elastic Network Interface with a private IP

### VPC Endpoint vs VPC Peering

**VPC Endpoint:**
- Connects a VPC to an AWS service
- No overlapping IP address issues with the service
- Does not enable access to resources in another VPC

**VPC Peering:**
- Connects two different VPCs
- Requires non-overlapping CIDR blocks
- Enables resources in one VPC to access resources in the other

### Private Subnet vs Public Subnet

**Private Subnet:**
- No route to an Internet Gateway
- Resources have no public IP by default
- Requires VPC Endpoints or NAT Gateway to reach external services

**Public Subnet:**
- Has a route to an Internet Gateway
- Resources can have public IP addresses
- Can reach AWS services directly via the internet

### NAT Gateway vs VPC Endpoint

**NAT Gateway:**
- Allows outbound internet traffic from private subnets
- Traffic leaves AWS network and goes to the public internet
- Has cost per hour and per GB of data processed

**VPC Endpoint:**
- Allows outbound traffic to specific AWS services only
- Traffic stays within the AWS network
- Gateway Endpoints have no hourly cost; Interface Endpoints have hourly cost

## Diagram

_This diagram shows how an EC2 instance in a private subnet uses VPC Endpoints to access S3 and CloudWatch privately, while user traffic enters through the public subnet via an Internet Gateway and load balancer._

```mermaid
graph TD
    A[Internet] --> B[Internet Gateway]
    B --> C[Public Subnet]
    C --> D[Load Balancer]
    D --> E[Private Subnet]
    E --> F[EC2 Instance]
    F --> G[VPC Endpoint for S3]
    F --> H[VPC Endpoint for CloudWatch]
    G --> I[S3 Bucket]
    H --> J[CloudWatch Logs]
    subgraph AWS Network
        G
        H
        I
        J
    end
    subgraph VPC
        C
        E
    end
```

## Common misconceptions

- **Misconception:** A VPC Endpoint completely replaces all internet traffic, so I do not need a NAT Gateway at all. **Reality:** A VPC Endpoint only works for supported AWS services. If your private resource needs to access the public internet (e.g., to download third-party software updates or reach a non-AWS API), you still need a NAT Gateway or a similar solution. (Beginners see VPC Endpoints as a 'magic fix' for all connectivity, but they are purpose-built for AWS services only.)
- **Misconception:** VPC Endpoints and VPC Peering are two names for the same thing. **Reality:** VPC Peering connects two different VPCs together, allowing resources in one to reach resources in the other. A VPC Endpoint connects a VPC to an AWS service, not to another VPC. (Both involve 'connecting' and 'private networking', leading to confusion. The difference in scope (AWS service vs. another VPC) is a common exam trap.)
- **Misconception:** If I use a VPC Endpoint, the traffic is automatically encrypted. **Reality:** VPC Endpoints provide private connectivity within the AWS network, but they do not automatically encrypt the data in transit. You still need to use TLS/HTTPS for encryption yourself if the service supports it. The endpoint creates a private channel, but the data on that channel is not inherently encrypted. (People confuse 'private' (not over the public internet) with 'encrypted'. They are two separate security controls.)
- **Misconception:** I can put a VPC Endpoint in a public subnet and it works the same as in a private subnet. **Reality:** You can place an Interface Endpoint in any subnet, but the point is to enable private connectivity for private resources. Placing it in a public subnet is pointless because those resources already have internet access through the IGW. The endpoint is designed to avoid that internet path. (Beginners often think the endpoint type (Gateway vs. Interface) is about subnet placement, but it is about cost and service type.)

## Key takeaways

- A private subnet is defined by its route table having no route to an Internet Gateway, not by the IP address range alone.
- VPC Endpoints allow private subnet resources to communicate with AWS services without leaving the Amazon network.
- Gateway Endpoints are free (no hourly cost) and only work for S3 and DynamoDB, using a route table entry.
- Interface Endpoints cost per hour and per GB, and provide a private IP address for each supported service.
- VPC Endpoint Policies can restrict which specific resources (e.g., which S3 bucket) the endpoint can access.
- Combine VPC Endpoint Policies with resource-based policies (like S3 bucket policies) for defence in depth.
- AWS PrivateLink enables you to create your own secure service endpoints for other VPCs to connect to.
- On the SCS-C02 exam, if a question asks for private connectivity to S3 from a private subnet, the answer is a Gateway Endpoint.

## FAQ

**Can I use a VPC Endpoint to connect to the public internet?**

No. VPC Endpoints only connect to supported AWS services like S3, DynamoDB, and CloudWatch. For public internet access, you need a NAT Gateway or Internet Gateway.

**What is the difference between a Gateway Endpoint and an Interface Endpoint?**

A Gateway Endpoint is a route table target used only for S3 and DynamoDB, with no hourly cost. An Interface Endpoint is an Elastic Network Interface with a private IP for other services, and it has an hourly cost.

**Do I need a VPC Endpoint if my EC2 instance is in a public subnet?**

No. Instances in a public subnet can reach AWS services directly via the Internet Gateway without needing a VPC Endpoint. Endpoints are only necessary for private subnets.

**Can I have one VPC Endpoint that works for all AWS services?**

No. Each VPC Endpoint is dedicated to a single service, or a single service endpoint. You must create one endpoint for each service you need to reach privately.

**Is traffic through a VPC Endpoint encrypted?**

The traffic stays within the AWS network, which is private, but the data is not automatically encrypted. You must use TLS/HTTPS at the application layer for encryption.

**What happens if my VPC Endpoint reaches its bandwidth limit?**

Interface Endpoints can scale horizontally up to a certain limit per VPC. You can request higher limits from AWS, or you can create multiple endpoints for the same service and distribute traffic.

## Check your understanding

1. **Which type of VPC Endpoint supports Amazon S3 and has no hourly cost?**

   Answer: A Gateway Endpoint.

2. **What is the primary security advantage of using a VPC Endpoint over a NAT Gateway for accessing AWS services?**

   Answer: Traffic never leaves the AWS network, eliminating exposure to the public internet and reducing the attack surface.

3. **True or False: VPC Endpoints can be used to connect your VPC to an on-premises data centre.**

   Answer: False. VPC Endpoints only connect to AWS services, not to external networks. For on-premises, use VPN or Direct Connect.

4. **What AWS service enables you to create your own service endpoints in a VPC for other VPCs to connect to securely?**

   Answer: AWS PrivateLink.

5. **You need to allow an EC2 instance in a private subnet to send logs to CloudWatch. What should you create?**

   Answer: A VPC Interface Endpoint for CloudWatch Logs, attached to the private subnet, with an appropriate endpoint policy.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-security-specialty/secure-infrastructure-design