Skip to content

Tencent Cloud Explanation

What this page covers

How Tencent Cloud fits together for complex projects, and why the main architecture patterns look the way they do: single-VPC, multi-VPC (CCN), multi-account governance (TCO, CAM, Identity Center), multi-AZ and multi-region, disaster recovery, perimeter security, landing zones, and the security model. Look-up tables (region IDs, service-name mapping, product tiers, limits) are in Reference. Commands are in How-to Guides.

Platform Architecture Overview

The diagram shows the layers of a typical multi-account Tencent Cloud estate. Governance sits in the TCO management account, shared networking in a hub account, and workloads in member accounts.

flowchart TB
    subgraph GOV["Governance layer (TCO management account)"]
        TCO["Tencent Cloud Organization<br/>departments + member accounts"]
        SCP["Service control policies<br/>+ tag policies"]
        CIC["Identity Center<br/>SAML IdP + SCIM"]
        CC["Control Center<br/>landing zone + account factory"]
    end
    subgraph NET["Network layer (hub account)"]
        CCN["CCN instance<br/>route tables"]
        DCG["Direct Connect gateway"]
        VPNG["VPN gateway"]
    end
    subgraph WL["Workload layer (member accounts)"]
        VPC1["VPC prod<br/>CLB + CVM/TKE + CDB"]
        VPC2["VPC non-prod"]
    end
    subgraph OBS["Audit and logs (log account)"]
        CA["CloudAudit tracking set"]
        CLS["CLS / COS log buckets"]
    end
    CC --> TCO
    TCO --> SCP
    CIC -->|"role configurations"| VPC1
    CIC -->|"role configurations"| VPC2
    VPC1 --- CCN
    VPC2 --- CCN
    DCG --- CCN
    VPNG --- CCN
    VPC1 -.->|"API events"| CA
    VPC2 -.->|"API events"| CA
    CA --> CLS

1. Single Project with Single VPC

Architecture Summary

A Virtual Private Cloud (VPC) is the foundational building block on Tencent Cloud. A VPC is an isolated virtual network where you define a private CIDR block, create subnets in Availability Zones, and attach route tables and gateways. For a single project, one VPC with multi-AZ subnets gives network isolation, high availability, and simple operations.

CIDR blocks cannot be modified after VPC or subnet creation

Plan IP address space carefully before provisioning. When the primary CIDR cannot support growth, add a secondary CIDR to expand the range.

The request path in a single-VPC, three-tier deployment:

flowchart TB
    NET(["Internet"]) --> WAF["WAF"]
    WAF --> CLB["CLB<br/>public subnet, AZ-a + AZ-b"]
    subgraph VPC["VPC 10.0.0.0/16"]
        CLB --> APPA["CVM app<br/>private subnet AZ-a"]
        CLB --> APPB["CVM app<br/>private subnet AZ-b"]
        APPA --> CDB["CDB MySQL source<br/>data subnet AZ-a"]
        APPB --> CDB
        CDB -->|"semi-sync replication"| CDBR["CDB replica<br/>AZ-b"]
        APPA --> NAT["NAT Gateway"]
        APPB --> NAT
    end
    NAT -->|"SNAT outbound"| NET

Key Services

Service Role
VPC Isolated virtual network with custom CIDR from 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 sub-ranges
Subnet Bound to a single AZ. Every Tencent Cloud resource with a private IP is deployed in a subnet
Route Table Default route table (auto-created per VPC) + custom route tables. Controls next-hop forwarding
Security Group Stateful per-instance firewall. Controls inbound/outbound traffic by protocol and port
Network ACL Stateless subnet-level packet filter
CLB (Cloud Load Balancer) Layer 4/7 load balancing across CVM, TKE pods, or CCN-connected backends. TCP, UDP, HTTP, HTTPS, QUIC
NAT Gateway Outbound Internet access (SNAT) and inbound port mapping (DNAT). Up to 10M concurrent connections (vendor figure, as of 2026-04)
EIP (Elastic IP) Public IP that can be bound to NAT Gateway, CLB, or individual CVM
  • CIDR planning: Use RFC 1918 ranges. VPC CIDRs must not overlap with any VPC you plan to connect later via Peering or CCN. Start with /16 for the VPC and /24 for subnets.
  • Multi-AZ subnets: Create at least two subnets in different AZs. Place CLB backends and CDB replicas in both. A single VPC spans all AZs in its region.
  • Subnet tiers: Segment into public (DMZ), private (application), and data (database) subnets. Use route tables and Network ACLs to enforce tiered traffic flow.
  • No public IPs on app/DB: Application and database instances get no EIPs. Use NAT Gateway (SNAT) for outbound Internet and CLB for inbound.
  • Security Groups: One SG per tier (web, app, db), least-privilege rules. Rules are evaluated top-to-bottom and the first match wins. Back up SG rules before modifying. Combine Security Groups with Network ACLs for defense in depth.
  • Reserved IPs: Tencent Cloud reserves the first two and last IP of every subnet CIDR.
  • Secondary CIDR: Extend the address space without recreating the VPC.

Real-World Example

