Original address
Background information
The default network connectivity policy for security groups is that the network is interoperable between instances within the same security group, and the default intranet is disconnected between instances of different security groups. This strategy meets the needs of the vast majority of customers, but a few customers want to change the security Group network connectivity strategy, the network within the same security group is isolated rather than interoperable, which can greatly reduce the number of security groups and thus reduce the cost of maintaining and managing security groups. Based on the demands of these customers, we have enriched the security Group network connectivity policy to support network isolation within the security group. To use this feature, you need to first understand some of the details of network isolation within a security group: a few instructions for network isolation within a security group the granularity of the quarantine is the NIC rather than the ECS instance. This requires special attention if the ECS instance mounts multiple network adapters. Does not change the default network connectivity Policy Security Group * * The default * * Network connectivity Policy is still the network interoperability between instances within the same security group, and the default intranet is disconnected between instances of different security groups. The new functionality only provides you with a means to modify network connectivity policies, so new features do not have any impact on your existing security groups or on your new security groups. The principle of isolation precedence is set to the security group "quarantined" within the group, priority is higher than the "interoperability" security group, so if two instances belong to a security group that is set to quarantine, then the network must be unreachable between the two instances, whether or not they also belong to the "interworking" security group. A security group that is set to "quarantine" in a group with a priority higher than all user-defined ACLs, the isolated security group, the network between instances of the group must not be reachable, even if an increase in the allowed access ACL does not work. Network isolation is limited to instances within the current group (NIC) assuming that the current security group is G1, the network in the group is set to "quarantine", vm1 and vm2 belong to G1,VM2 and vm3 within the group of G2,G2, then VM1 and vm2 networks are unreachable, but the network between VM2 and VM3 can be reached.
To better understand the constraints and limitations of the network gree within the security group, the following is illustrated by a typical example (for the purpose of expressing an instance with only one NIC, so the NIC isolation is equivalent to instance isolation), the relationship of the instance and the security group to which the instance belongs is as follows:
The network connectivity strategy in the security group is as follows: The Security group intranet connectivity strategy contains instances G1 isolation vm1,vm2 G2 Interoperability vm1,vm2 G3 interchange vm2,vm3
In this example, the network connectivity between the instances is as follows: Network interoperability/Isolation between instances vm1-vm2 isolation vm1,vm2 also belong to G1 and G2,G1 policy is "quarantine", G2 policy is "interoperability", based on the principle of "isolation", VM1 is not communication between Vm2 VM2-VM3 interworking Vm2 and Vm3 belong to G3 at the same time, and G3 strategy is "interoperability", so Vm2 and Vm3 can communicate vm1-vm3 isolation Vm1 and Vm3 are different security groups, according to the default network connectivity policy, the different security groups of instances between the default intranet Modifying the network connectivity Policy API in a security group
For API details on this feature, please refer to Modifysecuritygrouppolicy
Original address