Limits and billing of Log Audit Service - Simple Log Service

This topic describes the limits and billing of Log Audit Service.

Limits

Storage methods and region limits
Important
Before you use Log Audit Service for regional or centralized log storage, you must evaluate whether the storage region meets legal, regulatory, and security compliance requirements.
- Centralized storage
  Logs collected from different Alibaba Cloud accounts and regions are stored in a central project that belongs to the central account. The following regions are available for centralized storage.
  Note
  If you switch the region of the central account, Simple Log Service (SLS) creates a new central project. The original project is not deleted.
  - China: China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Hangzhou), China (Shanghai), China (Shenzhen), and China (Hong Kong)
  - Outside China: Singapore, Japan (Tokyo), Germany (Frankfurt), Indonesia (Jakarta), and Malaysia (Kuala Lumpur)
- Regional storage
  For SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS, Log Audit Service supports regional storage. Logs collected from each account are stored in an SLS project that belongs to the central account. The project is located in the same region as the service instance. For example, OSS access logs from an instance in the China (Hangzhou) region are stored in a project in the China (Hangzhou) region.
- Sync to center
  For regional storage of SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS logs, you can sync logstores from different regions to a central logstore. This enables centralized queries, analysis, alerting, visualization, and custom development.
  Note
  The sync mechanism relies on the data transformation feature of SLS. To prevent a negative impact on sync speed, you must adjust the shard resources of the regional logstore based on the data transformation performance guide.
Resource limits
- Only one central project can exist for the central account. The project is named slsaudit-center-CentralAccountID-ConfiguredRegion, for example, slsaudit-center-117938634953****-cn-beijing. You cannot delete the central project in the console. You can delete it only using the command line or an API.
- For SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS, you can have multiple regional projects. A project is named slsaudit-region-CentralAccountID-CollectionRegion, for example, slsaudit-region-117938634953****-cn-beijing. You cannot delete a regional project in the console. You can delete it only using the command line or an API.
- After you configure log collection for a cloud product, Log Audit Service creates a dedicated logstore. This logstore has all the features of a standard SLS logstore, with the following exceptions.
  - To prevent data tampering, you cannot write data to the logstore or modify or delete its indexes.
  - You can modify the storage duration or delete the logstore only on the configuration page of Log Audit Service or by calling an API.
  - When you enable Synchronization to Central Project, a data transformation task is automatically created in the corresponding regional project.
    - The data transformation task is named Internal Job: SLS Audit Service Data Sync for OSS Access, Internal Job: SLS Audit Service Data Sync for SLB, Internal Job: SLS Audit Service Data Sync for ALB, Internal Job: SLS Audit Service Data Sync for DRDS, Internal Job: SLS Audit Service Data Sync for VPC, or Internal Job: SLS Audit Service Data Sync for DNS.
    - You can stop this data transformation task only on the configuration page of Log Audit Service or by calling an API.
    - A regional logstore with the Synchronization to Central Project feature enabled syncs to a dedicated logstore. You cannot perform operations on this dedicated logstore. Instead, use the central logstore to run queries or perform other operations.

Permission limits

When you use Log Audit Service to collect Kubernetes logs, such as Kubernetes audit logs, Kubernetes Event Center logs, and Ingress access logs, the following permission limits apply.

Log Audit Service can collect Kubernetes logs only from the central account. It cannot collect Kubernetes logs from other member accounts in a multi-account setup.

Log Audit Service uses the data transformation feature to collect Kubernetes logs. Therefore, the central account must be granted the following permissions to collect these logs.

Item

Central account not upgraded

Central account upgraded

Current role of the central account

sls-audit-service-monitor

AliyunServiceRoleForSLSAudit

Additional permissions

The sls-audit-service-monitor role requires the AliyunLogAuditServiceMonitorAccess permission and the following custom permission (AliyunLogAuditServiceK8sAccess).

{
    "Version": "1",
    "Statement": [
        {
            "Action": "log:*",
            "Resource": [
                "acs:log:*:*:project/k8s-log-*"
            ],
            "Effect": "Allow"
        }
    ]
}

Only the AliyunServiceRoleForSLSAudit role is required. No additional permissions are needed.

