Huawei Cloud Account Marketplace Huawei Cloud ECS VPC network planning

Huawei Cloud / 2026-05-15 14:13:45

Introduction: The VPC Planning Party (Where Nobody Wants Surprise Guests)

Network planning for Huawei Cloud Elastic Cloud Server (ECS) can feel like assembling furniture with missing instructions, a suspicious amount of small screws, and a guarantee that “it will make sense once it’s built.” The good news: with a sensible plan, VPC network design becomes far more predictable. The not-so-good news: if you wing it, your servers will eventually start communicating like awkward relatives at a reunion—technically possible, socially confusing, and definitely not what you intended.

This article walks you through Huawei Cloud ECS VPC network planning with a clear, structured approach. We’ll talk about what a VPC is, why planning subnets and routing matters, how to design connectivity for typical workloads, and how to avoid common pitfalls. Along the way, you’ll get practical guidance that helps you build a network that’s secure, scalable, and easier to operate when your environment grows from “a few servers” to “why is everything in prod now?”

What “VPC Network Planning” Actually Means

VPC stands for Virtual Private Cloud. Think of it as your own private network space inside Huawei Cloud. Within a VPC, you create subnets, define routes, choose how traffic flows (directly or through gateways), and control access using security mechanisms like security groups and network ACLs (depending on your design).

When people say “network planning,” they often mean four things:

Address planning: choosing IP ranges that won’t clash later.
Segmentation: deciding which resources live together and which must be isolated.
Connectivity: determining how traffic enters, exits, and moves between components.
Security and operations: setting rules that are secure now and maintainable later.

For ECS specifically, your servers need network identity (private IPs in a subnet), connectivity rules (routes, gateways), and access controls (security groups). Without planning, you can still deploy ECS instances—but you might pay later in troubleshooting time, complexity, and fear.

Start With Workload Requirements (Before You Touch an IP Range)

The fastest way to build a “bad but working” VPC is to begin with IP addresses and only then ask, “Wait, what are we actually running?” Let’s reverse that. Before designing subnets, answer these questions:

What are your workload types? Web apps, databases, batch jobs, internal services, analytics, message queues?
Do you need internet exposure? If yes, which components should be publicly reachable?
Do you need internal-only access? Many systems should not be exposed directly to the internet.
Is there a need for cross-VPC or on-premises connectivity? If yes, you’ll care about routing and address overlap avoidance.
How many environments exist? Development, testing, staging, production—ideally separated.
What’s the expected growth? Subnets are like pants: if you buy them too tight, you’ll regret it. If you buy them too loose, you’ll wear them while everything slides around.

Write these requirements down. Then your network design stops being a creative writing project and starts being an engineering plan.

Design Principles That Save You From Your Future Self

There are several guiding principles that make VPC planning smoother. You don’t need to memorize them like a spellbook, but you should keep them in mind.

Principle 1: Segment by Function, Not by Mood

Try grouping resources by role: public-facing services in one segment, application servers in another, databases in a restricted segment, and so on. “Mood-based segmentation” is when you place resources wherever you have free IPs and hope nobody notices. Nobody wants that.

Principle 2: Plan for Growth With Address Headroom

Don’t create a subnet so small that your “just one more server” turns into a minor crisis. Plan for expected scale plus a buffer. Also consider future additions like new microservices, scaling groups, or temporary test environments.

Principle 3: Prefer Private Communication Internally

In many architectures, public endpoints are only for edge components. Internal services should communicate over private networks, with strict access controls. This reduces exposure and keeps troubleshooting localized.

Principle 4: Centralize Ingress/Balance Egress

If all servers can talk to the internet freely, you will eventually have a “why is this downloading updates from the wrong place?” moment. Instead, funnel internet access through controlled components like NAT and load balancers (where applicable), and enforce rules consistently.

Choosing IP Ranges: The Boring Part That Prevents Catastrophes

Address planning is less glamorous than flashy dashboards, but it’s where network sanity is born.

Decide on private IP ranges for your subnets. In VPC planning, you’ll typically choose CIDR blocks that don’t overlap with other networks you might connect to later (for example, corporate networks, other VPCs, or peered networks).

