Skip to content

Tencent Cloud -- Architecture Patterns

This note covers the major architecture patterns for complex project setups on Tencent Cloud: single-VPC, multi-VPC, multi-account, multi-AZ / multi-region, DR, DMZ, and Landing Zone / Governance. Each pattern includes the key services, recommended configurations, and real-world examples drawn from official Tencent Cloud documentation and established practice.

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 across Availability Zones, and attach route tables and gateways. For a single project, one VPC with multi-AZ subnets provides network isolation, high availability, and operational simplicity.

CIDR blocks cannot be modified after VPC or subnet creation

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

Internet --> WAF --> CLB (public subnet, AZ-a / AZ-b)
                        |
               +--------+--------+
               |                 |
         CVM App (private       CVM App (private
         subnet, AZ-a)          subnet, AZ-b)
               |                 |
         CDB MySQL (private subnet, AZ-a, replica in AZ-b)
               |
         NAT Gateway --> Internet (outbound SNAT)

Key Services

Service Role
VPC Isolated virtual network with custom CIDR; supports 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (mask 12-28)
Subnet Layer within a VPC bound to a single AZ; all Tencent Cloud resources must be deployed in a subnet
Route Table System route table (auto-created per VPC) + custom routes; 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; operates at the protocol and port level
CLB (Cloud Load Balancer) Layer 4/7 traffic distribution across CVM instances; supports TCP, UDP, HTTP, HTTPS
NAT Gateway Provides outbound Internet access (SNAT) and inbound port mapping (DNAT); up to 10M concurrent connections
EIP (Elastic IP) Public IP that can be bound to NAT Gateway, CLB, or individual CVM
  • CIDR planning: Use RFC 1918 ranges. Reserve headroom -- VPC CIDR cannot overlap with any VPC you plan to interconnect later via Peering or CCN. Use /16 for the VPC and /24 for subnets as a starting point. Each VPC can provide up to 65,533 private IP addresses.
  • Multi-AZ subnets: Create at least two subnets in different AZs. Place CLB, CVM, and CDB replicas across both. A single VPC can span all AZs in a 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 should have 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 prioritized top-to-bottom; the first matching rule 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 for internal networking.
  • Secondary CIDR: When the primary CIDR cannot support business growth, add a secondary CIDR block to 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) with subnets in AZ-2 and AZ-3. Public subnets host a CLB instance (HTTP/HTTPS listeners). Private subnets host CVM auto-scaling groups running application containers. A managed CDB for MySQL (two-node, semi-sync) instance runs with cross-AZ replica. NAT Gateway in the public subnet provides egress for pulling container images and calling third-party APIs. Security Groups restrict app-tier ingress to CLB health-check IPs only.

2. Multi-VPC Architecture

When workloads span multiple VPCs -- whether for environment isolation (dev/staging/prod), business-unit separation, or regulatory compliance -- Tencent Cloud offers three primary inter-VPC connectivity options.

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

Architecture Summary

CCN is Tencent Cloud's managed WAN service. It establishes full-mesh interconnection between VPCs and between VPCs and on-premises IDCs. CCN uses MPLS-VPN technology for tenant isolation and supports automatic route learning, so when network topology changes you do not need to manually configure routes.

Once VPCs or Direct Connect gateways connect to a CCN instance, any two network instances can communicate without additional links.

            +----------------------------------+
            |         CCN Instance              |
            |                                   |
  Region A  |   Region B         On-Prem IDC    |
  +-------+ |   +-------+       +-----------+   |
  | VPC-1 |-+---| VPC-2 |-------| DC GW     |   |
  +-------+ |   +-------+       +-----------+   |
      |      |       |                           |
  +-------+  |  +-------+                        |
  | VPC-3 |--+  | VPC-4 |                        |
  +-------+  |  +-------+                        |
            +----------------------------------+

Key Features

