前言

刚开始搞云计算那会儿，我也觉得VPC这玩意儿挺虚的。

控制台点进去一堆名词往脸上砸：Subnet、Route Table、Internet Gateway、NAT Gateway、Security Group、NACL、Endpoint、Peering……看着像网络，又不像传统机房那种网络。以前在机房里，交换机、路由器、防火墙、网线，摸得着看得见，排障还能去机柜边上看灯闪不闪。到了云上，啥都在页面里点来点去，概念全靠想象，理解起来总感觉隔了一层

这篇文章我就按我平时做云上网络规划的思路，拿AWS从头到尾搭一个贴近生产的小型VPC。不是那种点几下创建EC2能上网就完事的入门教程，而是把里面每个组件为什么这么配、出了问题怎么查、哪些地方容易踩坑都聊清楚。

VPC 简介

VPC，全称Virtual Private Cloud，翻译过来就是虚拟私有云。

你可以把它理解成：AWS在它那个巨大的全球网络基础设施里面，给你圈出来的一块“逻辑上完全隔离的私有网络空间”。这个空间里，你自己说了算：

• IP地址段用多大，随便选
• 哪些机器能访问公网，哪些只能内部互通
• 流量怎么走，哪些能出互联网
• 访问AWS其他服务走不走公网
• 多AZ之间怎么组网
• 怎么跟公司本地机房打通

它不是一台具体的物理设备，也不是一个单一的网关服务。它更像一个容器，所有EC2、RDS、EKS节点、ALB、ElastiCache，只要放进去，就都得遵守这个VPC定下的网络规则。

我之前给团队新来的同事解释VPC，喜欢打个不太严谨的比方：

生产环境我基本不用默认 VPC

AWS每个Region创建账号之后都会自带一个default VPC，你直接在控制台Launch Instance，它默认就塞进这个VPC里，机器起来就能上网，对新手非常友好。

但生产环境我基本不用它。

原因很简单：默认VPC的IP段通常是172.31.0.0/16，子网和路由表都是AWS自动建好的，你不知道里面有啥也不知道改了对业务有啥影响。特别是当团队变大、多个人同时操作的时候，一个不留神把默认VPC的路由表改了，整组人集体断网，那场面真的挺刺激的。

所以我现在不管是搭测试环境还是生产环境，第一步永远是先Create Your Own VPC，从头规划，自己掌控。

实操：从头搭一个生产级 VPC

规划IP地址段

这是最容易被忽略但其实最关键的一步。

IP段选大了浪费，选小了以后扩容麻烦。我一般会问自己几个问题：

• 这个VPC要放哪些业务
• 预估有多少台机器
• 需不需要跟其他VPC打通
• 有没有本地IDC要互联

拿我现在给一个中小型 SaaS 服务搭的VPC举例，我选了10.100.0.0/16这个段。

为什么是这个段？没什么硬性要求，主要是我司IDC用的是10.50.0.0/16，云上用10.100.0.0/16，两边不打架，好记。以后要是真拉专线打通，路由也好配。

然后把这个大段拆成几个子网：

• 10.100.1.0/24 — 公网子网，AZ1
• 10.100.2.0/24 — 公网子网，AZ2
• 10.100.11.0/24 — 私网子网，AZ1
• 10.100.12.0/24 — 私网子网，AZ2
• 10.100.21.0/24 — 数据库子网，AZ1
• 10.100.22.0/24 — 数据库子网，AZ2

公网子网放什么？ALB、NAT Gateway、需要对外提供服务的EC2。

私网子网放什么？应用服务器，Web服务器那些跑业务代码的。

数据库子网放什么？RDS、ElastiCache，那些不放公网、只允许应用层访问的。

子网划分没有标准答案，但有个原则要记住：公网和私网一定要分开，别为了省事把数据库直接塞公网子网里。