Step-by-Step IP Planning Approach

List your likely connected networks: on-premises networks, other VPCs, shared services, etc.
Choose non-overlapping private ranges: avoid common corporate ranges (like 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) if you know they’ll collide. If you don’t know, you should find out.
Allocate CIDR blocks per subnet: for example, smaller CIDRs for public subnets and larger ones for application subnets.
Leave room for scaling: you can allocate additional subnets later, but it’s smoother if you foresee growth.

Example (illustrative only): you might allocate a VPC CIDR like 10.30.0.0/16, then split it into:

Public subnet: 10.30.1.0/24
Application subnet: 10.30.2.0/22
Database subnet: 10.30.3.0/24

Even if your exact numbers differ, the method should feel repeatable: define a larger envelope for the VPC, then carve it logically for tiers.

Subnet Strategy: Public, Private, and “Why Are These Mixed Again?”

Subnets represent IP address ranges within a VPC. The key is how you intend traffic to flow and who can access which resources.

Typical Subnet Roles

Public subnet: hosts components that need inbound access (for example, load balancers). Often these components have routes that allow internet-facing traffic through an associated gateway.
Private application subnet: hosts ECS instances that serve internal traffic or receive traffic only from controlled ingress paths.
Private database subnet: hosts database servers; access should be tightly restricted, ideally only from application subnet resources.

Some teams use more granular segmentation, like separate subnets for internal services versus batch jobs, or for different departments. That can be smart, as long as you keep the design understandable.

Subnet Count vs. Complexity

You can create many subnets, but each one adds routing and policy overhead. If your environment is small, splitting into three subnets might be enough. If your environment is large and heavily regulated, more segmentation might be necessary. The goal isn’t to use the maximum number of subnets—it’s to make the network predictable.

Routing Basics: Who Talks to Whom and How

Routing determines how traffic moves between networks and through gateways. In a well-planned VPC, routing is structured like a good conversation: clear topics, clear destinations, and no mysterious detours.

Default Route and Gateway Decisions

In many designs:

Internet-bound traffic from private resources goes through a NAT or similar egress mechanism.
Inbound internet traffic reaches public entry components (like load balancers), which then route internally to application instances.
Internal traffic between subnets uses private routing rules.

You’ll also consider whether you need:

Virtual Private Network (VPN) connectivity to on-premises
Direct connect/leased line style connectivity (depending on your scenario)
Peer connections between VPCs

For each connectivity type, routing rules must reflect the path you want traffic to take.

Common Routing Pitfalls

Overlapping address spaces between your VPC and connected networks.
Routes that “exist” but don’t actually apply due to using the wrong subnet association.
Forgetting return traffic: asymmetric routing can cause traffic to vanish into the void.
Mixing public and private assumptions: for example, expecting a private subnet to have internet access without NAT.

The best antidote is testing with small, controlled flows before you scale up.

Security Groups: The Bouncers at the Club Door

Security groups act like bouncers: they decide who is allowed to enter and what they can do once inside. Planning your security group strategy early prevents rule chaos later.

Security Group Planning Tips

Use least privilege: allow only necessary ports and protocols.
Huawei Cloud Account Marketplace Reference by role rather than by individual instance IPs when possible (for example, allow traffic from “application” security group to “database” security group).
Keep rules readable: naming conventions matter. Nobody wants to maintain a security group called “SG-1234-FINAL-FINAL2”.
Document intent: include a short note about why a rule exists.

If your environment uses multiple tiers, a common approach is:

Load balancer (if used) allows inbound from the internet (or as configured) to web ports.
Application servers allow inbound from the load balancer’s security group to app ports.
Database servers allow inbound from application servers’ security group to database ports.

This “tier-to-tier” model is easier to maintain than a spider web of broad rules.

Network ACLs vs. Security Groups

Depending on your configuration and services, you may also use network ACL-like mechanisms. In many environments, security groups provide stateful filtering, while ACLs can provide stateless, more granular control at the subnet level. The planning lesson is the same: don’t rely on multiple layers of rules blindly. Decide which layer owns which responsibility, and test accordingly.