Capability Detail
Full-mesh Any-to-any connectivity; no need for individual peering connections
Automatic route learning Multi-level routing with autonomous learning; no manual route table updates
MPLS-VPN isolation Tenant networks isolated at the data plane; meets financial and government security requirements
Custom route tables Divide network zones within CCN for isolation between specific VPC groups
Cross-account VPCs from different Tencent Cloud accounts can join the same CCN instance
VPN Gateway for CCN Attach IPsec VPN tunnels to CCN, enabling encrypted access from multiple IDCs
Service levels Platinum, Gold, Silver -- with different bandwidth and latency SLAs
Free intra-region Same-region bandwidth up to 5 Gbps is free of charge (same or cross account)

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

Peering Connection provides direct, one-to-one VPC interconnection. Unlike CCN, connectivity is not transitive -- to fully interconnect N VPCs you need N*(N-1)/2 peering connections.

When to use Peering Connection vs CCN

Use Peering for simple two-VPC links. Use CCN when three or more VPCs need interconnection, or when VPCs span multiple regions or accounts.

2c. VPN Gateway -- Encrypted Tunnel

VPN Gateway creates IPsec VPN tunnels between a VPC and an on-premises IDC, between VPCs, or between a VPC and another cloud. Tencent Cloud also supports VPN Gateway for CCN, which attaches VPN tunnels directly to a CCN instance.

A common hybrid-cloud pattern uses Direct Connect (primary) with VPN (secondary) for disaster recovery. When the Direct Connect link fails, traffic automatically 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 via 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 route learning + custom route tables Manual route configuration Manual route configuration
Encryption MPLS-VPN isolation (not encrypted on wire) No encryption IPsec encryption
Bandwidth Up to 5 Gbps free intra-region; Platinum/Gold/Silver tiers for cross-region Configurable per connection Up to 1 Gbps per tunnel
Latency Optimized 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; migrate to CCN when growing Supplement to Direct Connect
  • Prefer CCN for any topology involving three or more VPCs.
  • CIDR discipline: Plan non-overlapping CIDRs across all VPCs. CCN can lower CIDR conflict detection to the subnet level, but non-overlapping VPC CIDRs is the safest approach.
  • Custom route tables in CCN: Use them to isolate network segments (e.g., production VPCs cannot route to development VPCs).
  • Hybrid DR: Use Direct Connect as the primary link and VPN Gateway as the secondary. When the DC link is healthy, all traffic flows over DC; when it fails, traffic fails over to VPN automatically.

Real-World Example

A financial services company operates in three regions (Shanghai, Guangzhou, Singapore) with separate VPCs per region and per environment (prod/staging). Six VPCs join a single Gold-tier CCN instance. Custom route tables isolate production from staging. A Direct Connect circuit from the Shanghai IDC connects via DC Gateway to CCN, with a VPN Gateway for CCN as a warm standby. Cross-region bandwidth is billed at CCN monthly 95th-percentile rates.

3. Multi-Account / Multi-Project Governance

Architecture Summary

Tencent Cloud provides two complementary services for multi-account governance:

  • Tencent Cloud Organization (TCO) -- centralized management of multiple Tencent Cloud accounts under a single organization, with Organizational Units (OUs), Service Control Policies (SCPs), and consolidated billing.
  • Cloud Access Management (CAM) -- identity and permission management within a single account, including sub-accounts, roles, policies, federated identity (SAML/OIDC SSO), and MFA.
+------------------------------------------------------+
|              Tencent Cloud Organization               |
|                                                       |
|  +------------+  +------------+  +------------+       |
|  | OU: Core   |  | OU: Prod   |  | OU: Dev    |       |
|  |            |  |            |  |            |       |
|  | - Shared   |  | - BizUnit1 |  | - Sandbox  |       |
|  |   Services |  | - BizUnit2 |  | - Staging  |       |
|  | - Security |  | - BizUnit3 |  |            |       |
|  +------------+  +------------+  +------------+       |
|                                                       |
|  Service Control Policies (SCPs) applied per OU       |
|  Consolidated billing across all member accounts      |
+------------------------------------------------------+

Key Services

