VPC & Advanced Networking

From Networking → VPC → Add VPC, choose a VPC offering and define a super CIDR range for the whole VPC (e.g. 10.0.0.0/16). Individual tiers (networks) within the VPC are then carved out of that range.

Adding tiers

Add one or more tiers to the VPC, each with its own CIDR and ACL. A typical setup might have a "web" tier that's internet-reachable and a "data" tier that only accepts traffic from the web tier. Each tier's CIDR must be unique within the VPC's super CIDR.

ACLs control traffic in and out of each tier, similar to security groups but scoped to the VPC's internal routing. Create an ACL list, add rules to it, then assign the list to a tier. You can also apply an ACL to a private gateway to control traffic entering the VPC from connected on-premises networks.

How ACL rules work

• Rules are numbered and evaluated in order, lowest number first - the first matching rule wins.
• ACLs are stateful: an allowed inbound connection's return traffic is permitted automatically, and isn't affected by a separate "deny all" egress rule.
• Each rule specifies a source CIDR, a protocol (TCP, UDP, ICMP, a raw protocol number, or "All"), and either a port range or - for ICMP - a type/code, plus allow or deny.

Public IPs are reserved for your VPC or account and can be associated with a specific VM using static NAT, giving that VM direct inbound/outbound access under its own public address. When a public IP or VLAN is no longer needed, release it back to the pool.

Most network offerings allow a single public IP to serve more than one purpose at once - for example, the same IP can carry source NAT, port forwarding, and load balancing rules together. Static NAT is the exception: once enabled on an IP, that IP can't also carry port forwarding or load balancing rules. If you need static NAT on an IP as well as port forwarding, allocate a separate public IP for the port forwarding rules.

Within a VPC you can create load balancing rules against a public IP to distribute traffic across multiple VMs in a tier - handy for scaling a web tier horizontally. An internal LB rule does the same thing but for traffic that stays entirely inside the VPC, for example balancing requests from a web tier to a pool of internal API servers ("load balancing across tiers").

Algorithms and stickiness

Each rule uses one of three algorithms to spread traffic across its instances: round-robin, least connections, or source (traffic from the same source IP is consistently sent to the same instance). For applications that need a client to keep hitting the same backend instance across requests (e.g. server-side session state), you can also enable sticky sessions using an LB-generated cookie, an application cookie, or the source IP.

Health checks

A health check can be configured against each rule so unhealthy instances are automatically taken out of rotation - defining a check path, timeout, and how many consecutive passes/failures flip an instance's status.

HTTPS/SSL

To terminate HTTPS at the load balancer rather than on each instance, upload an SSL certificate and bind it to the rule.

AutoScaling automatically adds or removes VMs behind a load balancing rule in response to demand, so a tier can grow under load and shrink back down once it passes - useful for a web tier with a variable traffic pattern. AutoScaling builds on top of a load balancing rule, so a load balancer must be configured first (see Load balancing above).

Preparing a template for AutoScaling

Before setting up a group, make sure your template is genuinely "autoscaling-ready":

• The application, and anything it depends on (web server, runtime, environment config, database connection details, etc.) must already be installed and configured to start automatically on boot - there's no one on hand to log in and start it manually when the group scales up.
• Use user data/cloud-init if a new instance needs to pull configuration or register itself at boot time (for example, fetching secrets or joining a service registry).
• The template must have PV drivers (Windows) or virtio drivers (Linux) installed - these are what let the platform collect the CPU and memory statistics that scaling decisions are based on. Most modern cloud/distro images include virtio drivers by default, but custom-built templates should be checked.
• Build and test the template as a normal VM first - snapshot it once you've confirmed the application comes up correctly on a fresh boot with no manual steps, and use that as the AutoScale template (see Templates & ISOs).

Network requirements

AutoScaling groups run inside an isolated network (or a VPC tier) using a network offering that supports instance AutoScaling, with a source NAT IP and a load balancing rule already in place - the group attaches to that rule rather than creating its own.

The AutoScale VM profile

The VM profile defines what a newly scaled-up instance looks like:

• Zone, template and compute offering - where the instance deploys and what template/hardware it's built from.
• An optional data disk offering, if instances in the group need extra storage.
• The network to attach new instances to.
• Advanced options: SSH keypair, affinity group, and user data to inject at boot.
• Minimum and maximum instance counts - the group will never scale below the minimum or above the maximum.
• Polling interval - how often conditions are evaluated (30 seconds by default).
• Expunge grace period - how long a scaled-down instance is kept before being destroyed (120 seconds by default).

Scaling policies

Each policy is either a scale-up or scale-down action, triggered by one or more conditions. A condition compares a counter (average instance CPU %, average instance memory %, public network Mbps received/transmitted per instance, or average load balancer connections per instance) against a threshold using an operator (greater than, less than, greater/less than or equal to, or equal to).

• Duration - how long the condition must hold true before the action fires, to avoid reacting to a brief spike.
• Quiet time - a cooldown after a scaling action (300 seconds by default) before another one can trigger, giving the group time to stabilise.

Two VPN options are available depending on what you're connecting to:

• Site-to-site VPN - connects your VPC to another network (e.g. your office or another data centre) via a persistent IPsec tunnel. This requires creating a VPN gateway on the VPC side and a customer gateway describing the remote end, then establishing the connection between them.
• Private gateway - a more direct, dedicated connection into the VPC for scenarios needing lower-level network control, with its own ACL for traffic filtering. A private gateway can optionally use source NAT, which is useful if more than one of your VPCs shares the same CIDR range and needs to reach the same on-premises network without conflicting.

Once a site-to-site connection is set up, you can restart or remove it from the portal, and update or remove the customer gateway definition if the details on the remote end change.

For more specialised networking needs, virtual network appliances can be deployed into a VPC from supported vendor templates - for example, a virtual firewall or SD-WAN appliance - giving you more advanced networking capability than the built-in VPC services alone.

A good starting point for most applications is: one VPC, a public-facing tier for anything that needs internet access, a private tier for databases/internal services, an ACL locking the private tier down to only accept traffic from the public tier, and a load balancer in front of the public tier if you're running more than one web server.