Cross-Region VPC Internal Network Connectivity for CloudBase via CCN (Single-Account)

Use Cases

CloudBase Cloud Functions and CloudBase Run support VPC access: once bound to a VPC under your account, they can access resources inside that VPC (self-hosted databases, CVMs, etc.).

However, the VPC bound to CloudBase resources is self-built by you, and when the target business VPC is in a different region (e.g. the Cloud Function VPC in Shanghai, the business service in Beijing), the VPC alone cannot achieve cross-region internal connectivity. In that case, leverage Tencent Cloud Cloud Connect Network (CCN) to link the two VPCs into a single internal network.

This document describes the single-account scenario: all resources (Cloud Function VPC, Business VPC, CCN) are under the same Tencent Cloud account, requiring no cross-account approval — everything is done in your own console.

Solution Overview

Network Topology

Cloud Function / CloudBase Run (bound to Cloud Function VPC)
        ↓
       CCN (cross-region internal network)
        ↓
Business backend (Business VPC, in another region)

Core Components

Component	Description
Cloud Function VPC	A VPC you create under your own account; the one Cloud Function / CloudBase Run is bound to via "VPC access"
Business VPC	Another self-built VPC in a different region under your account, hosting databases, CVMs, etc.
Cloud Connect Network (CCN)	The core component for cross-region internal connectivity, linking the VPCs above into a single internal network

Architecture Diagram

        ┌─────────────────────────────────────────────────┐
        │              Your Tencent Cloud Account          │
        │                                                 │
        │  ┌──────────────────────┐                       │
        │  │  Cloud Function VPC  │                       │
        │  │  (Shanghai)          │                       │
        │  │  192.168.0.0/16      │                       │
        │  │  Cloud Function /    │                       │
        │  │  CloudBase Run       │                       │
        │  │  → Call business IP  │                       │
        │  └──────────┬───────────┘                       │
        │             │                                   │
        │  ┌──────────┴──────────────────────────────┐    │
        │  │  CCN (Cloud Connect Network)            │    │
        │  │  Route Table (2 entries):               │    │
        │  │   · 192.168.0.0/16 (Cloud Function VPC) │    │
        │  │   · 172.16.0.0/16  (Business VPC)       │    │
        │  └──────────────────────────┬──────────────┘    │
        │                             │                   │
        │                             ↓                   │
        │                 ┌──────────────────────┐        │
        │                 │  Business VPC        │        │
        │                 │  (Beijing)           │        │
        │                 │  172.16.0.0/16       │        │
        │                 │  ┌─────────────────┐ │        │
        │                 │  │ DB / Service    │ │        │
        │                 │  │ 172.16.1.100   │ │        │
        │                 │  │ Port: 3306/8080 │ │        │
        │                 │  └─────────────────┘ │        │
        │                 └──────────────────────┘        │
        └────────────────────────────────────────────────┘

Prerequisites

• CloudBase environment is provisioned
• You have created a VPC in the same region as your CloudBase resources (e.g. Shanghai) to serve as the Cloud Function VPC
• You have a self-built VPC and business services in the target region (e.g. Beijing) — the Business VPC
• Your account has VPC and CCN operation permissions

CIDR Planning (Critical)

⚠️ CIDR conflicts are the most common cause of integration failure. Confirm before starting.

Role	Region	CIDR (example)	Notes
Cloud Function VPC	Shanghai	192.168.0.0/16	Created by you; Cloud Function / CloudBase Run is bound to it
Business VPC	Beijing	172.16.0.0/16	Created by you; hosts business backends

The two VPC CIDRs must not overlap, otherwise CCN routing will conflict.

Integration Steps

The whole flow happens in a single account, in 3 steps, all in your own console:

Step 1: Create CCN  →  Step 2: Associate both VPCs with CCN  →  Step 3: Call from app
(1 minute)             (3 minutes)                              (5 minutes)

Step 1: Create a CCN Instance

1. Sign in to the CCN Console and click New
2. Configure:
   • Name: customize, e.g. cloudbase-ccn
   • Billing mode: monthly 95-percentile (recommended, flexible) or monthly prepaid
   • Service quality: Gold (recommended, low latency) or Silver
   • Bandwidth limit type: per region pair
3. Click OK and record the CCN instance ID (like ccn-xxxxxxxx)

💡 CCN provides free bandwidth below 10 Kbps by default, sufficient for connectivity testing (ping/telnet). For production, purchase bandwidth per route (e.g. Shanghai ↔ Beijing) — 50 Mbps starting is recommended; scale on demand.

Step 2: Associate Both VPCs with CCN

💡 Initiate the association from each VPC's detail page (not from the CCN detail page). Same-account associations take effect immediately without approval.

2.1 Associate the Cloud Function VPC with CCN

1. Open the VPC Console and switch to Shanghai. Find your Cloud Function VPC (e.g. 192.168.0.0/16) and open its detail page
2. Switch to the CCN tab → click Associate CCN
3. Configure:
   • Account type: My account
   • CCN ID: select the cloudbase-ccn created in Step 1
4. Click OK (takes effect immediately)

2.2 Associate the Business VPC with CCN

1. Switch the VPC Console region to Beijing, find the Business VPC (e.g. 172.16.0.0/16), and open its detail page
2. CCN tab → Associate CCN
3. Same configuration as above; select the same cloudbase-ccn
4. Click OK

2.3 Verify CCN Routes

