Imagine you're building a new, high-security office for a global investment firm. You wouldn't build it in the middle of a public park. You'd buy a private piece of land, put up a fence, and install a security gate. In the world of Amazon Web Services (AWS), this private, fenced-off area is called a Virtual Private Cloud (VPC).

A VPC is your own personal data center within the massive AWS infrastructure. It's a space where you control the network, the IP addresses, and who gets in or out. For our firm's virtual desktops, called WorkSpaces, we need this isolation. We'll create a dedicated VPC just for them, ensuring they are separate from other company servers and completely sealed off from the public internet by default.

Now, imagine our private land is in a city prone to power outages. A smart move would be to have two separate buildings, each with its own power grid. If one goes down, the other keeps running. AWS offers a similar concept called Availability Zones (AZs). Each AZ is a distinct data center, or a group of data centers, within a geographic region. They have independent power, cooling, and networking.

To ensure our virtual desktops are always available, we will divide our VPC into smaller sections called subnets. We'll place at least two subnets in two different AZs. This way, if a problem affects one entire data center, the WorkSpaces in the other AZ will be unaffected. Business continues as usual.

One of the most critical decisions is sizing our subnets. Think of it like assigning phone numbers. If you only reserve 100 numbers but hire 200 employees, you're in trouble. In networking, we define the range of available IP addresses using a notation called Classless Inter-Domain Routing, or CIDR block. This looks something like 10.0.0.0/16.

For our 1,200 users, we need plenty of room to grow. A key rule with VPC subnets is that you cannot change their size after they are created. You have to get it right from the start. We'll need two subnets, each capable of holding more than half our workforce, plus extra for system use and future expansion. A /20 subnet in each of our two AZs gives us over 4,000 addresses per subnet, which is more than enough.

Our WorkSpaces need to be secure, so we will place them in private subnets. A private subnet is one that does not have a direct, open connection to the public internet. Think of it as a room with no windows or doors to the outside world. This is great for security, but it creates a problem: how do the virtual desktops get software updates or access online tools?

The solution is a NAT Gateway (Network Address Translation). This service acts as a secure, one-way door to the internet. We place the NAT Gateway in a public subnet, which is a subnet that is connected to the internet. When a WorkSpace in a private subnet needs to fetch an update, its request is sent to the NAT Gateway. The gateway then forwards the request to the internet on its behalf, gets the response, and sends it back to the WorkSpace.

Crucially, the internet cannot initiate a connection back through the NAT Gateway. It only allows traffic to pass if it was first requested from inside the private subnet. This setup gives us the best of both worlds: our virtual desktops are shielded from external threats, but they can still safely access the resources they need from the internet.

With our network foundation designed, we have a secure, resilient, and scalable environment ready for our virtual desktops.