Alibaba Cloud KYC transfer Alibaba Cloud VPC Network Setup Tutorial

Alibaba Cloud KYC transfer Overview: What You’ll Build

This tutorial walks you through setting up an Alibaba Cloud VPC (Virtual Private Cloud) network in a practical, end-to-end way. You’ll learn how to plan the network, create the VPC and vSwitches, connect subnets to route tables, configure NAT or gateways when you need internet access, and verify connectivity with simple checks.

Even if your project is small, a good VPC setup saves time later. Most network issues—unreachable services, “works in one subnet but not another,” missing outbound access—come from skipping a design step or misconfiguring route tables.

Alibaba Cloud KYC transfer Before You Start: Plan Your Network

1) Choose a CIDR block

A VPC needs an IP address range (CIDR), for example 10.0.0.0/16. Inside that range you will create subnets (vSwitches), usually smaller ranges like 10.0.1.0/24, 10.0.2.0/24, etc.

Key rule: your VPC CIDR must not overlap with other networks you will connect to later (on-premises, VPN, other clouds). Overlap is the #1 cause of confusing routing problems.

2) Decide how many subnets you need

Subnets typically map to function and security boundaries. Common patterns:

• Public subnet: resources that need inbound access (like load balancers) and outbound access through NAT.
• Private subnet: application servers that shouldn’t be reachable from the internet directly.
• Management subnet (optional): restricted access for admin tools.

You can keep it simple: one public and one private subnet is enough for many tutorials and small projects.

3) Select regions, zones, and availability

Alibaba Cloud resources are organized by region and zone. A vSwitch is created in a specific zone. If you plan to run multiple instances for high availability, spread them across zones and ensure routing works between them.

Create the VPC

Step 1: Go to the VPC console and create a VPC

In the Alibaba Cloud console, open the VPC (Virtual Private Cloud) service and choose to create a VPC. You will be asked for:

• VPC name (any clear label)
• Region
• VPC CIDR (like 10.0.0.0/16)
• VSwitch configuration plan (you can do it now or later)

Set a CIDR big enough for growth. Changing CIDR later is painful because it impacts subnet ranges and routing.

Step 2: Verify VPC basic settings

After creation, you should see the VPC with its CIDR, status, and related components. Keep this page open—you’ll use it to create vSwitches and route tables.

Create vSwitches (Subnets)

Step 1: Create a public vSwitch

Create a vSwitch inside your VPC. Typical settings:

• Zone: pick one
• VSwitch CIDR: an available range within the VPC CIDR, e.g. 10.0.1.0/24
• VSwitch name: like public-1

Decide which zone the subnet belongs to. If you create only one subnet, you still need to pick a zone.

Step 2: Create a private vSwitch

Create another vSwitch in the same or different zone (depending on your design). Example:

• Alibaba Cloud KYC transfer Zone: same as public-1 if you want simpler testing
• VSwitch CIDR: 10.0.2.0/24
• VSwitch name: private-1

Keep private and public subnets separate even if you test with few instances. It makes security and routing clearer.

Route Tables: The Core of Connectivity

In VPC networking, routing determines how traffic moves. If you don’t set up routes correctly, instances can’t reach each other across subnets, or they can’t reach the internet.

Alibaba Cloud KYC transfer Step 1: Understand the default behavior

Usually, the VPC has an internal routing rule that allows communication between subnets inside the same VPC CIDR. That means instances in public and private subnets can often talk to each other as long as security groups allow it.

However, outbound internet access and certain cross-network scenarios require additional routes (for example via NAT or a gateway).

Step 2: Create separate route tables (recommended)

To avoid confusion, create at least two route tables:

• Public route table: allow internet outbound if you plan to use NAT for public instances.
• Private route table: control internet outbound for private instances through NAT or other controlled paths.

Whether you choose to attach NAT to private only, or to both, depends on your use case.

Step 3: Associate route tables with vSwitches

Attach the public route table to the public vSwitch and the private route table to the private vSwitch. This step is easy to miss. If you attach the wrong route table, instances will behave unexpectedly.

Internet Access: NAT or Gateway

Most real applications need outbound internet (updates, package downloads, calling public APIs). In many VPC designs, you don’t want the private subnet directly exposed.

Option A: Use a NAT Gateway for private subnet outbound

Common approach: private instances send outbound traffic to the internet through a NAT Gateway. Typical NAT setup involves:

• Create a NAT Gateway
• Select the vSwitch or subnet it serves
• Set an outbound route rule (default route) pointing to NAT

When NAT is configured correctly, private instances can reach the internet for outbound connections, but inbound from the internet still isn’t directly allowed.

Step 4: Add a default route (0.0.0.0/0) to route table

In the private route table, create a route entry:

• Destination CIDR: 0.0.0.0/0
• Next hop: NAT Gateway

After this, verify that the route table is associated with your private vSwitch.

Option B: Internet Gateway for inbound (when needed)

If you need public inbound access (for example, a web server or a load balancer), you usually use an Internet Gateway and bind it through the public route table. Then you also need a public IP and firewall rules.

For many setups, a load balancer is preferred so you can scale and terminate connections cleanly. But the networking concept stays: public subnet routes and inbound exposure must be deliberate.

Alibaba Cloud KYC transfer Security Groups: Allow Only What You Need

Routing alone doesn’t guarantee traffic. Alibaba Cloud security groups and firewall rules decide what is allowed.

Step 1: Create or check security groups

Create security groups for your instances (or for the load balancer). You typically need two directions:

• Inbound rules: which ports are allowed (SSH, HTTP/HTTPS, custom app ports)
• Outbound rules: which destinations and ports can be reached