Connectivity Patterns for Common ECS Architectures

Now let’s talk about the “shapes” of real deployments. Network planning becomes much easier when you recognize patterns you’ve used before.

Pattern 1: Single-Tier Web App (Simple but Not Lazy)

For a small web application, you might place ECS instances in a private subnet, then use a load balancer in a public subnet to handle inbound traffic. The load balancer forwards requests to the web ECS instances over private network paths.

Planning considerations:

Public subnet: load balancer resources
Private subnet: ECS instances
Security group rules: load balancer to ECS on web ports
Egress: NAT for outbound requests if instances must reach external services

Huawei Cloud Account Marketplace This is a clean start. You get internet access where it should be (through the load balancer) without making every ECS instance internet-facing.

Pattern 2: Web + Application + Database (The Classic Trio)

This is the bread-and-butter architecture. You’ll typically use:

Public subnet: load balancer
Application subnet: web servers and/or application logic
Database subnet: databases only

Security group planning becomes more meaningful here:

Huawei Cloud Account Marketplace Database inbound only from application security group on database port(s)
Application inbound from load balancer on app/web port(s)
No direct inbound from the internet to database

Also consider operational needs: database backups, admin access, and monitoring. You may allow admin connectivity only from a jump host or a management network rather than from random IPs.

Pattern 3: Microservices With East-West Traffic (Now the Network Feels Alive)

Microservices introduce more “east-west” traffic (services talking to services). Your network plan needs to be robust against service sprawl.

Common approaches include:

One application subnet per environment, with security groups per service role
Or more segmentation: subnets by service domain (for example, auth, payments, analytics)
Service discovery and DNS planning so services can find each other reliably

Be careful not to create dozens of nearly identical security groups with copy-paste rules. Instead, group services by role and use consistent naming.

Pattern 4: Hybrid Connectivity (On-Premises Meets Cloud)

When you connect on-premises to your VPC, address planning becomes critical. Overlapping ranges can cause traffic to go to the wrong place with the subtlety of a cat walking into a room full of bathwater.

In hybrid scenarios:

Ensure no CIDR overlap between your on-prem network and VPC ranges.
Huawei Cloud Account Marketplace Plan routing: which networks should route over VPN/leased line?
Decide whether you’ll access cloud resources from on-prem or vice versa.
Think about DNS: on-prem name resolution should work for cloud private endpoints if needed.

Test connectivity early with a small set of traffic flows.

DNS and Service Discovery: The Unsexy Superpower

Networks aren’t just IPs. In real applications, name resolution plays a huge role in usability and stability. For ECS deployments, you might use:

Private DNS for internal service names
Public DNS for edge endpoints
Load balancer DNS names or custom domains

When planning, decide:

Where each service name resolves to (internal IP, load balancer endpoint, etc.)
Whether you need split-horizon DNS (different answers inside vs outside the VPC)
How service discovery works for microservices

Many outages are “network-related,” but the root cause is DNS misalignment—like the service is healthy, but nobody can find it by name.

Huawei Cloud Account Marketplace Internet Access: NAT, Load Balancers, and the “Don’t Expose Everything” Rule

One of the biggest network planning mistakes is letting every private instance reach the internet through unmanaged routes, or worse, making them publicly reachable.

NAT for Egress

If private ECS instances need outbound internet access (for updates, API calls, third-party integrations), you typically use a NAT mechanism so that:

Instances keep private IPs
Outbound traffic is controlled and easier to monitor
Inbound traffic from the internet isn’t automatically allowed

Plan your NAT routing so only desired subnets use it. If you give NAT access broadly, you’re basically hosting a buffet for outbound traffic. Useful, but not always wise.

Load Balancers for Ingress

When you need inbound traffic, load balancers help centralize entry and keep your ECS instances from being directly internet-facing.

Planning considerations include:

Which listener ports/protocols are exposed publicly
Health checks and their target ports
Huawei Cloud Account Marketplace Session persistence needs (if any)
Target group selection (which ECS instances receive traffic)