Storage duration dependencies
- The following logs in Log Audit Service are stored in the same logstore (dns_log): internal DNS logs (centralized), public zone logs, and Global Traffic Manager logs. If you enable collection for these logs and set different storage durations, the longest duration applies.
- The following logs in Log Audit Service are stored in the same logstore (rds_log): ApsaraDB RDS audit logs, slow query logs, and error logs. If you enable collection for these logs and set different storage durations, the longest duration applies.
- The following logs in Log Audit Service are stored in the same logstore (polardb_log): PolarDB for MySQL audit logs, slow query logs, and error logs. If you enable collection for these logs and set different storage durations, the longest duration applies.
- The following logs in Log Audit Service are stored in the same logstore (cloudfirewall_log): Internet firewall traffic logs and VPC firewall traffic logs from Cloud Firewall. If you enable collection for these logs and set different storage durations, the longest duration applies.
- The following logs in Log Audit Service are stored in the same logstore (ddos_log): access logs from Anti-DDoS Proxy (Chinese Mainland), Anti-DDoS Proxy (Outside Chinese Mainland), and Anti-DDoS Origin. If you enable collection for these logs and set different storage durations, the longest duration applies.
- The following logs in Log Audit Service are stored in the same logstore (k8s_log): Kubernetes audit logs and Kubernetes Event Center logs. If you enable collection for these logs and set different storage durations, the longest duration applies.
- The following logs in Log Audit Service are stored in the same logstore (cloudconfig_log): Cloud Config change logs and Cloud Config resource non-compliance logs. If you enable collection for these logs and set different storage durations, the longest duration applies.
Note
For the log types with storage duration dependencies, if you enable log collection and intelligent tiered storage for these log types, the longest hot storage duration applies. If you enable log collection but do not enable intelligent tiered storage for all related log types, the intelligent tiered storage feature is disabled by default.
For example, you enable collection for ApsaraDB RDS audit logs and error logs. If you enable intelligent tiered storage for both, the longest hot storage duration applies. If you enable intelligent tiered storage only for ApsaraDB RDS audit logs but not for error logs, the intelligent tiered storage feature is disabled for their shared logstore (rds_log).
Configuration audit
- Log Audit Service relies on configuration information from Cloud Config. You must go to the Cloud Config console to enable the Cloud Config service and monitor all resources.
- To collect, store, or query configuration audit logs in Log Audit Service, you must authorize SLS to retrieve logs from Cloud Config. After you grant this authorization, your configuration audit logs are automatically pushed to SLS.
- If you use a resource directory for multi-account log collection, Log Audit Service automatically enables Cloud Config and integrates with SLS for the accounts in the resource directory after the central account is authorized. If you use custom authorization for multi-account log collection, the member accounts also require authorization. For more information, see Use custom authorization to collect and sync logs.
Intelligent tiered storage
The dedicated logstores of Log Audit Service support intelligent tiered storage. Compared with hot storage, IA storage is less expensive but has lower query and analysis performance. Other features, such as alerting, visualization, data transformation, and data shipping, are not affected. For more information, see Manage intelligent tiered storage.
Note
Intelligent tiered storage is supported in the following audit center regions: China (Qingdao), China (Beijing), China (Hohhot), China (Hangzhou), China (Shanghai), China (Shenzhen), China (Hong Kong), and Singapore.
You can enable intelligent tiered storage for Log Audit Service on the Global Configurations page. The hot storage duration must be at least 7 days and cannot exceed the total storage duration. For example, if the total storage duration is 180 days and you set the hot storage duration to 30 days, logs are converted to the IA storage class after 30 days.
Note
In Log Audit Service (Legacy), you cannot enable Archive Storage on the Global Configurations page. To enable Archive Storage, submit a ticket to add your account to the allowlist. After your account is added to the allowlist, the storage duration set in the global configurations applies only when the logstore is created. The actual storage duration is displayed in the logstore console.
Data encryption
Log Audit Service supports encryption using the service keys provided by SLS, but does not support Bring Your Own Key (BYOK). The service key encryption method supports the AES algorithm (default) and the SM4 encryption algorithm. For more information, see Encryption of data in-transit.
After you enable log encryption, SLS automatically encrypts the dedicated logstores for cloud products with log collection enabled. This includes logstores in both central and regional projects. For more information, see Enable encryption.
Index limits
Log Audit Service supports automatic index updates and manual index modification. For more information, see Create indexes.
If you receive the prompt This Logstore is dedicated to the Log Audit Service application. You cannot modify the index attributes of the Logstore or disable indexing. while modifying an index, navigate to the Global Configurations page of Log Audit Service, click Modify, and then click OK to rebuild the Log Audit Service configuration.
Important
Manually modifying indexes may cause built-in dashboards and alerts to become unavailable. Use this feature with caution.