A SaaS startup deploys a three-tier web application in the Guangzhou region. One VPC (10.0.0.0/16) has subnets in AZ-3 and AZ-4. Public subnets host a CLB instance (HTTP/HTTPS listeners). Private subnets host CVM auto-scaling groups running application containers. A two-node CDB for MySQL (semi-sync) instance runs with a cross-AZ replica. A NAT Gateway provides egress for pulling container images and calling third-party APIs. Security Groups restrict app-tier ingress to the CLB.

2. Multi-VPC Architecture

When workloads span multiple VPCs (environment isolation, business-unit separation, regulatory boundaries), Tencent Cloud offers three inter-VPC connectivity options.

2a. Cloud Connect Network (CCN) -- Full-Mesh

Architecture Summary

CCN is Tencent Cloud's managed transit network. It connects VPCs in any region, Direct Connect gateways, and VPN gateways into one routing domain. CCN uses MPLS-VPN technology for tenant isolation and learns routes automatically, so topology changes do not need manual route updates. Once a network instance is attached, it can reach every other attached instance allowed by the CCN route tables.

The diagram shows one CCN instance with two route tables that keep production and non-production apart while both reach the on-premises IDC:

flowchart LR
    subgraph CCN["CCN instance ccn-xxxx (hub account)"]
        RTP["Route table: prod"]
        RTN["Route table: non-prod"]
    end
    subgraph GZ["ap-guangzhou"]
        V1["VPC prod-gz"]
        V2["VPC dev-gz"]
    end
    subgraph SG["ap-singapore"]
        V3["VPC prod-sg"]
    end
    subgraph JK["ap-jakarta (member account)"]
        V4["VPC prod-jk<br/>cross-account attach"]
    end
    IDC["On-prem IDC"] --> DC["Direct Connect gateway"]
    IDC -.->|"IPsec backup"| VPN["VPN gateway (CCN type)"]
    V1 --- RTP
    V3 --- RTP
    V4 --- RTP
    V2 --- RTN
    DC --- RTP
    DC --- RTN
    VPN --- RTP

Key Features

Capability Detail
Full-mesh Any-to-any connectivity. No individual peering connections
Automatic route learning Attached VPC, DC gateway, and VPN gateway routes are published into CCN automatically
MPLS-VPN isolation Tenant networks isolated at the data plane. Not encryption on the wire
Multiple route tables Associate instances with different route tables and use input, broadcast, and selection policies to control which routes each group learns
Route conflict handling Overlapping CIDRs are not activated by default. Newer options allow overlapping routes and ECMP (Terraform route_overlap_flag, route_ecmp_flag)
Cross-account VPCs from other accounts can attach. The CCN owner must accept the attachment
VPN Gateway for CCN IPsec tunnels attached directly to CCN, giving encrypted access from many IDCs
Service levels Platinum, Gold, Silver quality tiers for cross-region traffic
Billing First 5 Gbps same-region is free. Cross-region by monthly 95th percentile. Hourly instance and traffic-processing fees since 2023-07. See Reference

2b. Peering Connection -- Point-to-Point

Peering Connection is a direct, one-to-one VPC link. Unlike CCN it is not transitive: fully connecting N VPCs takes N*(N-1)/2 peering connections.

When to use Peering Connection vs CCN

Use Peering for a simple two-VPC link. Use CCN when three or more VPCs need to talk, or when VPCs span several regions or accounts.

2c. VPN Gateway -- Encrypted Tunnel

VPN Gateway creates IPsec tunnels between a VPC and an on-premises IDC, between VPCs, or to another cloud. The CCN type of VPN gateway attaches tunnels directly to a CCN instance.

A common hybrid pattern uses Direct Connect as primary and VPN as secondary. When the Direct Connect link fails, CCN withdraws its routes and traffic fails over to the VPN tunnel.

Connectivity Comparison Matrix

Criterion CCN Peering Connection VPN Gateway
Topology Full-mesh (any-to-any) Point-to-point Point-to-point tunnel
Transitivity Yes No No (unless attached to CCN)
Multi-region Yes (cross-region bandwidth billed) Yes (cross-region peering) Yes (over public Internet)
Multi-account Yes Yes (cross-account peering) Limited
Routing Automatic learning + route tables and policies Manual routes Manual routes (or learned when attached to CCN)
Encryption MPLS-VPN isolation (not encrypted on wire) No encryption IPsec encryption
Bandwidth 5 Gbps free same-region. Cross-region billed by 95th percentile Configurable per connection Depends on gateway spec
Latency Private backbone Private backbone Internet-dependent
Use case Enterprise multi-VPC, hybrid cloud, multi-region Simple two-VPC link Hybrid cloud, branch office, cross-cloud
Migration Target architecture Legacy. Move to CCN as you grow Backup to Direct Connect
  • Prefer CCN for any topology with three or more VPCs.
  • CIDR discipline: Plan non-overlapping CIDRs across all VPCs. CCN can detect conflicts at subnet level, but non-overlapping VPC CIDRs are the safest approach.
  • Multiple route tables: Isolate segments, for example production VPCs cannot route to development VPCs.
  • Hybrid DR: Direct Connect primary, VPN Gateway for CCN secondary.
  • Encrypt sensitive traffic yourself (TLS, IPsec) when you need encryption on the wire. CCN isolates but does not encrypt.

