A Real World Journey Building on Tencent Cloud
When you first approach Tencent Cloud, it feels familiar if you come from AWS or Azure. There are VPCs, Kubernetes clusters, load balancers, object storage, IAM, everything you would expect. But once you actually start building and deploying a real system, the differences start to show up in very real ways.
This is a story of building a production ready setup on Tencent Cloud, running into ICP restrictions, redesigning architecture, and eventually stabilizing with a private Kubernetes cluster, bastion access, and a Hong Kong deployment.
It is also a breakdown of how Tencent Cloud actually works under the hood, and how it compares to AWS and Azure in practical DevOps workflows.
Understanding Tencent Cloud at a Core Level
Tencent Cloud follows a similar mental model to other cloud providers, but the naming and behavior have subtle differences.
At the foundation you have a VPC. Inside the VPC you define subnets which can be public or private. Compute resources like CVMs or Kubernetes nodes live inside these subnets. Networking is controlled through security groups and routing tables.
Kubernetes is offered through TKE which is Tencent Kubernetes Engine. It abstracts control plane management but still gives you flexibility over networking, node pools, and scaling.
Object storage is COS which behaves similarly to S3.
Load balancing is handled through CLB which supports both public and private exposure.
At a glance everything looks standard. The complexity begins when you try to expose services publicly inside mainland China.
The ICP Reality
One of the biggest turning points in this journey was understanding ICP.
If you deploy infrastructure in mainland China regions such as Shanghai or Beijing, you cannot simply expose a public website or API like you would on AWS. You need an ICP license issued by the Chinese government.
Without ICP approval, public endpoints may not work reliably, may be blocked, or may never become accessible.
This creates a very real constraint.
You can build everything correctly from a technical standpoint and still fail at the final step of making your service reachable.
That is exactly what happened.
Everything was deployed in Shanghai. Kubernetes cluster was up. Services were running. Ingress was configured. But external access became the bottleneck due to ICP restrictions.
The Shift to Hong Kong
The solution was not a code change. It was a region change.
Tencent Cloud’s Hong Kong region operates outside mainland China regulations. That means no ICP requirement.
Moving to Hong Kong immediately removed the compliance barrier and allowed public exposure of services without regulatory friction.
This shift also impacted latency and accessibility for global users in a positive way.
The architecture itself remained similar, but the operational experience improved drastically.
Architecture Overview
The final architecture evolved into a secure and production ready setup with strong isolation.
You have a private Kubernetes cluster running inside a VPC. The nodes are not directly exposed to the internet. Instead, access is controlled through a bastion host.
Ingress is handled through NGINX inside the cluster. External traffic flows through a load balancer into the ingress controller, and then to services.
TCP services such as device communication ports are also exposed through the ingress configuration rather than separate load balancers.
Here is a simplified flow of the architecture:
Private Cluster and Bastion Access
One of the key design decisions was keeping the Kubernetes cluster private.
This means nodes do not have public IPs. Direct SSH or API access from the internet is not allowed.
Instead, a bastion host is deployed in a public subnet.
You connect to the bastion, and from there access internal resources.
This adds a strong security boundary.
This approach is very similar to hardened AWS architectures, but in Tencent Cloud it feels more necessary because of networking defaults and access patterns.
Kubernetes Exposure Strategy
Instead of creating multiple load balancers for each service, the setup uses a single ingress controller.
NGINX ingress handles both HTTP and TCP traffic.
This is especially useful when dealing with systems like GPS tracking devices or custom protocols where TCP ports need to be exposed.
Configuration is done through a ConfigMap that maps external ports to internal services.
This reduces cost and complexity since Tencent CLB instances are not as flexible or cheap as AWS alternatives in some cases.
Storage and Data Flow
Object storage using COS works very similarly to S3.
You can upload files, serve static assets, and integrate with applications easily.
A simple flow looks like this:
The APIs are slightly different, but the mental model remains the same.
CI CD and Deployment
Your pipeline builds Docker images, pushes them to a registry, and deploys them to Kubernetes.
Tencent Cloud can integrate with CI systems, but often external tools like GitHub Actions or self managed pipelines provide more flexibility.
The deployment flow looks like this:
This part feels very similar to AWS and Azure workflows.
Key Differences from AWS and Azure
Tencent Cloud is powerful, but the experience differs in important ways.
Documentation is not as consistent or detailed as AWS. You often need to experiment or translate concepts mentally.
Naming conventions are different which creates a small learning curve.
Networking behavior can feel stricter or less intuitive, especially with private clusters and routing.
The ICP requirement is something you never deal with in AWS or Azure global regions.
The console UI is functional but less polished compared to AWS.
On the positive side, Tencent Cloud integrates well with the Chinese ecosystem and provides strong performance in Asia.
Lessons I learned:
The biggest lesson is that infrastructure is not just about technology. It is also about geography and regulation.
Choosing the wrong region can block your entire system even if everything is technically correct.
Private clusters with bastion access provide strong security and should be the default for production setups.
Ingress based exposure is more efficient than multiple load balancers, especially when dealing with mixed traffic types.
Always design for flexibility. Being able to shift regions saved the entire setup.
Conclusion
Tencent Cloud is a capable platform, but it requires a different mindset compared to AWS and Azure.
Once you understand the constraints, especially around ICP and networking, you can build robust and scalable systems.
The journey from Shanghai to Hong Kong was not just a migration. It was a deeper understanding of how cloud infrastructure interacts with real world regulations and architecture decisions.
If you approach Tencent Cloud with the right expectations, it becomes a powerful tool rather than a frustrating one.
