Setting Up A VPC And Firewall In Linode (Akamai)

Your servers are spiking and you need to be able to cope without breaking the bank. Let’s move you to the cloud, where you can deal with your new demand with cost-effective ease.

A Virtual Private Cloud (VPC) is essentially your own private network slice within the cloud, fully isolated from other tenants. Inside a VPC, you get to define your IP address ranges, create public and private subnets, and set up route tables and internet or virtual private gateways to control traffic flows.

Setting up is important. Instead of hosting your servers in a flat network, it’s best to have a VPC (Virtual Private Cloud). This will create a secure environment where it’s much easier to get your servers talking to each other without being at risk of lateral attacks.

Setting Up the VPC

First, select the VPC tab under Networking.

Click Create VPC at the top right.

In the “Create VPC” form, choose your region and give your VPC a meaningful label.

After your VPC is created, you’ll see its dashboard. You’ll want to create separate subnets for the back-end and front-end servers. By putting your public web servers in one subnet and your private database or application servers in another, you keep them neatly separated. This allows you to create separate firewalls to limit access to non-public applications Click Create Subnet.

Label this subnet for the service you plan to deploy on it—for example, backend-service.

You should now see your new subnet listed in the VPC dashboard.

Repeat steps 4–6 for any other services (e.g. frontend-service, monitoring).

When you’re done, your VPC dashboard will list each subnet you created, all ready to have machines attached.

---

Setting Up Firewalls

Firewalls should always follow the basic security principle of least privilege. All inbound traffic should be blocked except for the access you explicitly allow. Here are some example rules you might consider:

Select the Firewalls tab under Networking.

Click Create Firewall at the top right.

Let’s start with your backend firewall:

• Inbound Policy: Drop by default. This means that all incoming connections are blocked unless you explicitly allow them with a rule.
• Leave the “Linodes” (assigned machines) blank for now as we have not yet created them.
• Click Create.

Back in your Firewalls dashboard, we should see your newly created firewall. click the new firewall to open its Rules tab.

Add the rules you need for your backend services:

Rule 1: Allow SSH from Admin

• Label: allow-ssh-from-admin
• Protocol / Port: TCP / 22
• Sources: ADMIN_IP/32

• Action: Accept

  This lets your personal machine SSH into the backend. To find your IP, visit https://whatismyipaddress.com/ and use the IPv4 address. The /32 suffix restricts it to exactly that one IP.

Rule 2: Allow Frontend → Backend (HTTPS)

• Label: allow-https-from-frontend
• Protocol / Port: TCP / 443
• Sources: FRONTEND_SUBNET_CIDR

• Action: Accept

  This lets your frontend instances call your backend over HTTPS.

Rule 3: Allow CI/CD Deployment

• Label: allow-cicd-deployment
• Protocol / Port: TCP / 22
• Sources: CICD_SERVER_IP/32

• Action: Accept

  Your CI/CD runner needs SSH access to deploy new code.

Rule 4: Allow Frontend → Database

• Label: allow-frontend-to-db
• Protocol / Port: TCP / 5432
• Sources: FRONTEND_SUBNET_CIDR

• Action: Accept

  If you’re using PostgreSQL on the default port 5432, this lets your frontend talk to your database.

After adding all required rules, your backend firewall rules tab should look like this:

Click Save Changes to apply.

• Ensure Inbound Policy remains Drop so only your specified rules are allowed.
• Outbound Rules can usually be left empty: most backends don’t need to initiate connections to the Internet directly, so dropping outbound by default prevents accidental data exfiltration.

---

Frontend Firewall

Follow the same steps to create a firewall for your frontend machines:

Rule 1: SSH from Admin

• Label: allow-ssh-from-admin
• Protocol / Port: TCP / 22
• Sources: ADMIN_IP/32
• Action: Accept

Here, you’ll want to allow inbound HTTP (port 80) and HTTPS (port 443) traffic from 0.0.0.0/0 so that your web server is accessible from the Internet.

Rule 2: HTTP (public)

• Label: allow-http
• Protocol / Port: TCP / 80
• Sources: 0.0.0.0/0
• Action: Accept

Rule 3: HTTPS (public)

• Label: allow-https
• Protocol / Port: TCP / 443
• Sources: 0.0.0.0/0
• Action: Accept

Rule 4: Allow database responses

• Label: allow-response-from-backend-pg
• Protocol / Port: TCP / 5432
• Sources: BACKEND_SUBNET_CIDR
• Action: Accept

This lets your frontend accept Postgres traffic from your backend subnet.

You should add rules for each back-end application and its corresponding port.

After adding all needed rules, your dashboard will look like this:

Remember: Inbound policy stays set to Drop—only the ports and sources you explicitly allow will work.

---

Final Tips

• Least Privilege: Only open the ports and source IPs/subnets you absolutely need.
• Review Regularly: When your infrastructure changes (new CI runners, different subnets), update your firewall rules.
• Use Private Subnets: Keep all backend services isolated from the public Internet whenever possible.

With this in place, your Linode VPC and firewalls will be locked down to only the traffic you explicitly allow—and everything else will be dropped by default. Happy deploying!