Elastic Compute Service:Cross-group communication in a VPC

Prerequisites

• The ECS instances that require communication must be in the same VPC. If your instances are in different VPCs, you must first connect their networks by using Cloud Enterprise Network or a VPC Peering Connection before you configure security group rules.

• Solution 2 and Solution 3 rely on the default behavior of basic security groups, where instances within the same group can communicate with each other. If you are using enterprise security groups, which isolate instances by default, you must use Solution 1 or Solution 4.

Method 1: Authorize by single IP address

Use cases

This solution is ideal for scenarios where a small number of ECS instances in the same VPC require communication over the internal network.

Pros and cons

• Pro: Rules are clear and easy to understand.

• Con: May hit the 200-rule limit per security group. Maintenance workload is high.

Procedure

1. Find an instance that requires communication and click its instance ID.

2. On the Instance Details page, click the Security Group tab.

3. Find the security group to configure, and in the Operation column, click or Configure Rules.

4. Click the Inbound tab.

5. Click 手动添加 and add a security group rule with the following settings.

   • Authorization policy: Allow.

   • Priority: Set as needed. Default: 1.

   • Protocol Type: Select as needed.

   • Port Range: Set as needed.

   • Source: Enter the private IP address of the source instance, in the format a.b.c.d/32. To authorize all instances within a network segment, use CIDR notation, such as 192.168.1.0/24.

6. Click Save.

Method 2: Add instances to the same security group

Use cases

Simple application architectures where all instances can share one basic security group.

Pros and cons

• Pro: Rules are clear and easy to review.

• Con: Only works for simple architectures. If the network architecture changes, you must update the authorization method.

Procedure

See Associate a security group with an instance (primary network interface card).

Method 3: Attach a dedicated security group for communication

Use cases

Multilayer application architectures that require a dedicated security group for internal communication.

Pros and cons

• Pro: Works for complex network architectures.

• Con: Instances belong to multiple security groups, making rules harder to read.

Procedure

1. In the same VPC, create a new basic security group (for example, a "shared-comm-sg"). This new group requires no rules. For more information, see Create a security group.

2. Associate this new shared security group with all instances that require internal communication. This allows the instances to communicate by applying the default rule that permits traffic between instances within the same basic security group. For more information, see Associate a security group with an instance (primary network interface card).

Method 4: Authorize between security groups

Use cases

Multilayer application architectures where instances authorize each other by security group ID.

Pros and cons

• Pro: Works for complex network architectures.

• Con: Instances belong to multiple security groups, making rules harder to read.

Procedure

1. Find an instance that requires communication and click its instance ID.

2. On the Instance Details page, click the Security Group tab.

3. Find the security group to configure, and in the Operation column, click or Configure Rules.

4. Click the Inbound tab.

5. Click 手动添加 and add a security group rule with the following settings.

   • Authorization policy: Allow.

   • Priority: Set as needed. Default: 1.

   • Protocol Type: Select as needed.

   • Port Range: Set as needed.

   • Authorization Object:

     • Within your account: Enter the destination security group ID.

     • Cross-account: Enter the destination account ID and security group ID in AccountID/SecurityGroupID format.

6. Click Save.