Once your entry is centralized, security rules become simpler: you know exactly who can connect to your application tier.

High Availability and Multi-AZ Thinking (Even if You’re Not “Big Yet”)

Huawei Cloud may support multi-AZ (availability zones) behaviors depending on configurations. Even if you’re not operating a fortress of reliability today, you should plan so that adding redundancy later doesn’t require tearing down your network.

Key planning ideas:

Design subnets and resources so you can add instances across zones
Ensure load balancer configuration supports multiple targets
Avoid hard-coding dependencies that assume single-zone resources

Think of it as planning for the day your traffic doubles. Your network should respond like a grown-up, not like a toddler holding a drink with both hands and no lid.

Observability: How You’ll Debug When Things Go Wrong

Huawei Cloud Account Marketplace Network planning isn’t just about preventing issues—it’s also about making issues easier to find when they happen. Your future self will thank you for adding the right diagnostic hooks.

What to Monitor

Connectivity: can instances reach each other on expected ports?
Routing: are packets following intended paths?
Security rule hits: are denies occurring unexpectedly?
Gateway logs: NAT or load balancer logs can reveal patterns
DNS resolution: internal name resolution success/failure

Even a basic test plan helps. For example, after deploying a new subnet or security group, verify connectivity between tiers before you declare victory.

A Practical Testing Checklist (Because “It Works in My Head” Is Not a Test)

From a test ECS instance in application subnet, verify access to database port on database instances.
Verify inbound access to web/app endpoints through load balancer.
Verify outbound internet access from private app instances via NAT (if required).
Confirm that blocked traffic is actually blocked (for example, database does not accept inbound from internet-facing subnets).
Test DNS resolution for internal service names.

Do this in a non-production environment first if possible. Your production network deserves a gentle introduction, not a surprise performance review.

Operational Practices: Naming, Documentation, and Change Control

You can design the perfect VPC on paper and still create chaos through unclear naming and undocumented rules. So let’s talk about the human side of network planning.

Naming Conventions That Don’t Make You Cry

Use consistent naming for:

VPCs (include environment: dev/test/prod)
Subnets (include tier: public/app/db and maybe zone)
Security groups (include role and allowed traffic direction)
Resources like load balancers and gateways (include function)

If your organization is large, align with existing conventions. If you don’t have them, create lightweight ones and stick to them.

Document the Design Like a Responsible Adult

Maintain a simple network diagram and a short written summary covering:

VPC CIDR and subnet CIDRs
Which subnet each ECS tier belongs to
Routing gateways and outbound paths
Security group rules and their intent
Ingress and egress points (load balancer, NAT)

This doesn’t need to be a novel. But when you’re troubleshooting at 2 a.m., the difference between a paragraph and a guess is the difference between “fixed quickly” and “staring at dashboards until sunrise.”

Change Control: Avoid “One-Off” Rule Edits

As your system evolves, people will request changes like “just open this port for now.” If “for now” becomes “forever,” your security posture decays. Use a process:

Record the reason for any rule change.
Set a review date if the change is temporary.
Validate after change: test connectivity and confirm expected blocks.

Common “Why Isn’t It Working?” Scenarios

Even with planning, issues happen. Here are some classic troubleshooting patterns. Use them like a checklist when reality does what reality does.

Huawei Cloud Account Marketplace Scenario 1: App Can’t Reach Database

Symptoms: application ECS instances fail to connect to database ports. You test from within the application subnet and see timeouts or connection refusals.

What to check:

Security group on database tier allows inbound from application security group.
Database security group isn’t overly restrictive (wrong ports/protocols).
Route between subnets is correct (often private routing should work, but verify associations).
Database is listening on the correct interface/IP.

If everything is correct but it still fails, check DNS resolution or host firewall rules inside the ECS instances. Sometimes the network is innocent and the server is guilty.

Scenario 2: Public Endpoint Works, But Health Checks Fail

Symptoms: load balancer shows targets as unhealthy.

What to check:

Health check port and path are correct.
Security group rules allow load balancer to access the target on health check port.
Application is actually reachable from the load balancer subnet.
Any IP allowlisting in the app layer isn’t excluding the load balancer’s source.

