diff --git a/doc/best-practice/source/_static/images/en-us_image_0000001124559429.png b/doc/best-practice/source/_static/images/en-us_image_0000001124559429.png new file mode 100644 index 0000000..5dbaced Binary files /dev/null and b/doc/best-practice/source/_static/images/en-us_image_0000001124559429.png differ diff --git a/doc/best-practice/source/_static/images/en-us_image_0000001124559441.png b/doc/best-practice/source/_static/images/en-us_image_0000001124559441.png new file mode 100644 index 0000000..c5d361f Binary files /dev/null and b/doc/best-practice/source/_static/images/en-us_image_0000001124559441.png differ diff --git a/doc/best-practice/source/_static/images/en-us_image_0141273034.png b/doc/best-practice/source/_static/images/en-us_image_0141273034.png new file mode 100644 index 0000000..1909444 Binary files /dev/null and b/doc/best-practice/source/_static/images/en-us_image_0141273034.png differ diff --git a/doc/best-practice/source/_static/images/en-us_image_0287297889.png b/doc/best-practice/source/_static/images/en-us_image_0287297889.png new file mode 100644 index 0000000..4be1389 Binary files /dev/null and b/doc/best-practice/source/_static/images/en-us_image_0287297889.png differ diff --git a/doc/best-practice/source/best_practice/index.rst b/doc/best-practice/source/best_practice/index.rst new file mode 100644 index 0000000..65fdef6 --- /dev/null +++ b/doc/best-practice/source/best_practice/index.rst @@ -0,0 +1,16 @@ +:original_name: bestpractice_0001.html + +.. _bestpractice_0001: + +Best Practice +============= + +- :ref:`VPC and Subnet Planning Suggestions ` +- :ref:`Using IP Address Groups to Reduce the Number of Security Group Rules ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + vpc_and_subnet_planning_suggestions + using_ip_address_groups_to_reduce_the_number_of_security_group_rules diff --git a/doc/best-practice/source/best_practice/using_ip_address_groups_to_reduce_the_number_of_security_group_rules.rst b/doc/best-practice/source/best_practice/using_ip_address_groups_to_reduce_the_number_of_security_group_rules.rst new file mode 100644 index 0000000..f8be815 --- /dev/null +++ b/doc/best-practice/source/best_practice/using_ip_address_groups_to_reduce_the_number_of_security_group_rules.rst @@ -0,0 +1,99 @@ +:original_name: bestpractice_0013.html + +.. _bestpractice_0013: + +Using IP Address Groups to Reduce the Number of Security Group Rules +==================================================================== + +Scenarios +--------- + +Finance and securities enterprises have high security requirements when planning cloud networks. Access to servers is often controlled based on IP addresses. To simplify security group rule configuration and provide refined security control, you can use IP address groups in case of the following scenarios: + +- A security group has more than 40 rules. +- The direction, type, protocol, and port of security group rules are the same except the address. + +Constraints +----------- + +- An IP address group can contain a maximum of 20 IP addresses or IP address ranges. + +Prerequisites +------------- + +You have created one or more security groups for access control. + +Typical Case +------------ + +For example, you plan to configure the following rules for security group A. + +========= ==== ======== ========== ========================= +Direction Type Protocol Port Range Source/Destination +========= ==== ======== ========== ========================= +Inbound IPv4 TCP 22122 Source: 11.19.255.64/30 +Inbound IPv4 TCP 22122 Source: 113.31.128.252/30 +Inbound IPv4 TCP 22122 Source: 113.31.138.0/25 +Inbound IPv4 TCP 22122 Source: 183.232.25.208/28 +========= ==== ======== ========== ========================= + +The four inbound rules have the same port, type, and protocol but different source IP addresses. In this case, you can use an IP address group to reconfigure the security group rules. + +Procedure +--------- + +**Create an IP address group.** + +#. Log in to the management console. +#. Click |image1| in the upper left corner and select the desired region and project. +#. Under **Networking**, click **Virtual Private Cloud**. +#. In the navigation pane on the left, choose **Access Control** > **IP Address Groups**. +#. Click **Create IP Address Group**. +#. Set the parameters. + + - **Name**: **ipGroup-A** + + - **IP Address**: + + 11.19.255.64/30 + + 113.31.128.252/30 + + 113.31.138.0/25 + + 183.232.25.208/28 + + + .. figure:: /_static/images/en-us_image_0000001124559441.png + :alt: **Figure 1** Creating an IP address group + + **Figure 1** Creating an IP address group + +#. Click **OK**. + +**Configure a security group rule.** + +8. In the navigation pane on the left, choose **Access Control** > **Security Groups**. +9. Locate security group A and click **Manage Rule** in the **Operation** column. +10. Under **Inbound Rules**, click **Add Rule**. +11. Set the parameters. + + - **Protocol & Port**: **TCP** and **22122** + + - **Type**: **IPv4** + + - **Source**: **ipGroup-A** + + + .. figure:: /_static/images/en-us_image_0000001124559429.png + :alt: **Figure 2** Configuring a security group rule + + **Figure 2** Configuring a security group rule + +12. Click **OK**. + +**Delete old security group rules.** + +13. Delete four old security group rules after the configured security group rule takes effect. + +.. |image1| image:: /_static/images/en-us_image_0141273034.png diff --git a/doc/best-practice/source/best_practice/vpc_and_subnet_planning_suggestions.rst b/doc/best-practice/source/best_practice/vpc_and_subnet_planning_suggestions.rst new file mode 100644 index 0000000..b87fa0a --- /dev/null +++ b/doc/best-practice/source/best_practice/vpc_and_subnet_planning_suggestions.rst @@ -0,0 +1,154 @@ +:original_name: bestpractice_0002.html + +.. _bestpractice_0002: + +VPC and Subnet Planning Suggestions +=================================== + +Before creating your VPCs, determine how many VPCs, the number of subnets, and what IP address ranges or connectivity options you will need. + +- :ref:`How Do I Determine How Many VPCs I Need? ` +- :ref:`How Do I Plan Subnets? ` +- :ref:`How Do I Plan Routing Policies? ` +- :ref:`How Do I Connect to an On-Premises Data Center? ` +- :ref:`How Do I Access the Internet? ` + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_section089562719454: + +How Do I Determine How Many VPCs I Need? +---------------------------------------- + +VPCs are region-specific. By default, networks in VPCs in different regions or even in the same region are not connected. + +- One VPC + + If your services do not require network isolation, a single VPC should be enough. + +- Multiple VPCs + +If you have multiple service systems in a region and each service system requires an isolated network, you can create a separate VPC for each service system. + +If you require network connectivity between separate VPCs in the same account or in different accounts, you can use VPC peering connections or Cloud Connect. + +- If two VPCs are in the same region, use a `VPC peering connection `__. +- If two VPCs are in different regions, use `Cloud Connect `__. + +.. note:: + + By default, you can create a maximum of five VPCs in each region. If this cannot meet your service requirements, request a quota increase. For details, see `How Do I Apply for a Higher Quota? `__ + +The following table lists the private CIDR blocks that you can specify when creating a VPC. Consider the following when selecting a VPC CIDR block: + +- Number of IP addresses: Reserve sufficient IP addresses in case of business growth. +- IP address range: Avoid IP address conflicts if you need to connect a VPC to an on-premises data center or connect two VPCs. + +:ref:`Table 1 ` lists the supported VPC CIDR blocks. + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_en-us_topic_0118499040_table3240172772213: + +.. table:: **Table 1** VPC CIDR blocks + + +-------------------+-----------------------------+--------------------------------+ + | VPC CIDR Block | IP Address Range | Maximum Number of IP Addresses | + +===================+=============================+================================+ + | 10.0.0.0/8-24 | 10.0.0.0-10.255.255.255 | 2^24-2=16777214 | + +-------------------+-----------------------------+--------------------------------+ + | 172.16.0.0/12-24 | 172.16.0.0-172.31.255.255 | 2^20-2=1048574 | + +-------------------+-----------------------------+--------------------------------+ + | 192.168.0.0/16-24 | 192.168.0.0-192.168.255.255 | 2^16-2=65534 | + +-------------------+-----------------------------+--------------------------------+ + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_section15166143804819: + +How Do I Plan Subnets? +---------------------- + +A subnet is a unique CIDR block with a range of IP addresses in a VPC. All resources in a VPC must be deployed on subnets. + +- By default, all instances in different subnets of the same VPC can communicate with each other and the subnets can be located in different AZs. For example, VPC-A has subnet A01 in AZ A and subnet A02 in AZ B. Subnet A01 and subnet B01 can communicate with each other by default. + +- After a subnet is created, its CIDR block cannot be modified. Subnets in the same VPC cannot overlap. + + When you create a VPC, a default subnet will be created together. If you need more subnets, see `Creating a Subnet for the VPC `__. + + A subnet mask can be between the netmask of its VPC CIDR block and /28 netmask. If a VPC CIDR block is 10.0.0.0/16, its subnet mask can between 16 to 28. + + For example, if the CIDR block of VPC-A is 10.0.0.0/16, you can specify 10.0.0.0/24 for subnet A01, 10.0.1.0/24 for subnet A02, and 10.0.3.0/24 for subnet A03. + + .. note:: + + By default, you can create a maximum of 100 subnets in each region. If this cannot meet your service requirements, request a quota increase by referring to `How Do I Apply for a Higher Quota? `__ + +When planning subnets, consider the following: + +- You create different subnets for different modules in a VPC. For example, in VPC-A, you can create subnet A01 for web services, subnet A02 for management services, and subnet A03 for data services. You can leverage network ACLs to control access to each subnet. +- If your VPC needs to communicate with an on-premises data center through VPN or Direct Connect, ensure that the VPC subnet and the CIDR block used for communication in the data center do not overlap. + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_section169901852144820: + +How Do I Plan Routing Policies? +------------------------------- + +When you create a VPC, the system automatically generates a default route table for the VPC. If you create a subnet in the VPC, the subnet automatically associates with the default route table. A route table contains a set of routes that are used to determine where network traffic from your subnets in a VPC is directed. The default route table ensures that subnets in a VPC can communicate with each other. + +If you do not want to use the default route table, you can now create a custom route table and associate it with the subnets. The custom route table associated with a subnet affects only the outbound traffic. The default route table controls the inbound traffic. + +You can add routes to default and custom route tables and configure the destination, next hop type, and next hop in the routes to determine where network traffic is directed. Routes are classified into system routes and custom routes. + +- System routes: Routes that are automatically added by the system and cannot be modified or deleted. System routes allow instances in a VPC to communicate with each other. + +- Custom routes: Routes that can be modified and deleted. The destination of a custom route cannot overlap with that of a system route. + + You cannot add two routes with the same destination to a VPC route table even if their next hop types are different, because the destination determines the route priority. According to the longest match routing rule, the destination with a higher matching degree is preferentially selected for packet forwarding. + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_section187551349164918: + +How Do I Connect to an On-Premises Data Center? +----------------------------------------------- + +If you require interconnection between a VPC and an on-premises data center, ensure that the VPC does not have an overlapping IP address range with the on-premises data center to be connected. + +As shown in :ref:`Figure 1 `, you have VPC 1 in region A and VPC 2 and VPC 3 in region B. To connect to an on-premises data center, they can use a VPN, as VPC 1 does in Region A; or a Direct Connect connection, as VPC 2 does in Region B. VPC 2 connects to the data center through a Direct Connect connection, but to connect to another VPC in that region, like VPC 3, a VPC peering connection must be established. + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_fig16817171713408: + +.. figure:: /_static/images/en-us_image_0287297889.png + :alt: **Figure 1** Connections to on-premises data centers + + **Figure 1** Connections to on-premises data centers + +When planning CIDR blocks for VPC 1, VPC 2, and VPC 3: + +- The CIDR block of VPC 1 cannot overlap with the CIDR block of the on-premises data center in Region A. +- The CIDR block of VPC 2 cannot overlap with the CIDR block of the on-premises data center in Region B. +- The CIDR blocks of VPC 2 and VPC 3 cannot overlap. + +.. _bestpractice_0002__en-us_topic_0167202536_en-us_topic_0119408804_section7650164019505: + +How Do I Access the Internet? +----------------------------- + +**Use EIPs to enable a small number of ECSs to access the Internet.** + +When only a few ECSs need to access the Internet, you can bind the EIPs to the ECSs. This will provide them with Internet access. You can also dynamically unbind the EIPs from the ECSs and bind them to NAT gateways and load balancers instead, which will also provide Internet access. The process is not complicated. + +For more information about EIP, see `EIP Overview `__. + +**Use a NAT gateway to enable a large number of ECSs to access the Internet.** + +When a large number of ECSs need to access the Internet, the public cloud provides NAT gateways for your ECSs. With NAT gateways, you do not need to assign an EIP to each ECS. NAT gateways reduce costs as you do not need so many EIPs. NAT gateways offer both source network address translation (SNAT) and destination network address translation (DNAT). SNAT allows multiple ECSs in the same VPC to share one or more EIPs to access the Internet. SNAT prevents the EIPs of ECSs from being exposed to the Internet. DNAT can implement port-level data forwarding. It maps EIP ports to ECS ports so that the ECSs in a VPC can share the same EIP and bandwidth to provide Internet-accessible services. + +For more information, see `NAT Gateway User Guide `__. + +**Use ELB to access the Internet If there are a large number of concurrent requests.** + +In high-concurrency scenarios, such as e-commerce, you can use load balancers provided by the ELB service to evenly distribute incoming traffic across multiple ECSs, allowing a large number of users to concurrently access your business system or application. ELB is deployed in the cluster mode. It provides fault tolerance for your applications by automatically balancing traffic across multiple AZs. You can also take advantage of deep integration with Auto Scaling (AS), which enables automatic scaling based on service traffic and ensures service stability and reliability. + +For more information, see `Elastic Load Balance User Guide `__. + +Helpful Links +------------- + +- `Application Scenarios `__ +- `Private Network Access `__ +- `Public Network Access `__ diff --git a/doc/best-practice/source/index.rst b/doc/best-practice/source/index.rst index 6d77415..cf04a7f 100644 --- a/doc/best-practice/source/index.rst +++ b/doc/best-practice/source/index.rst @@ -2,3 +2,7 @@ Virtual Private Cloud - Best Practice ===================================== +.. toctree:: + :maxdepth: 1 + + best_practice/index