Access CloudBase from an Office Network Through a VPC
Some organizations do not allow business traffic to reach CloudBase over the public network. Public access control plus IP allowlists rarely covers changing egress IPs, branch offices, and remote work; an internal proxy adds a hop and requires new certificates and domains.
This path is private end to end: office endpoints reach the enterprise VPC over a dedicated line or VPN, then hit CloudBase directly through the endpoint (PrivateLink). The enterprise only creates the endpoint; CloudBase enables one switch, and domain resolution is optional. Once connected, everything in the VPC shares it, with no code or domain changes.
VPC connection - cross-network access is a standard capability of the Platform Edition and requires the Platform Edition plan. Before use, contact us or submit a Tencent Cloud ticket to enable it and add your account to the endpoint service allowlist; without this, endpoints cannot be created or attached.
When to Use This Design
Applicable
- The office network or intranet is already connected to a Tencent Cloud VPC through a dedicated line or VPN.
- Internal office endpoints need direct access to sites, HTTP APIs, or admin systems hosted in a CloudBase environment.
- The environment's public entry points must be closed or limited to a very small number of sources.
- Multiple business systems access the same environment and should share one connection instead of individual proxies.
Not applicable
- No VPC, dedicated line, or VPN is available. This path requires an enterprise-side VPC.
- The goal is only to restrict inbound source IPs. Use public access control with an allowlist instead.
- The goal is for cloud functions or CloudBase Run to reach resources inside the enterprise VPC. That is the opposite direction and uses peering or Cloud Connect with a bound service.
Path and Components
Solid lines are business traffic; dashed lines are domain resolution. Once the domain resolves to the endpoint VIP, requests go straight to the VIP instead of a public entry point. Resolution is optional: use Private DNS, local hosts, or DNSPod.
| Component | Owner | Purpose |
|---|---|---|
| VPC connection - cross-network access | CloudBase console | Environment-level switch. When enabled, the platform adds the account to the endpoint service account allowlist so the enterprise can create and attach endpoints |
| Endpoint | Enterprise VPC | Entry point for reaching CloudBase from the enterprise VPC. An IPv4 address is assigned on creation; this is the VIP used for DNS |
| Endpoint service | CloudBase (service provider) | Provided by CloudBase; enterprises associate it through the service UIN and service ID |
| Domain resolution (optional) | Enterprise Private DNS / hosts / DNSPod | Resolves the environment domain to the endpoint VIP. Without it, access by hosts entry or VIP also works |
| Dedicated line or VPN | Enterprise | Connects the office network to the VPC; this path does not modify it |
Three design trade-offs:
- The channel is built at the VPC level: an endpoint is one-time infrastructure and is not configured per business system. New systems or office sites can reuse it as long as they are in the same VPC or a connected network segment.
- The domain stays the same: applications keep using the environment's domain (default or custom) and only point internal resolution to the VIP. No code changes or redeployment are needed, and rollback only requires deleting the DNS record.
- Entry points can be narrowed: after closing public access, the environment is reachable only through the internal path, making the access surface clear and auditable.
Prerequisites
| Side | Requirement |
|---|---|
| CloudBase environment | VPC connection - cross-network access is enabled. If disabled, new endpoints cannot be attached until it is re-enabled |
| CloudBase environment | The environment is in Shanghai. This endpoint service is currently available only in Shanghai |
| CloudBase environment | The environment has a domain for access. Either the default domain or any connected custom domain works |
| Enterprise | A VPC and subnet exist in the same region, with CIDR blocks that do not conflict with CloudBase |
| Enterprise | The office network is connected to the target VPC through a dedicated line or VPN |
| Enterprise | Permissions to create VPC endpoints; private domain management is also required for the Private DNS option |
Implementation Steps
Step 1: Create an Endpoint
Create an endpoint in the VPC console/Endpoints with these key parameters:
| Parameter | Value |
|---|---|
| Region | Shanghai, matching the environment region |
| Service type | Private service |
| Peer account type | Other account |
| Peer endpoint service UIN | 2252646423 |
| Peer endpoint service ID | vpcsvc-hwj3hf6o (Shanghai Zone 4) or vpcsvc-763h8db8 (Shanghai Zone 5), depending on the VPC's availability zone |
| Network and subnet | The enterprise's own VPC and subnet |
| IPv4 address | Automatically assigned |
Set peer account type to "Other account" and enter the service UIN and service ID above. Configure the remaining parameters according to the enterprise VPC.
CloudBase currently provides this endpoint service only in Shanghai; other regions are not supported yet. If the environment is not in Shanghai, this path cannot be established.
The enterprise account must be added to the endpoint service allowlist. Contact us to enable this permission.
After creation, the endpoint list shows the assigned IPv4 address. This VIP is used for DNS and must be recorded in the onboarding information.
Step 2: Configure Domain Resolution (Optional)
The endpoint only provides a VIP. To keep reaching the environment by domain, the domain must resolve to that VIP inside your network. This step is optional; pick one of the following:
| Method | When to use | Notes |
|---|---|---|
| Private DNS domain | Many endpoints in the VPC, long term | Create a private domain with an A record; it applies to the whole VPC, so new endpoints need no extra configuration |
| Local hosts | A few endpoints for validation or troubleshooting | Write VIP domain on the machine. Affects that machine only and needs no DNS setup |
| DNSPod | The domain is hosted on DNSPod | Point the A record value to the VIP; suits centralized DNS management |
The domain is not limited to a Platform Edition subdomain: both the environment's default domain and any connected custom domain work. When using the default domain, enter it as the private domain name, the hosts hostname, or the DNSPod host record.
Option 1: Private DNS
- Create a private domain in the Private DNS console. Use the domain your environment serves and associate the VPC that contains the endpoint from step 1.
- Add an A record to the private domain:
| Field | Value |
|---|---|
| Record type | A |
| Host | @, representing the domain itself |
| Value | The endpoint VIP from step 1 |
The associated VPC must match the one used in step 1; otherwise, private DNS resolution does not work. This is the most common cause of rework.
Option 2: Local hosts
Add one record on the machine; it takes effect locally only:
<endpoint VIP> <environment domain>
Option 3: DNSPod
In DNSPod, change the domain's A record value to the endpoint VIP. The record is reachable only from inside the network, so do not let public-facing services depend on it.
After configuration, the environment is reachable through this domain from the VPC and from networks connected through the dedicated line or VPN. Without resolution, you can also access it by VIP directly.
Verification and Cutover Order
Follow this order to minimize impact:
-
Keep public access and build the path first: once the endpoint is attached, resolve the domain from an internal machine and confirm it returns the endpoint VIP, not a public address.
-
Verify connectivity: run the following command internally, confirm the environment responds, then open a business page or call a business API.
curl -v https://<environment domain> -
Tighten VPC access control: if you have multiple VPCs, restrict sources to the intended business VPC in VPC access control.
-
Close public access: after the checks above pass, disable public access for the environment. All public entry points then stop working and only the internal path remains.
-
Regression and monitoring: observe the environment for one business cycle, checking branch office networks, remote work, and any legacy calls that still use public endpoints.
Step 4 disables all public entry points. Complete the endpoint setup and domain resolution first, and confirm the rollback plan before proceeding.
Billing
Costs land on both sides of the path:
| Item | Bearer | Notes |
|---|---|---|
| Endpoint | Enterprise | The endpoint is created on the enterprise side; VPC endpoint charges are billed to the enterprise account |
| Private domain resolution | Enterprise | With Private DNS, private domain and resolution charges are also borne by the enterprise; hosts or DNSPod follow their own rules |
| CloudBase gateway VPC traffic | CloudBase | Traffic over the VPC path is billed by outbound traffic at 0.1CNY/GB |
Traffic is counted in the response direction only; requests are not billed. Endpoint and resolution charges are not included in the CloudBase plan, so list them separately in the commercial proposal.
Combining the Three Access Controls
The three capabilities in CloudBase network configuration address different problems, and most organizations enable all of them:
| Capability | Scope | Role |
|---|---|---|
| Public access control | Public inbound access to the environment | Disabling it removes all public entry points, leaving only the internal path. This is the key compliance action |
| VPC access control | Sources connected through a VPC | Allowlists or denylists source VPC IDs to prevent other VPCs from using the path |
| VPC connection - cross-network access | Endpoint attachment eligibility | Environment-level switch that determines whether the enterprise can create attachable endpoints |
In short: cross-network access grants eligibility, VPC access control defines sources, and public access control closes the public exit.
Risks and Considerations
- Shanghai only: the endpoint service is currently available only in Shanghai, so environments in other regions cannot use this path; within Shanghai the endpoint must still be in the same region as the environment.
- Private domain associated with the wrong VPC: if the private domain's VPC differs from the endpoint's VPC, resolution fails with unclear errors. Verify each item during implementation.
- VIP changes: recreating an endpoint assigns a new address, so the A record must be updated. Add this to the enterprise's change management process.
- Single availability zone: each endpoint resides in one availability zone. For high availability, create one endpoint per zone and add multiple A records to the same private domain.
- Billing: endpoint and private domain resolution costs are borne by the enterprise, while CloudBase bills VPC outbound traffic. See Billing.
- Side effects of closing public access: before closing, confirm that no third-party systems, callback URLs, or monitoring probes still depend on the public domain.
- Outbound path is different: this path only covers enterprise intranet access to CloudBase. If CloudBase also needs to reach databases or internal services in the enterprise VPC, use a separate path (peering or Cloud Connect with a bound VPC).
Onboarding Information Checklist
Confirm the following information before implementation to reduce back-and-forth:
| Item | Content |
|---|---|
| Environment | Environment region and the domain in use (default or custom) |
| Network | VPC ID, subnet, availability zone, dedicated line or VPN peer and bandwidth |
| Permissions and accounts | Enterprise account UIN (to verify the endpoint service allowlist), owners for VPC and Private DNS operations |
| Redundancy | Whether multi-zone endpoints are required and whether multiple office sites must be covered |
| Cutover window | Time to close public access and the rollback plan |