Service Role
Tencent Cloud Organization (TCO) Multi-account organizational hierarchy with OUs, SCPs, consolidated billing, and account lifecycle management
CAM (Cloud Access Management) IAM service: sub-users, collaborators, roles, policies, temporary credentials, federated SSO, MFA
Service Control Policies (SCP) Guardrails applied at the OU/account level; restrict which services/actions member accounts can use
Resource Tags Key-value metadata on resources for cost allocation, ownership tracking, and policy enforcement
CloudAudit API-level audit logging for all account activity; 90-day retention; export to COS via tracking sets

CAM Identity Types

Identity Description
Root account Full access to all resources; creates sub-accounts
Sub-user Fully owned by the root account; receives console login and API keys
Collaborator An existing Tencent Cloud root account invited as a collaborator; maintains dual identity
Message recipient Receives notifications but has no console/API access
Role Virtual identity with temporary credentials; can be assumed by any Tencent Cloud account; used for cross-account access and service-linked permissions

Service Control Policies (SCPs)

SCPs are the enforcement mechanism in TCO. If an OU only permits CVM-related actions via SCP, then member accounts in that OU can only grant CVM permissions to their sub-accounts through CAM -- regardless of what CAM policies exist.

SCP + CAM interaction

Effective permissions = intersection of SCP permissions AND CAM permissions. SCPs set the maximum boundary; CAM sets the actual grant within that boundary.

  • Account-per-environment: Separate accounts for production, staging, development, and shared services (logging, security, networking).
  • OU hierarchy: Group accounts by lifecycle stage (Core / Prod / Non-Prod) and apply SCPs per OU.
  • Federated SSO: Connect your corporate IdP (Active Directory, Okta) to CAM via SAML 2.0 or OIDC. Avoid creating individual sub-users for every employee.
  • Least-privilege policies: Use CAM policy conditions (IP range, MFA required, time-of-day) to tighten access.
  • Consolidated billing: Use TCO billing mode to view all member account costs from the management account.
  • Resource tags: Enforce mandatory tags (env, team, cost-center) across all member accounts. Use tags for cost allocation in billing reports.

Real-World Example

A conglomerate with three subsidiaries manages 12 Tencent Cloud accounts under one TCO Organization. The Core OU holds the shared-services account (VPC hub via CCN, CloudAudit aggregation, COS log bucket) and the security account (Cloud Firewall, WAF). The Prod OU holds six production accounts (two per subsidiary), each with SCPs restricting resource creation to approved regions only (Shanghai, Guangzhou). The Dev OU holds three sandbox accounts with relaxed SCPs but hard budget limits via billing alerts. All accounts federate to a corporate Okta instance for SSO.

4. Multi-AZ / Multi-Region

Architecture Summary

Tencent Cloud operates 64 availability zones across 22 regions globally. Mainland China regions include Guangzhou, Shenzhen, Shanghai, Nanjing, Beijing, Chengdu, Chongqing, and Qingyuan. International regions include Hong Kong, Singapore, Seoul, Tokyo, Bangkok, Silicon Valley, Virginia, Frankfurt, Sao Paulo, Jakarta, and (newly opened in 2025) Saudi Arabia.

Multi-AZ deployment keeps resources in multiple data centers within the same region for intra-region HA. Multi-region deployment replicates infrastructure across geographies for DR, latency reduction, and data-residency compliance.

Key Services for Multi-AZ / Multi-Region

Service Multi-AZ / Multi-Region Role
CLB (Cloud Load Balancer) Deploys master/slave clusters across AZs in the same region; automatic AZ failover; supports 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 with decoupled compute/storage
TDSQL for MySQL Distributed database with intra-city active-active, 1-region-2-DC, 2-region-3-DC architectures; strong synchronous replication
TDSQL-C (CynosDB) Cloud-native MySQL/PostgreSQL with serverless compute and multi-AZ storage; compatible with MySQL 8.0
TencentDB for Redis Multi-AZ deployment for master and replica nodes; supports up to 6 AZs; read/write separation routes reads to local-AZ replica
COS (Cloud Object Storage) Multi-AZ (MAZ) storage within a region; cross-region replication between buckets for DR
GAAP (Global Application Acceleration Platform) 50+ global nodes; accelerates TCP/UDP/HTTP/HTTPS between user and origin; up to 10 Gbps per connection; IPv6 and HTTP/3 support
DNSPod DNS resolution service; supports geo-based and latency-based routing; used with CLB for global load balancing
CCN Cross-region VPC interconnection over private backbone; enables cross-region CLB binding