Real-World Example

A financial services company runs in Shanghai, Guangzhou, and Singapore with separate VPCs per region and environment (prod/staging). Six VPCs join a single Gold-tier CCN instance. Separate route tables isolate production from staging. A Direct Connect circuit from the Shanghai IDC reaches CCN through a DC gateway, with a CCN-type VPN gateway as warm standby. Cross-region bandwidth is billed by the monthly 95th percentile. Traffic between Shanghai and Singapore is cross-border and billed separately.

3. Multi-Account / Multi-Project Governance

Architecture Summary

Tencent Cloud splits multi-account governance across complementary services:

  • Tencent Cloud Organization (TCO) -- manages many accounts under one organization. It has a tree of departments (the TCO term for organizational units), member accounts, service control policies (SCPs), tag policies, resource sharing, and consolidated finance.
  • TCO Identity Center (CIC) -- workforce SSO across member accounts. It holds users and groups (manual or synced by SCIM), trusts one external SAML 2.0 IdP, and assigns "role configurations" (permission sets) to accounts.
  • Cloud Access Management (CAM) -- identity and permissions inside a single account: sub-users, collaborators, roles, policies, role SSO (SAML/OIDC), and MFA.
  • Control Center -- a landing-zone service on top of TCO (see section 7).

The account hierarchy below uses departments by lifecycle stage. Policies attached to a department apply to every member account under it.

flowchart TB
    ROOT["Root department<br/>management account: org + billing"]
    ROOT --> CORE["Dept: Core"]
    ROOT --> PROD["Dept: Production"]
    ROOT --> NP["Dept: Non-production"]
    ROOT --> SBX["Dept: Sandbox"]
    CORE --> LOG["Log archive account<br/>CloudAudit + CLS/COS"]
    CORE --> SEC["Security account<br/>CFW, WAF, Cloud Security Center"]
    CORE --> NETA["Network account<br/>CCN, DC gateway, shared NAT"]
    PROD --> P1["BizUnit-1 prod"]
    PROD --> P2["BizUnit-2 prod"]
    NP --> S1["Staging"]
    NP --> D1["Dev"]
    SBX --> X1["Sandbox accounts"]
    SCPR["SCP: FullAccess + region allow-list"] -.-> ROOT
    SCPP["SCP: deny CAM user creation"] -.-> PROD
    TAGP["Tag policy: env, team, cost-center"] -.-> ROOT

Key Services

Service Role
TCO Organization tree, member account lifecycle (create, invite, remove), consolidated finance
Service Control Policies (SCP) Guardrails on departments or accounts. Limit which actions member-account CAM can grant
Tag policies Standard tag keys and values across members. Non-compliant resources are reported
Identity Center Multi-account SSO with SAML 2.0 and SCIM, and permission sets per account
CAM Per-account IAM: sub-users, collaborators, roles, policies, temporary credentials, MFA
Resource Tags Key-value metadata for cost allocation, ownership, and tag-based CAM conditions
CloudAudit API audit log. 90-day event history. Tracking sets deliver to COS, CLS, or CKafka, optionally for all members

The CAM identity types (root, sub-user, collaborator, message recipient, role) are listed in Reference.

Service Control Policies (SCPs)

SCPs work as an allow-list across the whole path from the root to the member account. The root, every department, and every account start with the FullAccess policy. When you replace it with a narrower allow policy at some level, everything below that level is limited to it. A deny at any level is inherited and cannot be overridden. The flow below shows how a single API call from a member-account sub-user is evaluated:

flowchart TD
    REQ["API call from sub-user<br/>in member account"] --> SCPCHK{"Allowed by an SCP at<br/>root, every department,<br/>and the account?"}
    SCPCHK -->|"No, or explicit deny"| DENY1["Denied (SCP boundary)"]
    SCPCHK -->|"Yes"| CAMDENY{"Explicit deny in<br/>CAM policies?"}
    CAMDENY -->|"Yes"| DENY2["Denied"]
    CAMDENY -->|"No"| CAMALLOW{"Allowed by a CAM<br/>policy on user, group, or role?"}
    CAMALLOW -->|"No"| DENY3["Denied (implicit)"]
    CAMALLOW -->|"Yes"| OK["Allowed"]

SCP + CAM interaction

Effective permissions = intersection of SCP permissions and CAM permissions. SCPs set the maximum boundary. CAM grants the actual permissions inside that boundary. SCPs never grant anything.

Answer to an earlier open question

TCO SCPs are allow-list based with inherited denies, like AWS Organizations SCPs, and use CAM policy syntax. TCO also has tag policies (policy type TAG_POLICY). How TCO SCP condition keys compare in detail with Alibaba Resource Directory control policies is an open question on the hub page.

Identity Center Sign-In Flow

Identity Center replaces per-account SAML setup. The sequence shows a user signing in through an external IdP and landing in a member account with a role configuration:

sequenceDiagram
    participant U as Employee browser
    participant IDP as Corporate IdP (Entra ID, Okta)
    participant CIC as TCO Identity Center
    participant MEM as Member account (CAM role)
    IDP->>CIC: SCIM push of users and groups
    U->>CIC: Open user portal URL
    CIC->>U: Redirect with SAML AuthnRequest
    U->>IDP: Authenticate (password + MFA)
    IDP->>U: SAML assertion
    U->>CIC: Post assertion
    CIC->>U: Show assigned accounts and role configurations
    U->>CIC: Pick account + role configuration
    CIC->>MEM: Provisioned CAM role (from role configuration)
    MEM-->>U: Console session with temporary credentials
  • Account per environment and function: Separate accounts for production, staging, development, and shared services (log archive, security, network).
  • Department hierarchy: Group accounts by lifecycle stage (Core / Production / Non-production / Sandbox) and attach SCPs per department.
  • Identity Center for people: Connect the corporate IdP (Entra ID, Okta, others) to Identity Center with SAML 2.0 and SCIM. Do not create sub-users for every employee in every account.
  • OIDC role SSO for pipelines: Let CI/CD and TKE workloads assume CAM roles with OIDC tokens instead of long-lived API keys.
  • Least-privilege CAM policies: Use conditions (source IP, MFA, resource tags) to tighten access.
  • Consolidated finance: View all member costs from the management account. Use member financial permissions to control who can see bills.
  • Tags: Enforce mandatory tags (env, team, cost-center) with tag policies, and use them for cost allocation.

Real-World Example

A conglomerate with three subsidiaries manages 12 Tencent Cloud accounts under one TCO organization. The Core department holds the network account (CCN hub), the log archive account (CloudAudit tracking set for all members, COS bucket), and the security account (Cloud Firewall, WAF). The Production department holds six production accounts (two per subsidiary), with SCPs limiting resource creation to approved regions. The Non-production department holds three sandbox accounts with relaxed SCPs but budget alerts. All staff sign in through Identity Center federated to the corporate Okta tenant.

4. Multi-AZ / Multi-Region

Architecture Summary

Tencent Cloud reported 66 availability zones across 23 regions on 2026-08-18, up from 64 AZs across 22 regions in 2026-03. Mainland China regions include Beijing, Shanghai, Guangzhou, Nanjing, Chengdu, Chongqing, and the Shanghai and Shenzhen finance zones. International regions include Hong Kong, Singapore, Jakarta, Bangkok, Seoul, Tokyo, Silicon Valley, Virginia, Toronto, Frankfurt, Sao Paulo, Saudi Arabia (announced 2025-02), and Johor in Malaysia (2026-08). Osaka was announced in 2025-04 with a 2026 launch. The full table with IDs is in Reference.

Multi-AZ deployment keeps resources in several data centers in one region for high availability. Multi-region deployment replicates infrastructure across geographies for DR, latency reduction, and data residency.

Southeast Asia

Southeast Asia is Tencent's densest international footprint: Singapore, Jakarta (3 AZs), Bangkok, and Johor (2 AZs live, a third planned). Jakarta plus Singapore is the usual pair for Indonesian data-residency workloads with a regional DR copy.

Key Services for Multi-AZ / Multi-Region

Service Multi-AZ / Multi-Region Role
CLB Primary/standby clusters across AZs in a region. Automatic AZ failover. Cross-region binding 2.0 via CCN
CDB (TencentDB for MySQL) Two-node (source + replica cross-AZ), three-node (two replicas in different AZs), Cluster Edition
TDSQL for MySQL Distributed database with intra-city active-active, 1-region-2-DC, and 2-region-3-DC deployments. Strong sync replication
TDSQL-C Cloud-native MySQL/PostgreSQL with serverless compute and multi-AZ storage
TencentDB for Redis Master and replica nodes across AZs. Read/write separation routes reads to a local-AZ replica
COS Multi-AZ (MAZ) storage classes within a region. Cross-region replication between buckets for DR
GAAP Acceleration nodes worldwide. Tunnels TCP/UDP/HTTP/HTTPS from the user's region to the origin region
DNSPod Geo-based and weighted DNS routing. Used with CLB for global load balancing
CCN Cross-region VPC interconnection over the private backbone. Enables cross-region CLB binding

CLB Cross-AZ and Cross-Region

CLB offers two levels of geographic distribution:

  1. Cross-AZ (default): CLB runs clusters across AZs in a region. If an AZ fails, traffic routes to the surviving AZ. Bind CLB to CVM instances in several AZs for real-server-level HA.
  2. Cross-Region Binding 2.0: Uses CCN to bind CLB to backends in another region or VPC. The fee is charged on the CCN instance, not the CLB. Prerequisites (as of 2026-04): a bill-by-IP account, a CCN instance, and the target VPC attached to it.

Global load balancing combines regional CLB instances with DNSPod geo-routing.

CDB (TencentDB for MySQL) Multi-AZ Architectures

Architecture Nodes Replication Cross-AZ Use Case
Two-Node 1 source + 1 replica Async or semi-sync Source and replica in different AZs Standard HA
Three-Node 1 source + 2 replicas Semi-sync or strong sync Replicas in different AZs Financial-grade HA
Cluster Edition 1 primary + N read replicas Decoupled compute/storage Multi-AZ compute nodes Elastic read scaling

