What a firewall does in cloud apps and why you still need one

TL;DR — A firewall is the traffic gate in front of your systems: it decides which network connections are allowed in or out based on rules like source, destination, port, and protocol. Cloud apps still need firewalls because “running in the cloud” does not automatically mean “only the right things can reach it”; the most common fix is to allow only the traffic your app actually needs and block everything else by default. Reading time: ~7 min

What it is and where it sits

A firewall is a control point that filters network traffic (data moving between systems). It sits between one network zone and another — for example, between the public internet and your app server, or between your app server and your database.

In plain terms, it answers questions like:

• Can anyone on the internet open a connection to this server?
• Can this app server talk to the database on port 5432 (the default Postgres port)?
• Should SSH (remote admin login) be allowed from everywhere, or only from your office VPN?

What talks to it

Typical things that send traffic through a firewall:

• Web browsers hitting your website over HTTPS (encrypted web traffic)
• Mobile apps calling your API
• App servers talking to databases
• Admin tools connecting over SSH or RDP (remote desktop)
• Background jobs calling third-party APIs

What it replaces — and what it does not

A firewall partly replaces the old idea of “hard outer walls around one office network.” In cloud systems, your app may be spread across managed services, containers, virtual machines, and hosted databases. There often is no single office-style perimeter anymore.

But a firewall does not replace:

• App login and permissions
• TLS certificates (identity for encrypted connections)
• Secure coding
• Backups
• Monitoring

Think of it as one layer in a stack: it blocks unwanted network paths before the application even gets a chance to respond.

Where it lives in a typical cloud request flow

In 2026, a firewall may live in several places at once:

• At the cloud network edge, as security rules on a load balancer or gateway
• On a virtual machine, as host firewall rules (for example, ufw on Ubuntu or iptables/nftables underneath)
• In front of a managed database, as network access rules or allowed IP lists
• Between internal network segments, controlling east-west traffic (traffic between your own systems)

A common flow looks like this:

[Customer Browser] ---- 1. HTTPS 443 ----> [CDN/WAF]
[CDN/WAF] ---- 2. HTTPS 443 ----> [Load Balancer]
[Load Balancer] ---- 3. HTTPS 443 ----> [App Server]
[App Server] ---- 4. Postgres 5432 ----> [Database]
                       |
                       | 5. SSH 22 from admin VPN only
                       v
                  [Admin Laptop]

In that flow:

• A web application firewall, or WAF (HTTP-aware filter), may inspect web requests.
• A network firewall controls whether connections are allowed at all.
• The database should usually accept traffic only from the app server, not from the whole internet.

That last point is where many cloud incidents start: the app is hosted correctly, but a database, admin port, or internal service is left reachable from anywhere.

How it actually works

At a practical level, a firewall compares each connection attempt against rules.

Those rules usually include:

• Direction: inbound or outbound
• Source: where traffic comes from, often an IP address or network range
• Destination: where it is going
• Port: which service it wants, like 443 for HTTPS or 5432 for Postgres
• Protocol: TCP or UDP (two common network transport methods)
• Action: allow or deny

Most modern firewalls are stateful (they remember an allowed connection and automatically allow the reply traffic back). That matters because you usually allow “new inbound HTTPS connections to the app,” and then the return packets are permitted automatically.

One realistic example: protecting a cloud-hosted app and database

Imagine your company has:

• A public website at app.example.com
• One app server running Nginx and your application
• One Postgres database
• One admin who occasionally logs in over SSH

You want customers to reach the website, but you do not want the database or SSH exposed to the public internet.

Step by step, here is what happens.

1. A customer opens https://app.example.com in their browser.
2. DNS (the internet’s address book) points the name to your CDN or load balancer.
3. The firewall in front of the app allows inbound TCP port 443 from anywhere, because this is your public website.
4. The load balancer forwards the request to the app server.
5. The app server needs data, so it opens a connection to the database on port 5432.
6. The database firewall checks the source. It allows port 5432 only from the app server’s private network or security group, so the query succeeds.
7. Meanwhile, an attacker scans your IP range and tries to connect directly to port 5432 from the internet.
8. The database firewall sees the source is not the app server and drops or rejects the connection.
9. The attacker also tries SSH on port 22. Your host firewall allows SSH only from your admin VPN IP range, so that attempt is blocked too.
10. Your admin connects from the VPN, and SSH is allowed.