CLB Cross-AZ and Cross-Region

CLB provides two levels of geographic distribution:

  1. Cross-AZ (default): CLB deploys high-performance clusters across AZs within a region. If an AZ becomes unreachable, traffic automatically routes to the surviving AZ. Bind CLB to CVM instances in multiple AZs for real-server-level HA.

  2. Cross-Region Binding 2.0: Uses CCN to bind CLB to CVM instances in a different region or VPC. The fee is charged on the CCN instance, not the CLB. Prerequisites: bill-by-IP account, CCN instance created, target VPC associated with CCN.

Global Load Balancing combines CLB instances per region with DNSPod geo-routing to distribute traffic globally.

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 (e.g., Beijing Zone 5 + Zone 7) 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 optimizes InnoDB, replication performance, and provides enterprise features (TDE, audit, read/write separation). CDB supports 99.9996% data reliability and 99.95% service availability.

Cross-region DR: CDB supports creating disaster recovery instances in a remote region. DTS (Data Transmission Service) replicates data continuously over Tencent's private network. The DR instance can be promoted to a source instance in seconds.

GAAP (Global Application Acceleration Platform)

GAAP is purpose-built for reducing cross-border and cross-region latency. It creates high-speed tunnel connections between the user's region and the origin server region, bypassing congested public Internet paths.

Feature Detail
Nodes 50+ globally distributed acceleration nodes
Bandwidth Up to 10 Gbps per connection
Concurrency Up to 1 million concurrent requests per connection
Protocols TCP, UDP, HTTP, HTTPS, IPv6, HTTP/3
Security End-to-end encryption, two-way client auth, IP blocklist/allowlist, Anti-DDoS Basic integration
Monitoring Per-connection, per-listener, per-domain, per-origin statistics; alarms for bandwidth, concurrency, latency, packet loss
  • Multi-AZ by default: Deploy CVM, CDB, and Redis across at least two AZs. Use CLB to distribute traffic across both.
  • Three-node CDB for financial or mission-critical workloads with strong sync replication and replicas in separate AZs.
  • COS MAZ storage class for intra-region object durability. Add cross-region replication for DR.
  • GAAP for any user base that accesses the application from a different continent. Configure GAAP connections per acceleration region and monitor latency/packet-loss metrics.
  • DNSPod + CLB for global load balancing: resolve the same domain to different CLB VIPs per region using geo-routing policies.

Real-World Example

A global gaming company deploys its matchmaking service across Shanghai, Frankfurt, and Virginia. Each region has a VPC with multi-AZ subnets and a CLB. CDB three-node (strong sync) handles game state in Shanghai; DR replicas in Frankfurt via DTS. GAAP acceleration connections tunnel player traffic from South America to the Virginia origin and from Southeast Asia to the Shanghai origin. DNSPod resolves api.game.com to the nearest regional CLB VIP based on the player's geography.

5. Disaster Recovery (DR) Patterns

Architecture Summary

Tencent Cloud supports a spectrum of DR strategies from cold backup to active-active. The primary enabler is DTS (Data Transmission Service) for database-level DR, combined with COS cross-region replication for object storage and TDSQL / CDB features for database HA.

Key DR Services

