Skip to content

Background

Networking model

Every project gets its own private network. Instances talk to each other on it, a router connects it to the internet, floating IPs give chosen instances a public address, and security groups decide which traffic gets through.

The building blocks

Piece What it does On a traditional platform
Network A private layer-2 segment that belongs to your project A VLAN or port group
Subnet An IP range on a network. Hands out addresses by DHCP and tells instances which DNS resolvers to use The VLAN's IP scope and DHCP scope
Router Connects subnets to the external network, and translates private addresses for outbound traffic The default gateway with NAT on the edge firewall
Floating IP A public IPv4 address you attach to one instance; the router maps it to the instance's private address A public IP with a static NAT rule
Security group A set of stateful firewall rules applied to an instance A host firewall, or rules on a distributed firewall
Load balancer One address in front of several instances A hardware load balancer and its virtual IP

The difference from a traditional platform is who builds these. There's no network team to ask for a VLAN or a firewall change: you create networks, attach floating IPs and edit security group rules yourself, through the same API as everything else.

What a new project starts with

Each project gets, in each region it uses, a network called default with a subnet and a router connected to the external network. The project's default security group includes a rule that lets instances on that subnet reach each other.

You can add more networks, for example to keep a database tier apart from a web tier. Creating a network in the Breqwatr Cloud Portal (Strata) creates its subnet and router at the same time.

How traffic flows

From the internet to an instance

  1. A client sends a request to the instance's floating IP.
  2. The request reaches the router for the instance's network, which translates the floating IP to the instance's private address.
  3. The instance's security groups check the request against their ingress rules. If no rule allows it, it is dropped.
  4. The instance receives the request and replies.
  5. Security groups are stateful, so the reply is allowed back out without a separate rule. The router translates its source back to the floating IP.

Without a floating IP, step 1 has nowhere to go: an instance with only a private address can't be reached from the internet.

From an instance to the internet

  1. The instance sends traffic to an internet address through its default route, the router.
  2. The instance's security groups check it against their egress rules. Outbound traffic is allowed by default.
  3. The router translates the source to its own external address, so the instance can reach out without having a public address of its own.

Between instances

Instances on the same network reach each other directly, subject to their security groups. Traffic between different networks goes through a router, so whether two networks can reach each other depends on how they're connected.

Security groups

A security group is a list of rules. Each rule allows one kind of traffic, in one direction, from one source.

  • Stateful: allow a request in, and its reply goes out automatically.
  • Additive: an instance can have several groups, and their rules add together. There are no deny rules; anything not allowed is dropped.
  • Sources: a rule's source is an address range or another security group. "Allow port 5432 from the web group" lets every instance in that group reach the database, wherever its address is.

The same patterns serve Windows and Linux instances; only the admin port differs. 203.0.113.0/24 stands in for your own office range:

Rule Windows Linux
Admin access from your office TCP 3389 (RDP) from 203.0.113.0/24 TCP 22 (SSH) from 203.0.113.0/24
Web traffic from anywhere TCP 443 from 0.0.0.0/0 TCP 443 from 0.0.0.0/0
App tier to database TCP 1433 (SQL Server) from the app group TCP 5432 (PostgreSQL) from the app group

To reach instances for administration without giving each one a floating IP, use a bastion host or a self-hosted VPN on an instance; both are covered on docs.

Load balancers: the next layer up

When a service runs on more than one instance, a load balancer gives it a single address. Breqwatr Cloud's load balancers are provided by Octavia, OpenStack's load balancing service.

  • The load balancer's address sits on one of your project's networks.
  • A listener accepts traffic on a port and protocol, such as HTTPS on 443.
  • A pool holds the instances, called members, that receive the traffic.
  • A health monitor checks members and stops sending traffic to any that fail.
  • To take traffic from the internet, the load balancer's address gets a floating IP, just as an instance would.

The instances behind it then need no floating IPs of their own, only a security group rule that lets the load balancer reach them. A three-tier web app builds this.

Impact

  • Network changes happen in minutes, made by the people building the workload.
  • Exposure is a choice per instance: nothing is reachable from the internet until it has a floating IP, or sits behind a load balancer with one, and a security group rule lets traffic in.
  • Networks and rules can be defined in code with everything else, so an environment's network is rebuilt along with its instances.

Common anti-patterns

  • A floating IP on every instance: each public address is another way in. Instances that only serve other instances don't need one.
  • Admin ports open to the world: RDP or SSH allowed from 0.0.0.0/0, usually added to get something working and never narrowed.
  • One group for everything: a single security group shared by every tier, so a rule added for one tier opens it for all of them.
  • Address ranges chosen without a plan: networks that later need to connect to each other, or to another site, can't if their ranges overlap.

Further reading