# Control inbound and outbound traffic with security groups

How security groups filter traffic with allow rules only, how to create and bind them, and why binding one network interface can silently deny inbound traffic on the whole instance.

A security group is an allow-only rule set that you attach to a network interface. Each rule permits specific inbound or outbound traffic; anything a rule does not match falls back to the security group's default policy. The panel states this permanently: "Security groups contain allow rules only. Unmatched inbound traffic is denied by default, while unmatched outbound traffic is allowed."

**Binding a security group to one network interface can flip the entire instance to default-deny inbound — including other interfaces that are not bound to any security group.** The default policy applies at the instance level, not per interface. On a multi-interface instance, binding a group to a private interface can cut off a public interface's inbound traffic too, the moment the binding takes effect. Read what binding does, later on this page, before you attach a security group to anything.

_Interface illustration: Security groups panel on the VPC detail page: the persistent info notice at the top, the group list with rule count and attached-interface count columns, and the Create security group button_

## Before you begin

- **List every network interface on the target instance** and note which ones already have a security group bound. Binding affects the whole instance, not only the interface in the dropdown.
- **Add the inbound allow rules you need — SSH, RDP, or any other management port — before you bind the group**, not after.
- **Know that unbinding the last bound group turns the instance firewall off entirely.** It is not a partial rollback; see [Unbind a security group](#unbind-a-security-group).

## Create a security group

1. On the VPC detail page, go to the **Security groups** panel.
2. Select **Create security group**.
3. Enter a name and, optionally, a description.
4. Select **Save**.

A new security group starts with zero rules and is not bound to any network interface. Creating it has no effect on any instance — the risk starts only at the binding step, not at creation.

## Add allow rules

1. In the security group list, select the edit icon for the group.
2. Select **Add rule**.
3. Choose a protocol. Selecting **TCP** or **UDP** shows start and end port fields; other protocols do not require ports.
4. Enter the start and end port, if shown. A start port outside 1–65535 is rejected with "Start port must be between 1 and 65535". An end port lower than the start port or above 65535 is rejected with "End port must be no lower than the start port and no higher than 65535".
5. Choose a remote source: a CIDR block or an IP List. Leaving both empty blocks the save with "Select either CIDR or IP List".
6. Select **Save**.

_Interface illustration: Edit security group rules dialog: the rule table with protocol, port, and remote columns, the Add rule button, the rule count indicator, and the warning banner shown when the rule list is empty_

A security group holds up to 50 rules, shown as a running count in the dialog. Closing the dialog with zero rules shows the warning "There are no allow rules. All inbound traffic will be denied." This warning appears only here, inside the edit dialog. It does not appear on the network interface dropdown where binding actually happens, so seeing it is not itself the dangerous moment — binding an empty group to an interface is.

## Bind a security group to a network interface

The dropdown that binds a group has no confirmation step: it applies as soon as you select a value.

To see what changes, refer to the following table before you select a group:

| Element                                       | What happens                                                                                           | What does not happen                                                        |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
| The instance's firewall                       | Turns on for the whole instance, with inbound set to deny and outbound set to allow                    | The change does not stay scoped to the interface you picked                 |
| Other network interfaces on the same instance | Also switch to default-deny inbound if they carry no security group of their own                       | They are not left in their previous open state                              |
| The bound group's rules                       | Take effect as inbound allow exceptions                                                                | An empty rule set does not fall back to allowing everything                 |
| Outbound traffic                              | Keeps being allowed by default                                                                         | Outbound is not affected by the bind                                        |
| The apply step                                | Runs as an asynchronous work request; the panel shows "Binding updated. Syncing the instance firewall" | The new rules are not guaranteed to be live the instant the dropdown closes |

If the instance has not finished provisioning, binding only updates the stored association. There is no firewall to sync yet, and the panel shows "Binding updated" instead.

> [!CAUTION]
> Binding the first security group anywhere on a multi-interface instance puts
> every interface on that instance under default-deny inbound, not only the one
> you selected. Confirm every interface already has the allow rules it needs —
> especially SSH or RDP on a production instance — before you select a group.

1. On the VPC detail page, go to the **Network interfaces** panel.
2. Find the target network interface and open its security group dropdown.
3. Select the security group to attach.

_Interface illustration: Network interfaces panel: one row's security group dropdown, open to show the list of available groups and the empty option used to unbind_

Refer to [Work requests](/compute/operations/work-requests/) to confirm the sync finished.

## Unbind a security group

Unbinding uses the same dropdown: select the empty option instead of a group.

Before you unbind the last interface on an instance, refer to the following table:

| Element                                                                | What happens                                                                                                         | What does not happen                                                  |
| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| The interface you unbind                                               | Stops being filtered by that group's rules                                                                           | It is not left with some intermediate, partially open rule set        |
| The rest of the instance, if this was its last bound interface         | The instance firewall turns off entirely; traffic returns to fully open, the same as before any group was ever bound | The instance does not keep default-deny in a reduced or safer form    |
| The rest of the instance, if other interfaces still have a group bound | Stays on default-deny, unaffected by this unbind                                                                     | Unbinding one interface does not turn off the firewall for the others |

Unbinding a single interface on a multi-interface instance is not a full rollback by itself. The instance-wide policy only turns off once no interface on that instance has a security group attached.

## Rule changes apply to every instance sharing the group

Saving rule changes on a security group resyncs the firewall on every network interface currently bound to it, across every instance that uses it. If several instances share one group — for example, every web server in a project — editing one rule affects all of them in the same operation, not only the instance you happened to be viewing.

## Delete a security group

1. In the security group list, select the delete icon for the group.
2. Confirm the dialog: `Delete security group "{{name}}"? This action cannot be undone.`
3. Select **Delete security group** to confirm.

_Interface illustration: Security group list row with the delete icon disabled and its tooltip visible, next to the delete confirmation dialog_

The delete icon stays disabled, with the tooltip "Unbind from all ENIs first", while any network interface still has the group attached. Unbind it from every interface before deleting it.

## What binding and unbinding do not affect

- **Outbound traffic.** It stays allowed by default regardless of how many inbound rules exist or whether any group is bound.
- **The instance itself, its storage, and running workloads.** This is a network access control, not a power or storage action.
- **Console access.** It goes through the management plane rather than the instance's network interfaces, so it stays available even when inbound network traffic is fully blocked.
- **Instances with no bind action taken.** A newly created, unbound security group has no effect on any instance until you attach it to a network interface.

## If an action is rejected

The panel displays the platform's message verbatim in your interface language. Each message is quoted below, followed by what to do.

### Failed to load security groups

> Failed to load security groups

The panel could not fetch the list for this VPC. Reload the page. If the failure persists, refer to [Work requests](/compute/operations/work-requests/) to confirm the VPC itself is healthy.

### Failed to create, save, or delete a security group

> Failed to create security group

> Failed to save security group

> Failed to delete security group

The create, rule-save, or delete request itself failed — for example, a network error or an expired session. The security group's state before the attempt is unchanged. Retry the action.

### Failed to update security group binding

> Failed to update security group binding

The bind or unbind request failed before it was recorded. The dropdown reverts to its previous value. Retry the selection.

## Related documentation

- [VPC networks](/network/vpc/)
- [Network interfaces](/compute/instances/network/)
- [Instance details](/compute/instances/detail/)
- [Work requests](/compute/operations/work-requests/)