A firewall in cloud computing is a virtual control that filters network traffic to and from your cloud resources - not a physical appliance you rack, but a software service the provider runs. In practice it takes two main shapes: security groups (per-resource rules attached directly to your instances, the workhorse of cloud networking) and cloud firewall services / FWaaS (broader, network-level filtering that can inspect traffic more deeply). The mental shift from on-premise is that the firewall is software-defined, follows your resources automatically, and is configured with rules and APIs rather than cables. Where you put the rules - at the instance or at the network edge - is the decision that matters.
People coming from on-premise picture a firewall as a box between the internet and the servers. In the cloud there is no box - the firewall is a set of rules that travels with your resources, and understanding that changes how you design it.
Table of contents
- What a cloud firewall actually is
- Security groups: the per-resource workhorse
- Network firewalls and FWaaS
- North-south vs east-west traffic
- Where the rules belong
- How this fits the rest of the stack
- FAQ
What a cloud firewall actually is
In the cloud, the firewall is virtualised. Instead of a dedicated hardware appliance sitting inline, the provider runs filtering as a software service integrated into the network fabric. That has consequences worth internalising:
- It is software-defined. You configure it with rules, a console, or an API - no physical access, no cabling.
- It follows your resources. A rule attached to an instance applies wherever that instance runs; you are not protecting a location, you are protecting a resource.
- It scales with you. Spin up ten more instances and the same rules apply automatically, no new hardware.
The filtering job is the same as always - decide which traffic is allowed based on source, destination, port, and protocol. What changed is that the firewall is now a configuration object, not a device, and that is what makes it flexible and, occasionally, easy to misconfigure at scale.
Security groups: the per-resource workhorse
The firewall you will use most in the cloud is the security group - a set of rules attached directly to an instance (or a group of them).
- They are stateful: allow an inbound request and the response is automatically allowed back out, so you write fewer rules.
- They are usually default-deny inbound: nothing gets in unless a rule permits it. You open exactly the ports your service needs - 443 for HTTPS, 22 for SSH from your IP - and nothing else.
- They attach to resources, so protection travels with the instance rather than a network segment.
Security groups are where most day-to-day cloud firewalling happens. The discipline is the same as any firewall: open the minimum, restrict sources where you can (SSH from your office IP, not the whole internet), and review what is open. Most cloud exposure incidents are a security group left far more open than it needed to be.
Network firewalls and FWaaS
Security groups protect individual resources; broader tools protect the network:
- Network ACLs / subnet-level rules filter traffic at the subnet boundary - a coarser, stateless layer beneath security groups, useful for blanket rules across everything in a subnet.
- Cloud firewall services / FWaaS (Firewall-as-a-Service) sit at the network edge and can do more than port filtering - deep packet inspection, threat intelligence, application-layer rules, centralised policy across many accounts.
The distinction that matters: security groups are great at “which ports are open on this instance” but do not inspect the content of allowed traffic. A managed cloud firewall / FWaaS adds that deeper inspection and centralised control, at more cost and complexity. Smaller setups live entirely on security groups; larger, regulated, or multi-account environments add a network-level firewall on top for the inspection and central policy.
North-south vs east-west traffic
A concept that clarifies where to put firewall rules is traffic direction:
- North-south - traffic between your cloud and the outside world (users hitting your app, your app calling an external API). This is what most people think of as “the firewall” - the boundary with the internet.
- East-west - traffic between your own resources inside the cloud (the web tier talking to the database, services calling each other).
The old model protected north-south heavily and trusted everything inside. Modern practice does not: a compromised web server should not have free rein to reach every internal resource. Security groups are ideal for east-west control - the database’s security group allows connections only from the web tier’s security group, nothing else. Locking down east-west traffic with tight security groups limits the blast radius when one component is compromised, which is where a lot of real damage happens.
Where the rules belong
Putting it together, cloud firewall design is mostly about placing each rule at the right layer:
- At the instance (security group): the precise, per-service rules - this app allows 443, this database allows 5432 only from the app tier. This is the bulk of your firewalling and where least-privilege lives.
- At the subnet (network ACL): coarse, blanket rules across everything in a segment.
- At the network edge (cloud firewall / FWaaS): deep inspection, centralised policy, and cross-account control for larger environments.
Start with tight security groups - default-deny inbound, minimum ports, restricted sources, east-west lockdown between tiers. That alone prevents most exposure. Add a network-level firewall when you need inspection or central policy that security groups cannot express. And whichever provider you are on, the firewall is one line item in a larger platform - worth understanding alongside the rest of what the infrastructure costs to run.
How this fits the rest of the stack
Whatever you decide here, the cost of it eventually shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.
Useful related references:
- Cloud Computing Applications Worth Building in 2026
- Cloud Computing Engineer: A More Specific Flavor of Cloud Engineering
- Cloud Managed Firewall: What It Does, What It Doesn’t, When to Use One
- Database network security on RunxBuild
- Getting started with RunxBuild
FAQ
What is a firewall in cloud computing?
It is a virtual, software-defined control that filters network traffic to and from your cloud resources, run as a service by the provider rather than as a physical appliance. It usually takes the form of security groups attached to instances and, for larger setups, network-level cloud firewall services that add deeper inspection.
What is the difference between a security group and a cloud firewall?
A security group is a stateful, per-resource set of rules attached to instances, controlling which ports and sources are allowed - the workhorse of cloud networking. A cloud firewall service (FWaaS) operates at the network edge and adds deeper inspection, application-layer rules, and centralised policy across many resources or accounts.
How do cloud firewalls work?
They filter traffic based on source, destination, port, and protocol - the same job as any firewall - but implemented in software within the provider’s network fabric. Rules attach to resources and follow them automatically, scale with your instances, and are configured through a console or API rather than physical hardware.
What is the difference between north-south and east-west traffic?
North-south is traffic between your cloud and the outside world (users, external APIs); east-west is traffic between your own resources inside the cloud (web tier to database). Modern practice locks down east-west with tight security groups so a compromised component cannot freely reach everything internal.
Where should I put my cloud firewall rules?
Put precise per-service rules in security groups at the instance level - default-deny inbound, minimum ports, restricted sources, and east-west lockdown between tiers. Use subnet-level network ACLs for coarse blanket rules, and add a network-edge cloud firewall only when you need deep inspection or centralised policy across accounts.