Open the CCN Console → CCN instance detail → Route Table. Confirm the following routes exist with status Enabled:

Destination	Next hop	Status
192.168.0.0/16 (Cloud Function VPC)	Shanghai VPC	✅ Enabled
172.16.0.0/16 (Business VPC)	Beijing VPC	✅ Enabled

💡 Configure cross-region bandwidth at the same time: CCN detail page → Bandwidth Management → Change bandwidth, set the cap for the Shanghai ↔ Beijing route. The free quota (under 10 Kbps) is only for connectivity testing; purchase bandwidth as needed for production.

Step 3: Call from Your Application

3.1 Allow inbound traffic in the business VPC security group

In the security group of the target service (CVM/database/etc.) in the Business VPC, add inbound rules:

Source	Protocol	Port	Description
192.168.0.0/16 (Cloud Function VPC CIDR)	TCP	Business port (e.g. 8080)	Allow Cloud Function access
192.168.0.0/16	ICMP	All	Optional, for ping tests

3.2 Confirm the Cloud Function is bound to the Cloud Function VPC

Open the Cloud Function console → function detail → Network configuration → confirm that VPC access is enabled and the bound VPC is the one associated with CCN in Step 2.1.

If the Cloud Function does not have VPC access enabled yet, configure it here first.

3.3 Call the business service from your Cloud Function

Use the backend's internal IP directly in your Cloud Function:

// Example: Cloud Function calling a service in the Beijing VPC
const http = require('http')

exports.main = async (event, context) => {
  const options = {
    hostname: '172.16.1.100',  // Internal IP of the business service (direct via CCN)
    port: 8080,
    path: '/api/your-service',
    method: 'GET',
    timeout: 5000,
  }

  return new Promise((resolve, reject) => {
    const req = http.request(options, (res) => {
      let data = ''
      res.on('data', (chunk) => (data += chunk))
      res.on('end', () => {
        try {
          resolve({ statusCode: 200, body: JSON.parse(data) })
        } catch (e) {
          resolve({ statusCode: 200, body: data })
        }
      })
    })

    req.on('timeout', () => {
      req.destroy()
      reject(new Error('Request timeout - check VPC connectivity'))
    })
    req.on('error', (err) => {
      reject(new Error(`Connection failed: ${err.message} - check CCN/security group`))
    })
    req.end()
  })
}

3.4 Deploy and verify

Deploy the Cloud Function → trigger a test invocation → confirm the response is correct. Done.

Notes

CIDR Conflicts

• The most common failure cause. Confirm the two VPC CIDRs do not overlap before associating with CCN
• Recommended planning: use 192.168.0.0/16 for the Cloud Function VPC and 172.16.0.0/16 for the Business VPC; avoid 10.0.0.0/8

Bandwidth and Billing

• CCN provides free bandwidth below 10 Kbps by default, sufficient for connectivity testing only
• Production traffic is billed per region pair (e.g. Shanghai ↔ Beijing); in single-account scenarios, you bear the cost yourself
• Monitor bandwidth usage to avoid packet loss caused by traffic bursts

Security

• Keep the Business VPC security group scoped to the Cloud Function VPC CIDR and only the necessary ports
• For sensitive services like databases, layer IAM authentication and security group rules
• Open only the ports required by the business

Troubleshooting

When connectivity issues occur, follow this order:

CCN route table is complete (both routes enabled)
    ↓
Business VPC security group allows the Cloud Function VPC CIDR
    ↓
Cloud Function has VPC access enabled and is bound to the correct Cloud Function VPC
    ↓
Business backend is actually listening on the port (run curl localhost:<port> on the CVM)
    ↓
Cloud Function logs (timeout / connection refused / route unreachable)

Reverse Calls

This solution is one-directional (Cloud Function → Business VPC). If you need a CVM in the Business VPC to call back into a Cloud Function, two cases apply:

• CVM has internet egress (bound EIP, or routed through a NAT gateway): simply reach the Cloud Function's HTTP trigger over the public internet — no CCN required
• CVM has no internet egress (pure internal network): public access is not available. Deploy a NAT gateway / forward proxy in the Business VPC so that the CVM can reach the Cloud Function's HTTP trigger via that egress; or evaluate whether to redesign the architecture (for example, push the relevant capability down to the business side)

FAQ

Q1: Where do I view / create the Cloud Function VPC?

Open the VPC Console and create one. When you enable VPC access in the Cloud Function's Network configuration, you select a VPC from your account — pick the one you just created.

Q2: Can I connect to multiple business VPCs in different regions at the same time?

Yes. Repeat Step 2 to associate VPCs in different regions with the same CCN. CCN automatically maintains routes for all VPCs (just ensure no CIDR conflicts).

Q3: What if the business backend IP changes?

The hardcoded IP in the Cloud Function code needs to be updated. If backend IPs change frequently or you have multiple machines, deploy an internal CLB in the Business VPC as a unified entrypoint — your Cloud Function only calls the CLB VIP, and backend changes are transparent.

Q4: What about cross-account scenarios?

In cross-account scenarios, choose Other Account when associating the VPC with CCN and provide the peer UIN; the peer account approves the request from the CCN detail page. See the cross-account productized solution documentation for details.

Q5: Will associating the Cloud Function VPC with CCN affect existing in-VPC traffic?

No. Associating with CCN only adds cross-region access capability; existing intra-VPC traffic is unaffected.