The key idea: the firewall is not “securing the app code.” It is shrinking the number of network doors that exist at all.

Without those rules, your cloud app may still “work,” but it works with too many reachable paths:

• Database reachable from the internet
• Admin login reachable from everywhere
• Internal services reachable across environments
• Outbound traffic unrestricted, which can matter during malware or account compromise

When to use it (and when not to)

You should think in terms of exposure: what is reachable, by whom, and on which ports.

You probably do not need this if...

• You do not run servers, databases, or private network services at all.
• Your entire product is a third-party SaaS, and your role is only user administration.
• Your hosting platform fully abstracts the network layer and gives you no firewall controls; in that case, use the controls it does expose, such as private services, IP restrictions, or environment isolation.

Even then, the concept still matters. If your agency is building or integrating anything custom — app server, API, managed database, VPN, background worker, file transfer endpoint — firewall decisions are part of the design.

Trade-offs

A firewall is usually worth having, but it is not free.

The honest downsides

• Complexity: Someone has to know which ports and sources are truly needed.
• Downtime risk: A wrong rule can block real users or your own team.
• Latency: Usually small, but every extra hop or inspection layer adds some delay.
• Cost: Some cloud network controls, gateways, or advanced filtering features cost extra.
• False confidence: A firewall helps a lot, but it does not fix weak passwords, app bugs, or stolen API keys.

A good rule of thumb: use the simplest rule set that clearly matches your architecture. “Allow what is needed, deny the rest” is better than hundreds of clever exceptions nobody understands.

In practice

Below are two examples you can adapt today. Start in your provider’s dashboard if you have one: look for areas named Network, Security, Firewall, Security Groups, Access, or Database connectivity. In many dashboards, the practical task is: edit inbound rules, edit outbound rules, and limit database access to app sources only.

Example 1: Ubuntu server with UFW

If your app runs on an Ubuntu VM, ufw (Uncomplicated Firewall) is a common host firewall.

⚠️ If you enable firewall rules on a remote server before allowing SSH from your admin IP or VPN, you can lock yourself out and cause downtime.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable
sudo ufw status numbered

What it does: denies all inbound traffic by default, allows normal outbound traffic, opens web ports 80 and 443 to the public, and allows SSH only from one admin IP. Gotcha: if your office or home IP changes often, that SSH rule will stop working until you update it.

Example 2: Postgres listening only to the app network

For a self-managed Postgres server, combine firewall rules with Postgres’s own client allow list.

# postgresql.conf
listen_addresses = '10.0.2.15,127.0.0.1'

# pg_hba.conf
host    appdb    appuser    10.0.1.0/24    scram-sha-256
host    all      all        0.0.0.0/0      reject

What it does: Postgres listens only on the server’s private IP and localhost, then allows the app subnet 10.0.1.0/24 to connect as needed while explicitly rejecting everyone else. Gotcha: if your app servers move to a different subnet during scaling or migration, connections will fail until you update both network and Postgres rules.

Example 3: Nginx only on HTTPS, app not directly exposed

If Nginx is your public entry point, your application process itself should often listen only on localhost or a private interface.

server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

What it does: Nginx accepts public HTTPS and forwards requests to an app process on 127.0.0.1:3000, which is reachable only from the same server. Gotcha: if the app is accidentally bound to 0.0.0.0:3000 and your firewall allows that port, you may expose the app directly and bypass Nginx.

Further reading

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• The "Securing your web application" and reverse proxy sections of the Nginx docs
• The "Client Authentication" and pg_hba.conf sections of the PostgreSQL documentation
• Ubuntu Server Guide: UFW
• The "HTTP access control (CORS)" and "HTTP overview" sections of the MDN HTTP docs

This article was written by an AI system and published pending human review. Verify anything you intend to act on.