# Crafting a Resilient VPC Landscape using Terraform

Last week, [we released our Virtual Private Cloud](https://buildwithtalia.com/introducing-akamais-virtual-private-cloud) (VPC). Akamai’s VPC offers an isolated network that lets cloud resources privately communicate with each other.

What excites me about this release is the flexibility you have in setting up your VPC. You can add compute instances via your cloud provider’s UI, Cloud Manager, developer tools like a CLI, or my personal favorite, infrastructure as code tools like Terraform. In this blog, I’ll take you through the journey of deploying a VPC and dynamically adding subnets using Terraform.

I chose Terraform because you can see all of your configurations for your application in one place, allowing you to replicate resources in another environment, move resources to different accounts, etc. It’s essentially your one source of truth, eliminating configuration drift. If you’re new to Terraform or infrastructure as code, [this video](https://www.youtube.com/watch?v=sF3iY74JpVI&t=1s) guides you through creating a compute instance with the Linode Terraform Provider. That should get you on the right track to continue with this tutorial.

## Prerequisites

Before we begin, make sure you have the following:

1. A Linode account. If you don't have one, sign up for a [free Linode account](https://www.linode.com/).
    
2. A personal access token for Linode’s [v4 API](https://www.linode.com/docs/api/): Terraform uses this to interact with your Linode resources. Follow this guide to [generate your token](https://www.linode.com/docs/products/tools/api/get-started/).
    
3. Terraform installed on your local machine. If you don't have it, follow our [guide to installing and setting up your environment](https://www.linode.com/docs/guides/how-to-build-your-infrastructure-using-terraform-and-linode/).
    
4. Basic knowledge of how to use the command line.
    

## Step 1: Create your Terraform Configuration File

Let’s start by setting up the Linode Provider for Terraform. I created a new directory for my Terraform project and made a file called `terraform.tf`. Instead of building the configuration file from scratch, I utilized the Terraform registry. If you’ve never used an infrastructure as code registry, watch [this video](https://www.youtube.com/watch?v=hEv-el6Pm5A) to learn more.

First, find the [Linode VPC](https://registry.terraform.io/providers/linode/linode/latest/docs/resources/vpc) from the Terraform Registry. On the right hand side of the page, click on Use Provider, and copy the code from the dropdown into your `terraform.tf` file. Then, copy and paste the code from the Example Usage section for the VPC.

![](https://lh7-us.googleusercontent.com/BJwLeC1W2upI8CK1s6RdGoyicMv5_x7IBVdw6RIUmpgjRPNV6uYEXGfBlY8hYJNoY2z00FLQc0P9f-UoUVW6TEJ0tN88IdcZy1vX9oHAvZVpPP3FnoeUZKQV-CLsqz5FqEWrgOUu8g6MeJmEerDDrIk align="left")

Your configuration file should look like this:

*Note that you’ll need to replace your authorized key and root password as well.*

```plaintext
terraform {
  required_providers {
    linode = {
      source = "linode/linode"
      version = "2.13.0"
    }
  }
}

provider "linode" {
  token = "your_api_token"
}

resource "linode_vpc" "test" {
    label = "test-vpc"
    region = "us-iad"
    description = "My first VPC."
}
```

## Step 2: Deploy your Configuration File

To deploy your configuration file, enter: `terraform plan`

Then, enter: `terraform apply`

![](https://lh7-us.googleusercontent.com/cqDa7bHZW4APzKSlmsob4nHTj6Njg1a1zgh1r4nE5Uyf5Q0xvig7qIFEHQW-F-M900bDHYVa-nD8v0c0Kb1tCBAvNHeEKEx5BoW0YOa-vZa8xYAn7KbvzDe2AGfNc264CqvvDnUdu1l1j3C8JaNTv8g align="left")

Now, when you go to your cloud dashboard, you’ll see your VPC listed.

![](https://lh7-us.googleusercontent.com/_BWuSnJ5cWHz2VOKxEOAuOH9ZB4i5WS2O2VoSGCYby3SqH12eodrx3PWfrNDS7rNRKbmddt5YlzjuyXKyQP8mIEYjnxkEgQNexeBa8mf10aMr5uhlBF6LuSfop9tImi1iaX2uusQ7gWQ4QQKqOwmu0w align="left")

Using Infrastructure as Code for deploying a VPC provides greater control, consistency, agility, and efficiency in managing your cloud infrastructure while reducing the likelihood of human error and enabling faster, more reliable deployments.

## Step 3: Add Subnets to your VPC

Adding subnets to my VPC is an essential aspect of architecting a well-organized, secure, and scalable cloud infrastructure that aligns with the specific needs of my applications and services. By adding subnets, I can logically segment my VPC into smaller, more manageable networks. This segmentation is beneficial for organizing resources based on functionality, security needs, or other considerations. For instance, I might have separate subnets for web servers, databases, and application components.

Subnets also allow me to efficiently manage IP addresses within my VPC. Each subnet operates within its designated IP address range, preventing conflicts and providing a structured approach to IP address allocation. This becomes increasingly important as my infrastructure scales and more resources are deployed.

Subnets act as security boundaries, enabling me to implement different security measures for each subnet based on the sensitivity of the resources they host. For example, I can apply stricter security rules to a database subnet compared to a public-facing web server subnet. This helps in implementing the principle of least privilege.

Subnets play a crucial role in routing and optimizing network traffic within the VPC. I can configure routing tables to direct traffic between different subnets based on specific requirements. This flexibility allows me to design the most efficient communication paths for my applications.

Now, let’s add a couple subnets to the VPC. Edit your `terraform.tf` and add a `vpc_subnet` resource block.

*Note that you’ll need to replace your vpc\_id. Find this in your cloud dashboard below.*

![](https://lh7-us.googleusercontent.com/FSD-Rq80OgEI7NCt9vblWQtPieVwWc1XG9X3Skn8VVMFsoZbTj6xhJVAJqJQoT_2kmFMemy0-kjACE0mBiLixUEhM9s78YelZbUOgbscKIsvB4dK2iIYWchiwYvfrJHsp43jCmbLnGz2tzAuRrC8VJM align="left")

```plaintext
resource "linode_vpc_subnet" "vpc-subnet-terraform-subnet-01" {
    vpc_id = "your_vpc_id"
    label = "vpc-subnet-terraform-subnet-01"
    ipv4 = "192.168.1.0/24"
}

resource "linode_vpc_subnet" "vpc-subnet-terraform-subnet-02" {
    vpc_id = "your_vpc_id"
    label = "vpc-subnet-terraform-subnet-02"
    ipv4 = "10.0.0.0/24"
}
```

Run `terraform apply` to apply the changes.

![](https://lh7-us.googleusercontent.com/fYId8pwdRfDx3NtxLmPPhdDmbB3JRIIZt-Atf_ggvdaNkurqpag-QPvToowuV7Yxk_2iFrZW092MB6fBX3twlFZYvbo9Z85cRk38Scja9kFH9RZnGmO1b595PO-NqC5blHKYUbuiD-TjYsdHW6mtn3I align="left")

Now your VPC has 2 subnets. Navigate to the cloud manager to see the changes:

![](https://lh7-us.googleusercontent.com/zFeEyDQadhSx9FoD-ve3adz_pj1n8sI7wMC7qV5VMIyz2sUDryvHdaygqXAgkdDgJZZpygZgeobvhmlekDUchxut8vcFV0ZpWgVAFeZg6-EgdbQUMQ0pJ3c67pNElPkJM1IQGQvxk4y0y2rjMJzi7I4 align="left")

*Notes:*

1. *You should have one* `vpc_subnet` *resource block per subnet*
    
2. *The ipv4 of a subnet within the same VPC must not have any overlap*
    

## Differentiating between Akamai’s VPC and the Hyperscalers

One of the standout features of Akamai's VPC that I find truly remarkable is its flexibility when it comes to defining subnets. In many traditional hyperscalers, such as AWS and Azure, there's a rigid requirement that all subnets within a VPC must share the same [RFC1918](https://datatracker.ietf.org/doc/html/rfc1918#autoid-3) range or block. This essentially means that once you set a top-level CIDR range for your VPC, all subnets within it are confined to that particular address space.

However, Akamai takes a different and, in my opinion, more versatile approach. With Akamai’s VPC, each subnet is allowed to exist in its own RFC1918 range or block. This means that you have the freedom to design your network architecture in a way that best suits your specific use case. For instance, you can have one subnet operating in the 192.168/16 space and another in the 10/8 space, all within the same VPC.

This flexibility is a game-changer, especially as your application or business needs evolve. Unlike the constraints imposed by some hyperscalers, Akamai's VPC enables dynamic addition of subnets with different ranges. So, if your requirements change or your application scales, you can effortlessly integrate new subnets without being bound by the limitations of a predetermined top-level CIDR range. It’s a level of adaptability that caters to the diverse networking demands of modern cloud architectures. This is a feature that sets Akamai's VPC apart, offering a level of customization and scalability that aligns seamlessly with the dynamic nature of today’s cloud environments.

## More Resources

Connect with the Akamai team and fellow users in the [Akamai VPC discussion group](https://discuss.akamai.com/c/beta-program/vpc-beta/57) dedicated to our VPC feature (click [here](https://discuss.akamai.com/) to sign up if you’re not a member).

You can also check out our [VPC documentation](https://www.linode.com/docs/products/networking/vpc/) for more information and help getting started.

Thanks for reading! For all things cloud, follow me by clicking the follow button at the top of this page, subscribe to my newsletter below, and follow me on [Twitter](https://twitter.com/talia_nassi)!