Billing

SLS
The central account must have SLS and the Log Audit Service app enabled to collect logs from other accounts. By default, member accounts do not need to have SLS enabled and do not incur fees in their own SLS accounts. However, some cloud products may have different requirements. Log Audit Service is currently free of charge. However, you are charged on a pay-as-you-go basis for data storage, read/write traffic, and data transformation. For more information, see Pay-as-you-go billing items.
Important
- For logs from SLB, ALB, OSS, PolarDB-X 1.0, VPC, DNS, and Container Service for Kubernetes, if you enable the Sync To Center feature, the data transformation feature is used for synchronization. You are charged on a pay-as-you-go basis for data transformation and cross-network traffic. For more information, see Pay-as-you-go billing items.
- You can collect cloud product logs using Log Audit Service or the standard collection method. The fees for each method are calculated separately. If you use both methods, SLS stores two copies of the data. These two methods are intended for different scenarios.
  Log Audit Service: Supports real-time, automated, and centralized collection of cloud product logs from multiple accounts. The collected logs are mainly used for compliance audits.
  Standard method: Supports regional collection and decentralized management. The collected logs are mainly used for log analysis. For more information, see Overview of cloud service logs.
A free quota is available. You can also use purchased resource plans to offset the fees.

Cloud products

After you enable Log Audit Service and log collection for the corresponding cloud products, you may incur additional fees from the cloud products, which are described in the following table.

Cloud product	Additional fees
Web Application Firewall (WAF)	Purchase Log Service in the WAF console. For more information about billing, see Billing.
Security Center	Enable Log Analysis in the Security Center console. For more information about billing, see Billing overview.
Cloud Firewall	Purchase Log Analysis in the Cloud Firewall console. For more information about billing, see Billing of the log analysis feature.
ApsaraDB RDS	After you enable log collection for ApsaraDB RDS audit logs, the SQL Explorer and Audit feature is automatically enabled for RDS instances that meet the requirements (non-Basic editions that support MySQL, and High-availability Edition for PostgreSQL). For more information about billing, see Billing items. Note If you have enabled the trial version of SQL Explorer for an RDS instance, Log Audit Service automatically disables the trial version and enables the official version after you enable log collection. The default storage duration for SQL Explorer is 30 days. To modify the duration, go to the ApsaraDB RDS console. For more information, see Modify the storage duration of SQL logs. This storage duration is independent of the storage duration for ApsaraDB RDS audit logs in Log Audit Service. If you set the storage duration for SQL Explorer to less than 30 days in the ApsaraDB RDS console, the log shipping condition is not met. Log Audit Service automatically resets the duration to 30 days. If you have stopped collecting ApsaraDB RDS audit logs and want to disable the SQL Explorer feature, manually disable it in the ApsaraDB RDS console. For more information, see Disable SQL Explorer.
PolarDB	After you enable audit log collection for PolarDB, the SQL Explorer and Audit feature is automatically enabled for MySQL clusters. For more information about billing, see Billing overview. Note If you have enabled the trial version of SQL Explorer for a PolarDB instance, Log Audit Service automatically disables the trial version and enables the official version after you enable log collection. The default storage duration for SQL Explorer is 30 days. To modify the duration, go to the PolarDB console. For more information, see Modify the storage duration for SQL logs. This storage duration is independent of the storage duration for PolarDB audit logs in Log Audit Service. If you set the storage duration for SQL Explorer to less than 30 days in the PolarDB console, the log shipping condition is not met. Log Audit Service automatically resets the duration to 30 days. If you have stopped collecting PolarDB audit logs and want to disable the SQL Explorer feature, you can manually disable it in the PolarDB console. For more information, see Disable SQL Explorer and Audit.
Anti-DDoS	Purchase Log Analysis in the Anti-DDoS Proxy console. For more information about billing, see Overview.
VPC	The billing of flow logs consists of a flow log generation fee and SLS fees. For more information, see Flow log billing. Note You can enable VPC flow log collection in the Log Audit Service console or the VPC console. The two methods are independent. Enabling or disabling collection in one console does not affect the other. Flow log fees (flow log generation fee + SLS fee) are calculated separately for each method. Before you delete a project related to Log Audit Service, you must first disable VPC flow log collection. Otherwise, the flow log feature for the corresponding VPC-connected instance remains enabled.
DNS	You are charged for traffic analysis. For more information, see DNS.