Health checks are like asking, “Are you home?” If the app answers on a different doorbell, you’ll never know it’s awake.

Scenario 3: Private Instances Can’t Reach the Internet

Symptoms: application can’t download packages, call external APIs, or access public endpoints.

What to check:

Outbound routing uses NAT (if required).
NAT gateway is configured and associated with the correct route tables.
Security group egress rules (if applicable) allow outbound traffic.
Instance OS firewall or proxy configuration doesn’t block traffic.

In private subnet designs, internet access is usually an explicit decision. Private does not mean “magically internet-enabled.”

A Sample End-to-End Planning Blueprint (Illustrative)

To make this more concrete, here’s an illustrative blueprint you can adapt. Consider a typical web application stack with a database. We’ll outline how you’d plan your VPC, subnets, routing, and security groups.

Blueprint Assumptions

Environment: production
Need: internet access for web users via load balancer
App servers: private-only
Database: private-only and restricted
App servers: need outbound internet for updates and external API calls (optional)

Step 1: Choose VPC CIDR and Subnet CIDRs

VPC CIDR: 10.30.0.0/16
Public subnet CIDR: 10.30.1.0/24 (load balancer)
Application subnet CIDR: 10.30.2.0/22 (ECS app instances)
Database subnet CIDR: 10.30.3.0/24 (DB instances)

Ensure these CIDRs don’t overlap with any connected networks.

Step 2: Create and Associate Route Tables

Public subnet route table: allows ingress via load balancer and appropriate local routing.
Application subnet route table: local routing for internal traffic; NAT for external destinations if required.
Huawei Cloud Account Marketplace Database subnet route table: local routing; typically no need for outbound internet.

This keeps database traffic limited and reduces unnecessary exposure.

Step 3: Define Security Groups by Tier

LB security group: inbound from the internet to web port (as needed); outbound to application web port.
App security group: inbound from LB security group to app/web port; inbound from monitoring sources for metrics if needed; outbound to database port.
Huawei Cloud Account Marketplace DB security group: inbound only from app security group on database port; outbound only if required for backups or monitoring.

Keep rules tight. If you must open something temporarily, mark it and plan to close it later.

Step 4: Deploy ECS Instances in the Right Subnets

Create ECS app instances inside application subnet.
Create ECS database instances inside database subnet.
Associate each instance with its corresponding security group.

Then set the load balancer target group to include app instances.

Step 5: Validate With Connectivity Tests

From app instance, connect to DB port successfully.
From LB, confirm health checks succeed.
From app instance, confirm outbound internet works if NAT is configured.
Attempt blocked connections (like DB from app-to-internet) to ensure security rules behave as expected.

Only after validation should you scale up and deploy more services.

Final Checklist: Your VPC Planning “Don’t Forget This” List

Here’s a concise checklist you can use as a final review before go-live:

Have you chosen non-overlapping VPC and subnet CIDRs?
Do your subnets reflect functional tiers (public, app, db)?
Are route tables associated correctly with each subnet?
Is internet ingress handled through load balancers (not random server exposure)?
Huawei Cloud Account Marketplace Is outbound traffic from private instances controlled through NAT if needed?
Are security group rules least-privilege and tier-based?
Have you tested key flows: LB to app, app to DB, DNS resolution, outbound access?
Is monitoring/logging planned so troubleshooting isn’t guesswork?
Is the design documented with enough clarity for future you?

Conclusion: Build a Network That’s Boring in the Best Way

Huawei Cloud ECS VPC network planning doesn’t need to be a mystical rite performed under a cloudy sky. With thoughtful address planning, clear subnet roles, disciplined routing decisions, and secure, maintainable security group rules, you can build a VPC that stays understandable as you grow. And remember: a boring network is a happy network. When your traffic flows predictably and your rules are clear, you spend less time chasing ghosts and more time delivering features.

So go ahead—plan your VPC like an adult, test it like a scientist, and document it like someone who’s definitely going to be on-call later. Your future self will bring snacks. Probably.