Service DR Role
DTS (Data Transmission Service) Database migration, real-time synchronization, and binlog-based subscription; supports cloud-local active-active, multi-site active-active, and cross-border sync
CDB Disaster Recovery Instance Read-only replica in a remote region; syncs via DTS over private network; promotable to source in seconds
TDSQL for MySQL Intra-city active-active in financial AZs; 1-region-2-DC and 2-region-3-DC architectures with strong sync (MAR technology)
TDSQL-C (CynosDB) Cloud-native MySQL with multi-AZ storage replication; automatic failover within seconds
COS Cross-Region Replication Incremental object sync between buckets in different regions; supports versioning; master/slave failover with SCF automation
SCF (Serverless Cloud Function) Automates DR switchover logic (health checks, DNS updates, failover triggers)
EventBridge Event-driven orchestration for DR workflows; triggers SCF functions on failure events
DNSPod DNS failover routing; switches traffic 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 (stopped/minimal); COS replication; scale up 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 bi-directional sync; dual CLB with DNSPod weighted routing

COS Cross-Region Replication DR

COS cross-region replication is the primary mechanism for object storage DR. It syncs incremental data between a source bucket and a destination bucket in a different region.

Architecture:

                   +-- cross-region replication -->
  [Bucket A]       |                            [Bucket B]
  (Shanghai)  <----+---- replication (reverse)   (Singapore)
       |                                              |
  [CDN Layer]                                    [CDN Layer]
       |                                              |
  +----+----+                                    +----+----+
  | App     |  <-- SCF health check + failover   | App     |
  | Primary |     DNSPod switches DNS            | DR      |
  +---------+                                    +---------+

Key characteristics:

  • Requires versioning enabled on both buckets.
  • Incremental replication; files replicate in seconds to minutes depending on size and distance.
  • Master/slave failover: when Bucket A links fail, SCF detects the failure and switches client traffic to Bucket B. Reverse replication keeps Bucket A in sync once it recovers.
  • Cost optimization: replicate only hot data (recent uploads) to reduce storage costs in the DR bucket.
  • COS Multi-AZ (MAZ) storage class provides intra-region redundancy across IDCs. Combine MAZ with cross-region replication for both local and geographic durability.

DTS Capabilities

DTS is the workhorse for database DR:

  • Data Migration: One-time full + incremental migration with minimal downtime. Supports migration to Tencent Cloud, between TencentDB instances, and from third-party cloud databases.
  • Data Synchronization: Continuous real-time sync between two database instances. Supports bi-directional sync for active-active patterns.
  • Data Subscription: Streams binlog changes to downstream consumers (data warehouses, event pipelines).

DTS leverages Tencent's private network for DR sync, reducing latency and minimizing data loss risk compared to public-network replication. Each DTS node has second-level failure recovery and self-healing capabilities.

TDSQL Multi-DC Architectures

Architecture Description Failover Data Consistency
1-Region-2-DC Master and slave nodes in two data centers within the same city Automatic; minutes Strong sync (MAR)
2-Region-3-DC Three data centers across two regions Automatic; minutes Strong sync (MAR); zero data loss
Intra-city Active-Active Both DCs serve read/write traffic via the same virtual IP Automatic; transparent to application Strong sync; same VIP, same port

TDSQL achieves strong sync through Multi-thread Asynchronous Replication (MAR), a Tencent kernel optimization that brings strong-sync performance close to asynchronous replication levels. This addresses the traditional performance penalty of synchronous replication.

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

Real-World Example

Airstar Bank (a Tencent-backed virtual bank in Hong Kong) runs a multi-layer DR architecture on Tencent Cloud. The system achieves cross-AZ dual-active disaster recovery with second-level rapid switching on extreme failures. DTS provides continuous database synchronization between the primary and DR regions. Tencent Cloud's observability platform monitors all business nodes in real time, triggering automated failover workflows when anomalies are detected.

6. DMZ / Perimeter Security Patterns

Architecture Summary

Tencent Cloud implements defense-in-depth through layered security services rather than a traditional physical DMZ. The recommended deployment chain is:

Client --> Anti-DDoS --> CDN (EdgeOne) --> WAF --> CLB --> CVM (real server)

Each layer strips a category of threat before traffic reaches the application. Subnet tiering within the VPC provides network-level isolation between public, application, and data tiers.

Key Security Services

