About Network Settings

You can implement fine-grained control over network access to your Compute Classic instances, both from other instances as well as from external hosts. When you create an instance, by default, it doesn’t allow access from any other instance or external host. Network settings allow you to configure access to your instances.

You can configure network access to your instance by using the shared network as well as by setting up your own IP networks. If an instance has multiple vNICs, you can associate that instance with both the shared network and the IP network. In the shared network, access to your instances is determined by security lists and security rules, while in the IP network you create security rules and access control lists (ACLs) enable access to instances.

If you want to access an instance directly over the public Internet, you must assign a public IP address to the instance. Public IP addresses can be assigned to the instance interface on the shared network as well as to its interfaces IP networks, if any.

Note:

This section describes network configuration in the shared network. For information about setting up an IP network, see Configuring IP Networks.

In the shared network, to enable unrestricted communication among some of your instances (for example, to enable all the instances hosting your development environment to communicate with each other), you can create a security list and add the instances to that security list. When you add an instance to a security list, the instance can communicate with all the other instances in the same security list using their private IP addresses.

By default, the instances in a security list are isolated from hosts outside the security list. You can override this default setting by creating security rules. Each security rule defines a specific source, a destination, and a protocol-port combination over which communication is allowed. For example, you can set up a security rule to permit SSH access over port 22 from a set of external hosts (specified in a security IP list) to all the instances in a security list.

A security list can be used as a source or destination in up to 10 security rules.

The following diagram illustrates how you can use security lists and security rules to restrict traffic between your instances and control access to them.

Communication paths between security lists and security IP lists using security rules
This diagram shows the following communication paths:
  • Instances in Security-list-a can send traffic to instances in Security-list-b over any protocol, as defined by Security-rule-a.

  • Instances in Security-list-a can receive HTTPS traffic from any host on the public internet, as defined by Security-rule-b.

  • Instances in Security-list-b can receive traffic over SSH from any of the IP addresses specified in Security-IP-list-a, as defined by Security-rule-c.

If no security rules are defined for a security list, then, by default, instances in that security list can’t receive traffic from hosts outside the security list. However, instances in the security list can still access other instances in the same security list.

When you remove an instance from a security list, the instance can no longer communicate with other instances in that security list, and traffic to and from that instance is no longer controlled by the security rules defined for that security list.

A security IP list specifies a set of IP addresses that can be used as a source or a destination in security rules. See Managing Security IP Lists.

An instance can be added to multiple security lists. In case of conflicts in policy, the most restrictive policy takes precedence. For example if an instance belongs to one security list with the outbound policy permit and the same instance is added to another security list with the outbound policy deny, effectively the outbound policy for that instance would be deny.