Firewall Policies tab

Overview

The policies available to this VPC — “Configure stateless firewall policies for fine-grained traffic control”. Creating one here scopes it to this VPC automatically.

Navigation: Networking → VPC → click a VPC → Firewall Policies.

Actions

Action	Available when
Manage Rules	Always
Edit Firewall Policy	Not a system default
Delete Firewall Policy	Not a system default

System defaults

System policies carry a System default badge and a tooltip:

Built-in system policy — rules are read-only and the policy cannot be changed or deleted

You can open Manage Rules on a system default to read its rules, which is worth doing once. A tier with no policy assigned is governed by one of these, so knowing what it permits tells you what an unassigned tier actually allows.

The rule model

Rules and inline editing are documented in full on Firewall Policies. Two properties matter most when working inside a VPC: Policies are stateless. Allowing traffic in one direction does not implicitly allow the reply, so rules generally come in pairs. Policies are shared. The same policy assigned to three tiers governs all three, and editing its rules changes all three at once — see Networks.

Deleting a policy

Deleting one that’s still assigned fails with:

The Firewall Policy may still be assigned to a network

The message doesn’t say which network. Find them in Networks — the Firewall Policy column shows the policy each tier uses — or open the designer, where every tier connected to the policy node is visible at a glance.

Find every tier using it

The designer is fastest: connections into the policy node are the assignments.

Reassign those tiers

Assign a different policy to each, or drag a new connection in the designer.

Then delete

With nothing assigned, the deletion succeeds.

Worked example: give a database tier its own rules

The default state — one shared policy across every tier — is the situation worth fixing first in an inherited VPC.

Create a policy for the tier

Create here, and it’s scoped to this VPC. Name it after the tier, not the rule: db-tier, not allow-5432. Rules change; the tier doesn’t.

Add only the traffic the tier needs

Typically the database port from the application tier’s CIDR, and nothing from the internet. Because policies are stateless, add the return direction too.

Assign it to the tier

From Networks, or by dragging a connection in the designer.

Confirm the web tier did not change

Its Firewall Policy value should still be the original policy. If it now reads the new one, you reassigned the wrong tier.

Test from the application tier, then from outside

It should work from the app tier and fail from the internet. Testing only the first half is how a tier ends up publicly reachable.