Service Role
Anti-DDoS Basic Free 2 Gbps (up to 10 Gbps) DDoS protection; auto-enabled for all Tencent Cloud resources; SYN/UDP/ACK/ICMP/CC flood defense
Anti-DDoS Pro Paid; binds to Tencent Cloud IPs (CVM, CLB, NAT); 30-line BGP; base + elastic bandwidth; no IP change required
Anti-DDoS Advanced Paid; for any Internet business (in or outside Tencent Cloud); hides real server IP; Tbps-level capacity; 900+ Gbps per China node; global cleaning centers
Tencent EdgeOne Integrated CDN + DDoS + WAF + bot protection; 25+ Tbps DDoS reserve; 3-second attack response; Anycast
WAF (Web Application Firewall) OWASP Top 10 defense; SQL injection, XSS, CSRF, web shell detection; VIP addresses include 2 Gbps Anti-DDoS Basic
Cloud Firewall (CFW) Network-layer firewall with IPS, virtual patching, domain-based ACLs; NAT firewall for outbound control; VPC boundary firewall for inter-VPC isolation
Security Group Instance-level stateful firewall
Network ACL Subnet-level stateless packet filter

Anti-DDoS Protection Tiers

Tier Protection Scope Pricing Key Feature
Anti-DDoS Basic 2-10 Gbps Auto-enabled on all Tencent Cloud resources Free Basic volumetric defense
Anti-DDoS Pro Configurable base + elastic Tencent Cloud resources only (CVM, CLB, NAT) Base monthly + elastic daily No IP change; 30-line BGP
Anti-DDoS Advanced Tbps-level Any Internet business (Tencent Cloud or external) Base monthly + elastic daily + app bandwidth Hides real IP; global cleaning centers

Cloud Firewall (CFW) Editions

Edition Capabilities
Premium ACL control, IPS intrusion blocking, virtual patch, malicious code detection, NAT firewall with integrated NAT
Enterprise All Premium features + inter-VPC firewall for VPC boundary isolation
Ultimate All Enterprise features + advanced threat tracing, 6-month log retention

CFW replaces traditional DMZ management

Cloud Firewall can implement DMZ-style management for VPC networks, focusing protection on core assets and achieving fine-grained isolation between VPC segments -- similar to traditional network DMZ zones but using cloud-native controls.

Subnet Tiering Pattern

+----------------------------------------------------------+
|  VPC (10.0.0.0/16)                                       |
|                                                          |
|  +------------------+  Public Tier (10.0.1.0/24)         |
|  | CLB, NAT Gateway |  <-- Internet-facing               |
|  +------------------+  <-- Anti-DDoS + WAF protect this  |
|          |                                                |
|  +------------------+  Application Tier (10.0.10.0/24)   |
|  | CVM App Servers  |  <-- CFW VPC firewall isolates     |
|  +------------------+  <-- SG: allow from CLB only       |
|          |                                                |
|  +------------------+  Data Tier (10.0.20.0/24)          |
|  | CDB, Redis, ES   |  <-- SG: allow from App tier only |
|  +------------------+  <-- No Internet access             |
|                                                          |
+----------------------------------------------------------+
  1. Anti-DDoS Pro/Advanced absorbs volumetric attacks at the network edge.
  2. EdgeOne / CDN caches static content and provides additional L7 DDoS protection.
  3. WAF inspects HTTP/HTTPS traffic for application-layer attacks (SQL injection, XSS, bot traffic).
  4. CLB distributes clean traffic to CVM instances in private subnets.
  5. Cloud Firewall (NAT firewall) controls outbound connections from CVM, detecting and blocking malicious outbound traffic (C2 callbacks, data exfiltration).
  6. Cloud Firewall (VPC firewall) isolates east-west traffic between VPCs or between subnet tiers.
  7. Security Groups on each instance provide the final layer of least-privilege access control.
  • Always enable Anti-DDoS Basic (it is auto-enabled, but verify the protection threshold).
  • Bind Anti-DDoS Pro to WAF VIP addresses for combined L3/L4 + L7 protection.
  • Use CFW Enterprise edition for multi-VPC environments to inspect east-west traffic at VPC boundaries.
  • NAT firewall for outbound traffic control: identify CVM instances making suspicious outbound connections.
  • Network ACLs on the data-tier subnet: whitelist only application-tier subnet CIDRs on database ports.
  • No direct Internet access for data-tier or application-tier subnets. Route all 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. Cloud Firewall Enterprise edition monitors east-west traffic between the order-processing VPC and the payment VPC. NAT firewall inspects all outbound connections, blocking known malicious domains. CDB for MySQL sits in a data subnet with Network ACLs that only allow TCP 3306 from the application subnet CIDR.

