Resource stability best practices in Cloud Config help you identify configuration risks that affect the continuity and reliability of your cloud resources. A compliance package is a predefined set of compliance rules that Cloud Config runs against your resources to check whether their configurations follow established best practices. This topic explains the background and workflow of resource stability checks and describes the default rules included in the compliance package.
Background
Risk management is a top priority for cloud customers. Many enterprises choose Alibaba Cloud to improve business continuity by leveraging the high availability of the Alibaba Cloud platform. Identifying cloud resource configuration risks efficiently and comprehensively is critical for maintaining business continuity.
The following case study illustrates a system failure caused by improper cloud resource configuration:
An enterprise ran a core system on a Basic Edition ApsaraDB RDS instance, which is designed for test environments. The system ran without issues during periods of low traffic, masking the underlying configuration problem. During a major promotion, business volume increased by two to three times and real-time data processing volume increased by more than 10 times. The database instance responded slowly, which disrupted normal business operations. The root cause was identified as an improper database instance configuration. The issue was resolved after the instance specifications were upgraded.
How it works
Cloud Config performs static configuration compliance checks on your core resources, including compute, database, storage, networking, load balancing, and security resources. When non-compliant configurations are detected, Cloud Config generates a report. You can download the report and remediate the issues, for example, by upgrading instance specifications or adjusting configurations.
Static configurations are cloud resource configuration items such as instance specifications and instance deployment zones.
The following figure shows the workflow of the resource stability best practices scenario. 
Default rules
The compliance package includes 85 default rules. The rules are grouped by Alibaba Cloud service in the following sections. Each rule checks a specific configuration item and reports whether the resource is compliant or non-compliant.
| Service | Number of rules |
| ApsaraDB RDS | 10 |
| ApsaraDB for Redis | 10 |
| ApsaraDB for MongoDB | 7 |
| PolarDB | 8 |
| NAT Gateway | 2 |
| SLB | 6 |
| ALB | 3 |
| CEN | 2 |
| ECS | 9 |
| CDN | 2 |
| Message Queue for Apache Kafka | 1 |
| RocketMQ | 1 |
| Elasticsearch | 6 |
| OSS | 3 |
| ACK | 3 |
| EIP | 2 |
| AnalyticDB for MySQL | 3 |
| ECI | 1 |
| Bastionhost | 1 |
| Anti-DDoS | 1 |
| Internet Shared Bandwidth | 1 |
| CEN bandwidth plans | 1 |
| PolarDB-X | 2 |
ApsaraDB RDS
| Rule name | Rule description |
| Enable log backup for an ApsaraDB RDS instance | If log backup is not enabled, data cannot be recovered when local binary logs are lost. If log backup is enabled for the ApsaraDB RDS instance, the instance is considered compliant. |
| Use dedicated ApsaraDB RDS instances | If the ApsaraDB RDS instance uses a dedicated instance specification, the instance is considered compliant. |
| SQL audit log retention of ApsaraDB RDS instances meets the specified requirement | If SQL audit is enabled for an ApsaraDB RDS MySQL instance and the log retention period is greater than or equal to the specified value, the instance is considered compliant. Default value: 180 days. |
| Use multi-zone ApsaraDB RDS instances | If the ApsaraDB RDS instance uses multi-node deployment, the instance is considered compliant. |
| Disable public network access for ApsaraDB RDS instances | If no public network access endpoint is configured for the ApsaraDB RDS instance, the instance is considered compliant. We recommend that you do not configure Direct Internet Access for ApsaraDB RDS instances in production environments. Direct Internet Access exposes instances to attacks. |
| Set a reasonable maintenance window for ApsaraDB RDS instances | If the maintenance window of the ApsaraDB RDS instance falls within one of the time ranges specified by the parameter, the instance is considered compliant. If the maintenance window overlaps with business peak hours, your business may be affected. |
| Enable deletion protection for ApsaraDB RDS instances | If deletion protection is enabled for the ApsaraDB RDS instance, the instance is considered compliant. This rule does not apply to subscription instances; such instances are considered not applicable. |
| Configure a proper security whitelist for ApsaraDB RDS instances | If a security whitelist is configured for the ApsaraDB RDS instance and the whitelist does not contain 0.0.0.0/0, the instance is considered compliant. |
| Use cluster series ApsaraDB RDS instances | If the ApsaraDB RDS instance uses the series specified by the parameter, the instance is considered compliant. Default value: cluster edition or high-availability edition. |
| Check endpoint expiration of ApsaraDB RDS subscription instances | For subscription resources, renew upfront to avoid service interruption caused by payment issues. If the expiration date of the prepaid instance is more than the specified number of days from the check time, the instance is considered compliant. Default value: 30 days. This rule does not apply to pay-as-you-go instances; such instances are considered not applicable. |
ApsaraDB for Redis
| Rule name | Rule description |
| Check endpoint expiration of ApsaraDB for Redis subscription instances | If the expiration date of an ApsaraDB for Redis prepaid instance is more than the specified number of days from the check time, the instance is considered compliant. Default value: 30 days. Instances with auto-renewal enabled are considered compliant. This rule does not apply to pay-as-you-go instances; such instances are considered not applicable. |
| Set a reasonable backup window for ApsaraDB for Redis instances | If the automatic backup window of the ApsaraDB for Redis instance falls within one of the time ranges specified by the parameter, the instance is considered compliant. If the backup window overlaps with business peak hours, your business may be affected. |
| Do not set the IP whitelist of ApsaraDB for Redis instances to 0.0.0.0/0 | If the IP whitelist of the ApsaraDB for Redis instance is not set to 0.0.0.0/0, the instance is considered compliant. |
| Disable high-risk commands for ApsaraDB for Redis instances | If high-risk commands are disabled for the ApsaraDB for Redis instance, the instance is considered compliant. |
| Use cluster edition ApsaraDB for Redis instances | If the architecture type of the ApsaraDB for Redis instance is cluster edition, the instance is considered compliant. |
| Use Enterprise Edition ApsaraDB for Redis instances | If the ApsaraDB for Redis instance is Enterprise Edition, the instance is considered compliant. |
| Upgrade ApsaraDB for Redis instances to the latest minor version | If the ApsaraDB for Redis instance is upgraded to the latest minor version, the instance is considered compliant. |
| Enable release protection for ApsaraDB for Redis instances | If release protection is enabled for the ApsaraDB for Redis instance, the instance is considered compliant. |
| Enable incremental backup for ApsaraDB for Redis instances | If incremental backup is enabled for the ApsaraDB for Redis instance, the instance is considered compliant. This rule only applies to Tair instances; non-Tair instances are considered not applicable. |
| Use multi-zone ApsaraDB for Redis instances | If the ApsaraDB for Redis instance uses multi-node deployment, the instance is considered compliant. |
ApsaraDB for MongoDB
| Rule name | Rule description |
| Check endpoint expiration of ApsaraDB for MongoDB subscription clusters | If the expiration date of an ApsaraDB for MongoDB subscription cluster is more than the specified number of days from the check time, the cluster is considered compliant. Default value: 30 days. Clusters with auto-renewal enabled are considered compliant. |
| Enable log backup for ApsaraDB for MongoDB instances | If log backup is enabled for the ApsaraDB for MongoDB instance, the instance is considered compliant. |
| Use dedicated or exclusive ApsaraDB for MongoDB instances | If the ApsaraDB for MongoDB instance does not use a shared specification, the instance is considered compliant. |
| Do not set the IP whitelist of ApsaraDB for MongoDB instances to 0.0.0.0/0 | If the IP whitelist of the ApsaraDB for MongoDB instance is not set to 0.0.0.0/0, the instance is considered compliant. |
| Use multi-node deployment for ApsaraDB for MongoDB instances | If the ApsaraDB for MongoDB instance uses multi-node deployment, the instance is considered compliant. |
| Enable release protection for ApsaraDB for MongoDB instances | If release protection is enabled for the ApsaraDB for MongoDB instance, the instance is considered compliant. |
| Use multi-zone ApsaraDB for MongoDB instances | If the ApsaraDB for MongoDB instance uses multi-node deployment, the instance is considered compliant. |
PolarDB
| Rule name | Rule description |
| Check endpoint expiration of PolarDB subscription clusters | For subscription resources, renew upfront to avoid service interruption caused by payment issues. If the expiration date of the prepaid instance is more than the specified number of days from the check time, the instance is considered compliant. Default value: 30 days. Instances with auto-renewal enabled are considered compliant. This rule does not apply to pay-as-you-go instances; such instances are considered not applicable. |
| Use cluster edition PolarDB instances | If the PolarDB edition is cluster edition or multi-master cluster edition, the instance is considered compliant. Exercise caution when using single-node databases because fault recovery is slow. |
| Set a reasonable maintenance window for PolarDB clusters | If the maintenance window of the PolarDB cluster falls within one of the time ranges specified by the parameter, the cluster is considered compliant. If the maintenance window overlaps with business peak hours, your business may be affected. |
| Do not set the IP whitelist of PolarDB instances to 0.0.0.0/0 | If the IP whitelist of the PolarDB instance is not set to 0.0.0.0/0, the instance is considered compliant. |
| Enable deletion protection for PolarDB clusters | If deletion protection is enabled for the PolarDB cluster, the cluster is considered compliant. |
| PolarDB database minor version status is stable | If the current database minor version status of the PolarDB cluster is stable, the cluster is considered compliant. |
| Enable hot standby cluster for PolarDB clusters | If the hot standby cluster is enabled for the PolarDB cluster and data is distributed across multiple zones, the cluster is considered compliant. |
| Secondary backup retention of PolarDB clusters meets the specified requirement | If the level-two backup retention period of the PolarDB cluster is greater than or equal to the specified number of days, the cluster is considered compliant. Default value: 30 days. If level-two backup is not enabled or the retention period is less than the specified number of days, the cluster is considered non-compliant. |
NAT Gateway
| Rule name | Rule description |
| SNAT and DNAT entries of NAT gateways do not use the same EIP | If the SNAT and DNAT entries of the NAT gateway do not use the same EIP, the gateway is considered compliant. This rule does not apply to VPC NAT gateways; such gateways are considered not applicable. |
| Consistent bandwidth peak settings for multiple EIPs bound to SNAT entries | If multiple EIPs bound to the SNAT entry of the NAT gateway are added to an Internet Shared Bandwidth instance or have the same bandwidth peak setting, the gateway is considered compliant. This rule does not apply to VPC NAT gateways; such gateways are considered not applicable. |
SLB
| Rule name | Rule description |
| Enable health checks for all SLB listeners | If health checks are enabled for all running listeners of the SLB instance, the instance is considered compliant. |
| Check endpoint expiration of SLB subscription instances | For subscription resources, renew upfront to avoid service interruption caused by payment issues. If the expiration date of the prepaid instance is more than the specified number of days from the check time, the instance is considered compliant. Default value: 30 days. Instances with auto-renewal enabled are considered compliant. This rule does not apply to pay-as-you-go instances; such instances are considered not applicable. |
| Enable release protection for SLB instances | If release protection is enabled for the SLB instance, the instance is considered compliant. |
| SLB instance specifications meet requirements | If the SLB instance specification is in the specified list, the instance is considered compliant. We recommend that you use SLB instances that meet performance requirements. Exercise caution when using shared-performance instances that cannot guarantee performance metrics. |
| Use multi-zone SLB instances | If the SLB instance uses multi-node deployment, the instance is considered compliant. |
| Use multi-zone SLB instances and configure resources from multiple zones in server groups | If the SLB instance uses multi-node deployment and the server groups used by all listeners have resources from multiple zones added, the instance is considered compliant. |
ALB
| Rule name | Rule description |
| Enable health checks for all ALB listeners and forwarding rules | If health checks are configured for all listeners and forwarding rules of the ALB instance, the instance is considered compliant. |
| Add at least the specified number of servers to the default forwarding rule of all ALB listeners | If the default forwarding rule associated with each listener of the ALB instance has at least the number of backend servers specified by the parameter, the instance is considered compliant. Default value: at least one server is considered compliant. |
| Enable deletion protection for ALB instances | Deletion protection prevents instances from being accidentally released. If deletion protection is enabled, the instance is considered compliant. |
CEN
| Rule name | Rule description |
| Cross-region connection bandwidth of CEN instances meets the specified requirement | If the bandwidth allocated to all inter-region connections under the Cloud Enterprise Network (CEN) instance is greater than the value specified by the parameter, the instance is considered compliant. Default value: 1 Mbps. |
| Enable health checks for all VBR connections in CEN instances | If health checks are configured for all VBRs associated with the Cloud Enterprise Network (CEN) instance, the instance is considered compliant. |
ECS
| Rule name | Rule description |
| No duplicate IP address ranges across vSwitches in the same region | If no duplicate IP address ranges exist across vSwitches in the same region, the configuration is considered compliant. |
| ECS instances are not in the Stopped state | If the instance status of the ECS instance is not Stopped, the instance is considered compliant. |
| Check endpoint expiration of ECS subscription instances | For subscription resources, renew upfront to avoid service interruption caused by payment issues. If the expiration date of the prepaid instance is more than the specified number of days from the check time, the instance is considered compliant. Default value: 30 days. Instances with auto-renewal enabled are considered compliant. This rule does not apply to pay-as-you-go instances; such instances are considered not applicable. |
| Set reasonable creation timepoints for automatic snapshot policies | If the snapshot creation timepoints in the automatic snapshot policy fall within the time range specified by the parameter, the policy is considered compliant. Creating snapshots may temporarily reduce block storage I/O performance, typically by less than 10%, with brief instantaneous slowdowns. We recommend that you select timepoints outside business peak hours. |
| Do not open risky ports to all CIDR blocks for specified protocols in security groups | If the inbound CIDR block of the security group is set to 0.0.0.0/0 and the port range of the specified protocol does not contain the specified risky ports, the configuration is considered compliant. If the inbound CIDR block is not set to 0.0.0.0/0, the configuration is considered compliant even if the port range contains the specified risky ports. If the detected risky ports are denied by a higher-priority authorization policy, the configuration is considered compliant. This rule does not apply to security groups used by cloud products or virtual suppliers; such security groups are considered not applicable. |
| Do not use deprecated ECS instance families | If the ECS instance does not use the instance families specified by the parameter, the instance is considered compliant. Default value: discontinued or shared instance families. |
| Use specified operating system versions for ECS instances | Enterprises can standardize OS versions within the organization and require all production hosts to run a unified operating system version. Operating systems that are no longer maintained by the vendor should be upgraded in time to prevent security vulnerabilities. If the English name of the operating system used by the ECS instance is in the specified whitelist or is not in the specified blacklist, the instance is considered compliant. |
| Enable release protection for ECS instances | If release protection is enabled for the ECS instance, the instance is considered compliant. |
| Configure automatic snapshot policies for ECS disks | If an automatic snapshot policy is configured for the ECS disk, the disk is considered compliant. |
CDN
| Rule name | Rule description |
| Configure CDN caching for domains | If CDN caching and TTL are configured for the domain, the configuration is considered compliant. |
| Consistent origin configuration for CDN domains with OSS origin | If the origin domain name of a CDN domain is set to an OSS domain name and the origin type is set to OSS, the configuration is considered compliant. |
Message Queue for Apache Kafka
| Rule name | Rule description |
| Do not set the public IP whitelist of Message Queue for Apache Kafka instances to allow all IPs | If the public IP whitelist of the Message Queue for Apache Kafka instance is not set to allow access from all IPs, the instance is considered compliant. |
RocketMQ
| Rule name | Rule description |
| Use Platinum Edition RocketMQ instances | If the RocketMQ instance is Platinum Edition, the instance is considered compliant. |
Elasticsearch
| Rule name | Rule description |
| Disable public network access or restrict IP access for Elasticsearch instances | If public network access is disabled for the Elasticsearch instance or the whitelist is not set to allow access from all IPs, the instance is considered compliant. |
| Disable public network access to Kibana for Elasticsearch instances | If public network access to Kibana is disabled for the Elasticsearch instance or the whitelist is not set to allow access from all IPs, the instance is considered compliant. |
| Do not use deprecated Elasticsearch instance specifications | If the Elasticsearch instance does not use the specifications specified by the parameter, the instance is considered compliant. |
| Do not use deprecated Elasticsearch versions | If the version of the Elasticsearch instance is not in the deprecated version range specified by the parameter, the instance is considered compliant. |
| Enable automatic backup for Elasticsearch instances | If automatic backup is enabled for the Elasticsearch instance, the instance is considered compliant. |
| Use multi-zone Elasticsearch instances | If the Elasticsearch instance uses multi-node deployment, the instance is considered compliant. |
OSS
| Rule name | Rule description |
| Enable versioning for OSS buckets | If versioning is not enabled, data that is overwritten or deleted cannot be recovered. If versioning is enabled for the OSS bucket, the bucket is considered compliant. |
| Prohibit public read/write access to OSS buckets | If the ACL policy of the OSS bucket prohibits public read/write access, the bucket is considered compliant. |
| Enable zone-redundant storage for OSS buckets | If zone-redundant storage (ZRS) is not enabled, OSS cannot provide consistent services when a data center becomes unavailable, which affects data recovery objectives. If ZRS is enabled for the OSS bucket, the bucket is considered compliant. |
ACK
| Rule name | Rule description |
| Use Pro managed ACK clusters | If the ACK cluster is a Pro managed cluster, the cluster is considered compliant. This rule does not apply to non-managed clusters; such clusters are considered not applicable. |
| Upgrade ACK clusters to the latest version | If the ACK cluster is upgraded to the latest version, the cluster is considered compliant. |
| Enable release protection for ACK clusters | If release protection is enabled for the ACK cluster, the cluster is considered compliant. |
EIP
| Rule name | Rule description |
| Enable deletion protection for elastic IP addresses (EIPs) | If deletion protection is enabled for the elastic IP addresses (EIPs), the EIP is considered compliant. This rule does not apply to EIPs created by service accounts or prepaid EIPs; such EIPs are considered not applicable. |
| Check endpoint expiration of subscription elastic IP addresses (EIPs) | If the expiration date of the elastic IP addresses (EIPs) is more than the time range specified by the parameter from the current time, the EIP is considered compliant. Default value: 30 days. This rule does not apply to pay-as-you-go resources; such resources are considered not applicable. |
AnalyticDB for MySQL
| Rule name | Rule description |
| Set a reasonable maintenance window for AnalyticDB for MySQL clusters | If the maintenance window of the AnalyticDB for MySQL cluster falls within one of the time ranges specified by the parameter, the cluster is considered compliant. |
| Enable log backup for AnalyticDB for MySQL clusters | If log backup is enabled for the AnalyticDB for MySQL cluster, the cluster is considered compliant. |
| Check endpoint expiration of AnalyticDB for MySQL Data Warehouse Edition instances | If the expiration date of the AnalyticDB for MySQL Data Warehouse Edition instance is more than the time range specified by the parameter from the current time, the instance is considered compliant. Default value: 30 days. Instances with auto-renewal enabled are considered compliant. This rule only applies to subscription resources; pay-as-you-go instances are considered not applicable. |
ECI
| Rule name | Rule description |
| Mount data volumes to ECI elastic container groups | If data volumes are mounted to the Elastic Container Instance (ECI) elastic container group, the container group is considered compliant. |
Bastionhost
| Rule name | Rule description |
| Check endpoint expiration of Bastionhost instances | If the expiration date of the Bastionhost instance is more than the time range specified by the parameter from the current time, the instance is considered compliant. Default value: 30 days. |
Anti-DDoS
| Rule name | Rule description |
| Check endpoint expiration of Anti-DDoS instances | If the expiration date of the Anti-DDoS instance is more than the specified number of days from the current time, the instance is considered compliant. Default value: 30 days. |
Internet Shared Bandwidth
| Rule name | Rule description |
| Check endpoint expiration of Internet Shared Bandwidth instances | If the expiration date of the Internet Shared Bandwidth instance is more than the time range specified by the parameter from the current time, the instance is considered compliant. Default value: 30 days. |
CEN bandwidth plans
| Rule name | Rule description |
| Check endpoint expiration of CEN bandwidth plans | If the expiration date of the Cloud Enterprise Network (CEN) bandwidth plan is more than the time range specified by the parameter from the current time, the bandwidth plan is considered compliant. Default value: 30 days. |
PolarDB-X
| Rule name | Rule description |
| Check endpoint expiration of PolarDB-X 1.0 instances | If the expiration date of the PolarDB-X 1.0 instance is more than the specified number of days from the current time, the instance is considered compliant. Default value: 30 days. This rule only applies to subscription resources; pay-as-you-go instances are considered not applicable. |
| Check endpoint expiration of PolarDB-X 2.0 instances | If the expiration date of the PolarDB-X 2.0 instance is more than the specified number of days from the current time, the instance is considered compliant. Default value: 30 days. This rule only applies to subscription resources; pay-as-you-go instances are considered not applicable. |