CDB uses the TXSQL kernel (Tencent's MySQL branch), which adds InnoDB and replication optimizations and enterprise features (TDE, audit, read/write separation). Tencent publishes 99.9996% data reliability and 99.95% service availability for CDB.

Cross-region DR: CDB can create disaster recovery instances in a remote region. Data replicates continuously over Tencent's private network. The DR instance can be promoted to a source instance.

GAAP (Global Application Acceleration Platform)

GAAP reduces cross-border and cross-region latency. It builds high-speed tunnels between the user's region and the origin region, avoiding congested public Internet paths. Tencent's product page cites 50+ nodes, and up to 10 Gbps and one million concurrent requests per connection. It supports TCP, UDP, HTTP, and HTTPS, end-to-end health checks, and per-connection monitoring of bandwidth, latency, and packet loss.

  • Multi-AZ by default: Deploy CVM, CDB, and Redis across at least two AZs, with CLB in front.
  • Three-node CDB for financial or mission-critical workloads, with replicas in separate AZs.
  • COS MAZ storage class for in-region durability. Add cross-region replication for DR.
  • GAAP for users on another continent from the origin. Monitor latency and packet-loss metrics per connection.
  • DNSPod + CLB for global load balancing: resolve one domain to different regional CLB VIPs.

Real-World Example

A global gaming company runs its matchmaking service in Shanghai, Frankfurt, and Virginia. Each region has a VPC with multi-AZ subnets and a CLB. A three-node CDB (strong sync) holds game state in Shanghai, with a DR instance in Frankfurt. GAAP tunnels player traffic from South America to the Virginia origin and from Southeast Asia to the Shanghai origin. DNSPod resolves the API domain to the nearest regional CLB VIP.

5. Disaster Recovery (DR) Patterns

Architecture Summary

Tencent Cloud supports DR strategies from backup-and-restore to active-active. The main enablers are DTS (Data Transmission Service) for database replication, COS cross-region replication for objects, and CDB/TDSQL HA features.

Key DR Services

Service DR Role
DTS Migration, real-time sync, and binlog subscription. Supports one-way and two-way sync for active-active and cross-border sync
CDB Disaster Recovery Instance Read-only instance in a remote region, synced over the private network. Promotable to source
TDSQL for MySQL Intra-city active-active in finance zones. 1-region-2-DC and 2-region-3-DC deployments with strong sync (MAR)
TDSQL-C Multi-AZ storage replication with automatic failover
COS Cross-Region Replication Incremental object sync between buckets in different regions. Requires versioning
SCF Runs DR switchover logic (health checks, DNS updates, failover triggers)
EventBridge Event-driven orchestration. Triggers SCF functions on failure events
DNSPod DNS failover between primary and DR endpoints

DR Strategy Comparison

Strategy RPO RTO Cost Tencent Cloud Implementation
Backup & Restore Hours Hours Lowest CDB automated backups (binlog + physical). COS lifecycle. Restore on demand
Pilot Light Minutes 10-30 min Low CDB DR instance at minimum spec. COS replication. Scale on failover
Warm Standby Minutes Minutes Medium CDB DR instance (running, read-only). CLB + CVM at reduced capacity in DR region. DTS continuous sync
Active-Active Near zero Near zero Highest TDSQL intra-city active-active. DTS two-way sync. Dual CLB with DNSPod weighted routing

The RPO/RTO figures are typical ranges for each strategy, not Tencent SLAs.

COS Cross-Region Replication DR

COS cross-region replication is the main mechanism for object-storage DR. It syncs incremental data from a source bucket to a destination bucket in another region. The flow shows a primary/DR pair with automated failover:

flowchart LR
    subgraph SH["ap-shanghai (primary)"]
        BA["COS bucket A<br/>versioning on"]
        APPP["App primary"]
    end
    subgraph SGP["ap-singapore (DR)"]
        BB["COS bucket B<br/>versioning on"]
        APPD["App DR"]
    end
    BA -->|"cross-region replication"| BB
    BB -.->|"reverse replication after failback"| BA
    APPP --> BA
    APPD --> BB
    EB["EventBridge / Cloud Monitor alarm"] --> SCF["SCF failover function"]
    SCF -->|"switch records"| DNS["DNSPod"]
    DNS -->|"clients"| APPP
    DNS -.->|"after failover"| APPD

Key characteristics:

  • Versioning must be enabled on both buckets.
  • Replication is incremental. Objects arrive in seconds to minutes depending on size and distance.
  • Failover: when bucket A is unreachable, the SCF function switches client traffic to bucket B. Reverse replication resyncs bucket A after it recovers.
  • Cost: replicate only hot data (for example by prefix) to reduce storage costs in the DR bucket.
  • Combine MAZ storage classes (in-region, cross-IDC redundancy) with cross-region replication.

DTS Capabilities

DTS is the workhorse for database DR:

  • Data Migration: One-time full + incremental migration with minimal downtime, into Tencent Cloud, between TencentDB instances, or from other clouds.
  • Data Synchronization: Continuous real-time sync between two instances, including two-way sync for active-active.
  • Data Subscription: Streams binlog changes to downstream consumers (data warehouses, event pipelines).

DTS replicates over Tencent's private network, which lowers latency and loss risk compared with public-network replication.

TDSQL Multi-DC Architectures

Architecture Description Failover Data Consistency
1-Region-2-DC Primary and replica nodes in two data centers in the same city Automatic Strong sync (MAR)
2-Region-3-DC Three data centers across two regions Automatic Strong sync (MAR). Zero data loss in the synchronous pair
Intra-city Active-Active Both DCs serve read/write traffic behind the same VIP Automatic, transparent to the application Strong sync

TDSQL implements strong sync with MAR (Multi-thread Asynchronous Replication), a Tencent kernel optimization that brings strong-sync throughput close to asynchronous replication. It reduces the usual performance penalty of synchronous replication. How it behaves above 50 ms RTT is an open question (see the hub page).

  • Warm standby as the default DR strategy for most production workloads: CDB DR instance + DTS sync + COS cross-region replication + reduced-capacity CLB/CVM in the DR region.
  • Active-active for financial and payment workloads: TDSQL intra-city active-active in finance zones.
  • Automate failover: SCF + EventBridge + DNSPod detect failures, promote DR instances, and switch DNS.
  • Test DR regularly: Promote the DR CDB instance in a test window to measure RTO. Simulate a bucket-A failure to check the SCF switchover logic.

Real-World Example

Airstar Bank, a Hong Kong virtual bank, moved its entire operations onto Tencent Cloud in a project started in December 2023 and announced in April 2025. Tencent designed a multi-layer DR architecture covering traffic access, applications, and data storage. The result is cross-AZ dual-active DR with second-level switching on extreme failures. Databases were migrated with Tencent's DBbridge tool without rollbacks (announcement).

6. DMZ / Perimeter Security Patterns

Architecture Summary

Tencent Cloud implements defense in depth with layered managed services instead of a physical DMZ. Each layer removes one class of threat before traffic reaches the application:

flowchart LR
    C(["Client"]) --> AD["Anti-DDoS Pro/Advanced<br/>L3/L4 volumetric"]
    AD --> EO["EdgeOne / CDN<br/>cache, L7 DDoS, bots"]
    EO --> WAF["WAF<br/>OWASP Top 10, CC"]
    WAF --> CFWI["CFW Internet firewall<br/>IPS, virtual patching"]
    CFWI --> CLB["CLB"]
    CLB --> CVM["CVM / TKE<br/>private subnet"]
    CVM -->|"outbound"| NATFW["CFW NAT firewall"]
    NATFW --> OUT(["Internet"])

Subnet tiering inside the VPC adds network-level isolation between public, application, and data tiers.

Key Security Services

Service Role
Anti-DDoS Basic Free 2 Gbps protection, auto-enabled on Tencent Cloud public IPs
Anti-DDoS Pro Paid protection bound to Tencent Cloud resources (CVM, CLB, WAF, NAT). No IP change
Anti-DDoS Advanced Paid high-defense IPs for any Internet service. Hides the origin IP
Tencent EdgeOne CDN + DDoS + WAF + bot protection at the edge. Anycast outside mainland China
WAF OWASP Top 10 defense, CC protection, bot management, API protection
Cloud Firewall (CFW) Internet firewall with IPS and virtual patching, NAT firewall for outbound, inter-VPC firewall for east-west
Security Group Instance-level stateful firewall
Network ACL Subnet-level stateless packet filter

Tier and edition details (capacities, pricing models, CFW Premium/Enterprise/Ultimate) are in Reference.

CFW replaces traditional DMZ management

Cloud Firewall can implement DMZ-style zoning for VPC networks. It focuses protection on core assets and isolates VPC segments, like traditional DMZ zones but with cloud-native controls.

Subnet Tiering Pattern

The three tiers and the controls on each boundary:

flowchart TB
    subgraph VPC["VPC 10.0.0.0/16"]
        subgraph PUB["Public tier 10.0.1.0/24"]
            CLB["CLB"]
            NAT["NAT Gateway"]
        end
        subgraph APP["Application tier 10.0.10.0/24"]
            CVM["CVM app servers"]
        end
        subgraph DATA["Data tier 10.0.20.0/24"]
            DB["CDB, Redis, ES"]
        end
    end
    NET(["Internet"]) -->|"Anti-DDoS + WAF"| CLB
    CLB -->|"SG: allow from CLB only"| CVM
    CVM -->|"SG + ACL: DB ports from app CIDR only"| DB
    CVM --> NAT
    NAT -->|"CFW NAT firewall"| NET
  1. Anti-DDoS Pro/Advanced absorbs volumetric attacks at the network edge.
  2. EdgeOne / CDN caches static content and adds L7 DDoS protection.
  3. WAF inspects HTTP/HTTPS traffic for application-layer attacks (SQL injection, XSS, bots).
  4. CLB distributes clean traffic to CVM instances in private subnets.
  5. CFW NAT firewall controls outbound connections from CVM and blocks C2 callbacks and exfiltration.
  6. CFW inter-VPC firewall isolates east-west traffic between VPCs.
  7. Security Groups give the final layer of least-privilege access control.
  • Check Anti-DDoS Basic thresholds (it is auto-enabled, but know when blackholing starts).
  • Bind Anti-DDoS Pro to WAF and CLB addresses for combined L3/L4 + L7 protection.
  • Use CFW Enterprise edition or higher for multi-VPC environments to inspect east-west traffic.
  • NAT firewall for outbound traffic control.
  • Network ACLs on the data-tier subnet: allow only application-tier CIDRs on database ports.
  • No direct Internet access for data-tier or application-tier subnets. Route outbound through NAT Gateway, monitored by CFW.

Real-World Example

An e-commerce platform in Guangzhou deploys Anti-DDoS Advanced (hiding the origin IP), EdgeOne for CDN and bot mitigation, and WAF for application-layer defense. Traffic flows through CLB into CVM instances in a private subnet. CFW Enterprise edition monitors east-west traffic between the order-processing VPC and the payment VPC. The NAT firewall inspects all outbound connections and blocks known malicious domains. CDB for MySQL sits in a data subnet whose Network ACL allows only TCP 3306 from the application subnet CIDR.

7. Landing Zone / Governance

Architecture Summary

Correction (2026-09)

Earlier versions of this note said Tencent Cloud has no packaged landing-zone product. That is out of date. Tencent Cloud Control Center sets up a landing zone on top of TCO: organization structure, core accounts, finance policies, security rules, compliance auditing, and an account factory with baselines. Terraform support started with tencentcloud_controlcenter_account_factory_baseline_config in provider 1.82.44 (2025-12-10).

You can build a landing zone three ways:

  1. Control Center (console-driven): configure the landing zone, then create accounts through the account factory with baseline items applied.
  2. Terraform: TCO, Identity Center, CAM, CloudAudit, Config, and CCN resources in the tencentcloud provider, or the tencentcloud-landing-zone-booster modules (network hub, logging account, CAM/SSO, security baseline).
  3. Manual assembly from the individual services, as described in the building blocks below.
AWS Tencent Cloud
AWS Organizations Tencent Cloud Organization (TCO)
Service Control Policies TCO service control policies
Tag policies TCO tag policies
IAM Identity Center TCO Identity Center
IAM Cloud Access Management (CAM)
CloudTrail (organization trail) CloudAudit tracking set with "track for all members"
AWS Config Config (rules, compliance packs, remediation)
Security Hub / GuardDuty Cloud Security Center
Control Tower + Account Factory Control Center (landing zone + account factory)
Resource Access Manager TCO resource sharing (share units)

The target landing zone, with the controls each core account owns:

flowchart TB
    subgraph MGMT["Management account"]
        CC["Control Center<br/>landing zone + account factory"]
        TCO["TCO: departments, SCPs, tag policies"]
        CIC["Identity Center<br/>SAML IdP + SCIM"]
        FIN["Consolidated finance"]
    end
    subgraph LOGA["Log archive account"]
        TRAIL["CloudAudit tracking set<br/>TrackForAllMembers"]
        COSL["COS bucket: versioning,<br/>lifecycle, object lock"]
        CLSL["CLS log topics"]
    end
    subgraph SECA["Security account (delegated admin)"]
        CSC["Cloud Security Center"]
        CFG["Config rules +<br/>compliance packs"]
        CFW["Cloud Firewall"]
    end
    subgraph NETA["Network account"]
        CCN["CCN + route tables"]
        EGR["Shared NAT / egress VPC"]
        DCG["Direct Connect gateway"]
    end
    subgraph WORK["Workload accounts (from account factory)"]
        W1["Prod account VPC"]
        W2["Non-prod account VPC"]
    end
    CC -->|"baseline"| WORK
    TCO -->|"SCP guardrails"| WORK
    CIC -->|"role configurations"| WORK
    WORK -->|"API events"| TRAIL
    TRAIL --> COSL
    TRAIL --> CLSL
    WORK --- CCN
    CCN --- EGR
    CCN --- DCG
    CFG -.->|"evaluate"| WORK

CloudAudit

CloudAudit is the API audit log. Event history covers the last 90 days. A tracking set delivers events to COS, CLS, or CKafka for longer retention. When created in the TCO management account (or a delegated account) with "track for all members", one tracking set collects events from every member account. CloudAudit itself is free. You pay for the destination storage. Field and feature details are in Reference.

Governance Building Blocks

  1. TCO organization: Create it from the management account. Define departments (Core, Production, Non-production, Sandbox). Create or invite member accounts and move them into departments.
  2. Service control policies: Enable the SCP policy type and attach allow-lists per department, for example limiting production to approved regions and services.
  3. Identity Center: Connect the corporate IdP with SAML 2.0, sync users and groups with SCIM, and assign role configurations per account.
  4. Organization-wide audit: One CloudAudit tracking set for all members, delivering to a COS bucket in the log archive account.
  5. Tag policies: Define mandatory tags (env, team, cost-center, data-classification) and review non-compliant resources.
  6. Config: Record resource configuration, apply rules and compliance packs, and add remediation.
  7. Shared networking: A network account owns the CCN instance. Member VPCs attach across accounts and use route tables for isolation.
  8. Security baseline: Cloud Firewall, WAF, Anti-DDoS, and Cloud Security Center managed from the security account.
  9. Central log bucket: CloudAudit, CLB access logs, WAF logs, and VPC flow logs in a dedicated COS bucket with versioning, lifecycle policies, and object lock.

Compliance

Tencent Cloud states compliance with local information-security standards in the countries where it operates. The certification list is in Reference.

Government-grade workloads rely on:

  • Encryption: TLS in transit, KMS-backed encryption at rest for storage, databases, and logs.
  • RBAC: CAM roles restrict log access to authorized staff.
  • Tamper-proof storage: COS versioning + object lock prevent modification or deletion of audit trails.
  • CLS: Centralized log management for real-time analysis and compliance monitoring.
  • Start with TCO + Identity Center, even for small organizations. Early setup prevents painful account restructuring later.
  • Organization-wide CloudAudit tracking set delivering to a separate log archive account from day one.
  • Tag policies plus CAM conditions for tag enforcement.
  • Network hub: Centralize Internet egress and hybrid connectivity in a network account with CCN, NAT Gateway, and Direct Connect.
  • Quarterly compliance review: Use Config compliance results, CloudAudit history, and COS log analysis.

Real-World Example

A mid-size enterprise sets up a landing zone with 8 accounts under TCO using Control Center. The management account owns the organization, Identity Center, and billing. A log archive account holds the organization-wide CloudAudit tracking set and its COS bucket. A security account runs Cloud Firewall, WAF, and Config compliance packs. A network account holds the CCN instance and shared NAT gateways. Three production accounts and two development accounts sit in Production and Non-production departments. SCPs on Production limit resource creation to approved regions. All staff sign in through Identity Center federated to Microsoft Entra ID.

8. Security Model

Identity & Access

CAM is the per-account identity service. It supports sub-users, collaborators, roles, and fine-grained JSON policies with effect, action, resource, and condition elements. Tencent provides preset (system) policies and supports custom policies. A tag-scoped policy looks like this:

{
  "version": "2.0",
  "statement": [
    {
      "effect": "allow",
      "action": ["cvm:DescribeInstances", "cvm:StartInstances"],
      "resource": ["qcs::cvm:ap-guangzhou:uin/100000000001:instance/*"],
      "condition": {
        "for_any_value:string_equal": {
          "qcs:resource_tag/env": ["production"]
        }
      }
    }
  ]
}

Federation options:

  • Role SSO with SAML 2.0: Register a SAML IdP in CAM, then map IdP attributes to CAM roles. Users sign in with the corporate IdP (Okta, Entra ID, ADFS) and assume a role.
  • Role SSO with OIDC: Register an OIDC IdP in CAM so CI/CD pipelines and TKE pods assume roles without long-lived API keys. The Terraform provider supports this through assume_role_with_web_identity and enable_pod_oidc.
  • Identity Center: For multi-account estates, use TCO Identity Center instead of per-account SAML (see section 3).

Network Security

Security groups are stateful, instance-level firewalls. Rules are evaluated top-to-bottom and the first match wins. Practices:

  • One security group per application tier (web, app, db).
  • Rely on default deny. Allow only what each tier needs.
  • Reference security groups or parameter templates instead of hard-coding IP addresses.
  • Back up security group rules before changes.

Cloud Firewall has three inspection points:

Mode Scope Use Case
Internet firewall North-south traffic on EIPs, CLB, and NAT Gateways Block external threats, IPS, virtual patching
NAT firewall Outbound traffic from CVM through NAT Detect and block malicious outbound connections
Inter-VPC firewall East-west traffic between VPCs over CCN or Peering VPC isolation, micro-segmentation

WAF protects HTTP/HTTPS applications in SaaS (CNAME) mode or CLB-integrated mode, against OWASP Top 10 attacks, CC (HTTP flood) attacks, and bots.

Data Protection

KMS provides centralized key lifecycle management. Keys are held in FIPS 140-2 Level 3 validated HSMs and support envelope encryption: you generate data keys, encrypt data locally, and encrypt the data key with the customer master key (CMK). COS, CBS, CDB, TDSQL, and CLS integrate natively.

CDB and TDSQL support Transparent Data Encryption (TDE), which encrypts data files at rest with KMS-managed keys and no application change. Treat enabling it on CDB as permanent. The steps are in How-to Guides.

90-day native retention

CloudAudit event history only covers 90 days. China's Cybersecurity Law requires network logs to be kept for at least six months, and MLPS Level 3 assessments expect 180 days or more. Configure tracking sets that deliver to COS with versioning and lifecycle policies.

Compliance Context

China Cybersecurity Law (effective 2017-06-01) puts obligations on network operators and critical information infrastructure (CII) operators:

  • Data localization: Personal information and important data collected in mainland China by CII operators must be stored domestically. Cross-border transfer needs a security assessment by the Cyberspace Administration of China (CAC).
  • Network security obligations: At least six months of log retention, real-name user authentication, incident response plans.
  • CII operators: Further requirements, including security reviews and procurement of secure products.

MLPS 2.0 (GB/T 22239-2019) is China's mandatory security classification scheme. Tencent Cloud offers compliance assistance per level. The level-to-service mapping is in Reference.

Data residency: Tencent Cloud runs separate sites and accounts for mainland China and international regions. Data created in mainland regions stays in China by default. Cross-border transfer (for example DTS sync or COS replication to Singapore, or CCN cross-border links) falls under the Personal Information Protection Law (PIPL) and Data Security Law (DSL).

Cross-References

Sources