7. Landing Zone / Governance

Architecture Summary

Tencent Cloud does not have a single packaged "Landing Zone" product equivalent to AWS Control Tower or Azure Landing Zones. Instead, governance is assembled from individual services:

AWS Equivalent Tencent Cloud Service
AWS Organizations Tencent Cloud Organization (TCO)
AWS Service Control Policies TCO Service Control Policies (SCPs)
AWS IAM Cloud Access Management (CAM)
AWS CloudTrail CloudAudit
AWS Config No direct equivalent; partial coverage via Cloud Security Center
AWS Control Tower No direct equivalent; assemble from TCO + CAM + CloudAudit + tags
Resource Groups / Tags Resource tags (key-value pairs on resources)

CloudAudit

CloudAudit is Tencent Cloud's API-level audit logging service:

Feature Detail
Coverage Logs all API operations across Tencent Cloud Console, CLI, SDK
Retention 90 days in CloudAudit console (event history)
Persistent storage Tracking sets export to COS buckets for long-term retention
Query fields Access key, region, error code, event ID, event name, event source, event time, request ID, source IP, username
Cost Free (you only pay for COS storage if using tracking sets)
Use case Compliance audits, security investigations, resource change tracking, troubleshooting

Governance Building Blocks

A Tencent Cloud Landing Zone can be assembled as follows:

  1. TCO Organization: Create the organization from a management account. Define OUs (Core, Production, Non-Production, Sandbox). Invite or create member accounts and assign to OUs.

  2. Service Control Policies: Apply SCPs per OU to restrict allowed services, regions, and actions. For example, restrict production OU to Shanghai and Guangzhou regions only.

  3. CAM Federated SSO: Configure SAML 2.0 or OIDC identity providers in each member account (or use cross-account role assumption from a central identity account).

  4. CloudAudit Aggregation: In each member account, create a tracking set that exports audit logs to a centralized COS bucket in the security account. This provides a single pane for compliance review.

  5. Resource Tags: Define mandatory tags (env, team, cost-center, data-classification) and enforce them through CAM policy conditions or post-deployment compliance checks.

  6. Shared Networking: Create a network hub account with a CCN instance. Member account VPCs join the CCN. Use custom route tables for isolation.

  7. Security Baseline: Deploy Cloud Firewall, WAF, and Anti-DDoS in the security account. Route all Internet-facing traffic through the security account's CLB and WAF.

  8. COS Log Bucket: Centralize all logs (CloudAudit, CLB access logs, WAF logs, COS access logs) in a dedicated COS bucket with versioning, lifecycle policies, and cross-region replication.

Compliance

Tencent Cloud complies with local information security standards in countries and regions where it provides cloud services. Available compliance certifications include ISO 27001, SOC 1/2/3, PCI-DSS, GDPR readiness, CSA STAR, and region-specific certifications (China MLPS, Singapore MTCS).

Government-grade workloads benefit from:

  • Encryption: TLS in transit, AES at rest for logs and audit data.
  • RBAC: CAM role-based access to restrict log access to authorized personnel.
  • Tamper-proof storage: COS versioning + object lock prevents unauthorized modification or deletion of audit trails.
  • CLS (Cloud Log Service): Centralized log management for real-time analysis and compliance monitoring.
  • Start with TCO + CAM SSO: Even for small organizations, setting up TCO early avoids painful account restructuring later.
  • Mandatory CloudAudit tracking sets: Export to COS in a separate security account from day one.
  • Tag enforcement: Use CAM policies that deny resource creation when mandatory tags are missing.
  • Network hub: Centralize Internet egress and ingress through a shared-services account with CLB, NAT Gateway, WAF, and Cloud Firewall.
  • Quarterly compliance review: Use CloudAudit event history and COS log analysis to generate compliance reports.