For outbound, if you rely on NAT for internet access, ensure outbound traffic isn’t blocked.

Step 2: Use principle of least privilege

Examples:

• Public-facing security group: allow 80/443 from the internet (source 0.0.0.0/0) if you really need it.
• Private application security group: allow inbound only from the public subnet’s components or security group, not from the entire internet.
• SSH: allow only from your office IP or a trusted bastion host.

Step 3: Verify security group references work across subnets

If you allow inbound from a security group rather than a CIDR range, you reduce fragility. Instances in different subnets can still match the rule as long as they belong to the referenced security group.

Launch Instances and Assign Network Interfaces

Step 1: Create an instance in the public vSwitch

When creating a compute instance, you will select:

• VPC: your VPC
• vSwitch: your public vSwitch
• Security group: public security group

If the instance needs inbound access, assign a public IP as required by the console choice. Don’t assume every instance in a public subnet is automatically reachable.

Step 2: Create an instance in the private vSwitch

Create your application instance in the private vSwitch and attach the private security group. Do not assign a public IP unless your design explicitly requires it.

At this point, the private instance should usually be reachable from the public instance (internal routing + security group rules). Internet outbound should depend on NAT and route table configuration.

Test Connectivity Step by Step

Testing should be methodical. When something fails, you want to know whether the problem is DNS, routing, security groups, or application configuration.

Test 1: Verify internal connectivity (public to private)

From the public instance, try to reach the private instance’s private IP:

• Alibaba Cloud KYC transfer Ping (if allowed by OS firewall)
• Try TCP connection to your app port

If internal connectivity fails, check:

• Are both instances in the same VPC CIDR?
• Is the private instance’s security group allowing inbound from the public instance (or its security group)?
• Is the route table associated with the subnets correct?

Test 2: Verify internet outbound from private instance

From the private instance, attempt outbound access:

• DNS resolution (resolve a domain)
• HTTPS connection to a public site

If outbound doesn’t work, check:

• Does the private route table have a 0.0.0.0/0 route pointing to NAT?
• Is the NAT gateway status healthy?
• Is outbound allowed in the private security group?
• Is the instance OS firewall blocking egress?

Test 3: Verify inbound to public service

If you run a web server on the public instance, test from your local machine:

• Alibaba Cloud KYC transfer HTTP/HTTPS ports are open
• Public IP is assigned correctly

If it fails, check security group inbound rules, OS firewall, and whether the public route table has the correct paths to the internet gateway.

Common Mistakes and How to Fix Them

Mistake 1: Overlapping CIDR ranges

If you later connect VPN or additional networks and discover “no route” behavior, CIDR overlap may be the reason. Fixing it requires redesigning CIDRs and recreating networking resources.

Mistake 2: Route table not associated with the vSwitch

You can create the correct route rule, but if it’s not associated to the vSwitch, instances won’t use it. Always confirm the association status.

Mistake 3: Security group mismatch

Routing might be correct, but security groups still block traffic. For example, outbound is blocked by default or inbound only allows a CIDR you’re not using. Use security group references when possible.

Mistake 4: Missing outbound rules for NAT use cases

Some security group policies restrict outbound. If your NAT gateway is correct but egress fails, update outbound rules to allow the needed ports (at least DNS and HTTPS if you test with web access).

Mistake 5: Assuming vSwitch equals “public” in every sense

A “public subnet” is mostly a naming and design concept. True internet reachability depends on your gateway, routes, public IP assignment, and security group rules. Treat “public” as a design label that you must implement.

Recommended Reference Architecture (Simple and Safe)

If you want a clean baseline that works for many projects, use this pattern:

• VPC: 10.0.0.0/16
• Public vSwitch: 10.0.1.0/24
• Private vSwitch: 10.0.2.0/24
• Public route table: internet path for inbound where needed
• Private route table: default route to NAT for outbound
• Security groups: public allows web ports, private allows only from public components

This keeps your application servers private while still enabling outbound updates and API calls.

Troubleshooting Checklist (Quick)

When something doesn’t work, use this sequence. It reduces guesswork:

• Alibaba Cloud KYC transfer Step A: Confirm IP ranges (VPC CIDR and vSwitch CIDRs don’t overlap, instances have correct private IPs)
• Step B: Confirm subnet association (each instance is attached to the intended vSwitch)
• Step C: Confirm route table association (public/private route tables are linked to the correct vSwitches)
• Step D: Confirm routes (0.0.0.0/0 to NAT for private outbound if required)
• Step E: Confirm security group rules (inbound/outbound for the specific ports and sources)
• Step F: Confirm OS firewall and service binding (service listens on the right interface; OS firewall allows the traffic)
• Step G: Confirm DNS (if outbound requires DNS, test name resolution)

Alibaba Cloud KYC transfer Scaling Up: What to Consider Next

Once the basic VPC works, you’ll likely want improvements:

• Multiple instances behind a load balancer in the public subnet
• More private subnets for different tiers (app, data, cache)
• Stronger access control using security group references and restricted admin access
• Centralized monitoring to track connection failures early

The foundational steps in this tutorial—CIDR planning, vSwitch creation, route table association, and security group rules—remain the backbone for everything else.

Wrap-up

Setting up Alibaba Cloud VPC networking is not only about clicking “Create.” It’s about building a clear plan: IP ranges, subnet roles, route table intent, and security group restrictions. Once those pieces align, connectivity becomes predictable and troubleshooting becomes straightforward.

If you follow the order in this tutorial—plan first, create VPC, create vSwitches, configure route tables, set up NAT or gateway as needed, attach security groups correctly, then test in steps—you’ll end up with a working VPC network that you can extend with confidence.