Real-World Example

A mid-size enterprise establishes a Tencent Cloud landing zone with 8 accounts under TCO. The management account owns the organization and billing. A security account hosts CloudAudit tracking-set COS buckets, Cloud Firewall, and WAF. A network account holds the CCN instance and shared NAT Gateways. Three production accounts and two development accounts are organized into Prod and Dev OUs. SCPs on the Prod OU restrict instance creation to approved regions and require MFA for destructive API calls. All accounts federate to Azure AD via SAML 2.0. Resource tags are enforced through CAM deny policies.

8. Service Naming Quick Reference

This table maps common cloud concepts to their Tencent Cloud product names and abbreviations.

Compute

Concept Tencent Cloud Service Abbreviation
Virtual Machine Cloud Virtual Machine CVM
Serverless Function Serverless Cloud Function SCF
Container Orchestration Tencent Kubernetes Engine TKE
Container Registry Tencent Container Registry TCR
Bare Metal Cloud Physical Machine CPM
Auto Scaling Auto Scaling AS

Networking

Concept Tencent Cloud Service Abbreviation
Virtual Network Virtual Private Cloud VPC
Subnet Subnet --
Load Balancer (L4/L7) Cloud Load Balancer CLB
NAT Gateway NAT Gateway NAT
Elastic IP Elastic IP EIP
DNS DNSPod --
CDN Content Delivery Network / EdgeOne CDN
WAN / Transit Network Cloud Connect Network CCN
VPC Peering Peering Connection --
VPN VPN Connections (VPN Gateway) VPN
Dedicated Circuit Direct Connect DC
Global Acceleration Global Application Acceleration Platform GAAP

Database

Concept Tencent Cloud Service Abbreviation
Managed MySQL TencentDB for MySQL CDB
Managed PostgreSQL TencentDB for PostgreSQL --
Managed Redis TencentDB for Redis --
Managed MongoDB TencentDB for MongoDB --
Managed SQL Server TencentDB for SQL Server --
Cloud-native MySQL/PG TDSQL-C for MySQL / PostgreSQL CynosDB
Distributed MySQL TDSQL for MySQL DCDB
Managed MariaDB TencentDB for MariaDB TDSQL (legacy naming)
NoSQL (wide column) TcaplusDB --
Managed Kafka Cloud Kafka CKafka
DB Migration/Sync Data Transmission Service DTS

Storage

Concept Tencent Cloud Service Abbreviation
Object Storage Cloud Object Storage COS
Block Storage Cloud Block Storage CBS
File Storage (NFS) Cloud File Storage CFS
Archive Storage COS Archive / Deep Archive --

Security & Identity

Concept Tencent Cloud Service Abbreviation
IAM Cloud Access Management CAM
Organization / Multi-Account Tencent Cloud Organization TCO
Network Firewall Cloud Firewall CFW
Web App Firewall Web Application Firewall WAF
DDoS Protection (free) Anti-DDoS Basic --
DDoS Protection (Tencent IPs) Anti-DDoS Pro --
DDoS Protection (any IP) Anti-DDoS Advanced --
Integrated Edge Security Tencent EdgeOne --
Data Security Data Security Governance Center DSGC
Key Management Key Management Service KMS
SSL Certificate SSL Certificate Service --

Monitoring & Logging

Concept Tencent Cloud Service Abbreviation
Cloud Monitoring Cloud Monitor CM
Log Management Cloud Log Service CLS
API Audit Logging CloudAudit --
Event Bus EventBridge EB
APM Application Performance Management APM

AI / ML

Concept Tencent Cloud Service Abbreviation
Machine Learning Platform Tencent Cloud TI Platform TI
NLP / Speech / Vision Tencent Cloud AI --

Cross-References