AWS为用户提供了一个虚拟的数据中心，用户可以将EC2 instance、RDS（Amazon Relational Database Service）、EMR Clusters等资源部署到这个虚拟的数据中心。不仅如此，这些资源还需要同internet进行通讯。
Amazon VPC 允许用户在 Amazon Web Services (AWS) 云中预置出一个逻辑隔离的部分，让用户在自己定义的虚拟网络中启动 AWS 资源。用户可以完全掌控这个虚拟网络环境，包括选择自己的 IP 地址范围、创建子网以及配置路由表和网络网关。
VPC 概念和基础知识
IP 地址范围
根据RFC 1918，为了解决IPV4地址将要耗尽和ISP（Internet Service Provider）路由负荷即将过载的问题，人们提出了一个方案：一个ISP从地址注册组织获得一个地址块，然后根据每个客户的要求将块内的地址分配给客户。到许多客户的路由将会被聚合起来,对其他服务提供商呈现为一个单一的路由。
在企业内部使用IP的主机在企业内部无多义，而根据其在企业之间是否可能有多义的IP地址，可以将主机分为“私有的”和“公开的”。
因特网域名分配组织IANA组织（Internet Assigned Numbers Authority）保留了以下三个IP地址块用于私有网络。
10.0.0.0 - 10.255.255.255 (10/8比特前缀)
172.16.0.0 - 172.31.255.255 (172.16/12比特前缀)
192.168.0.0 - 192.168.255.255 (192.168/16比特前缀)
我们把第一块称为“24-比特块”，第二块称为“20-比特块”，第三块称为“16-比特块”注意（在前面的CIDR 记号中），第一块地址就是一个A类网络号，第二块地址是16个连续的B类网络号集合，第三块地址是256个连续的C类网络号集合。
假设，一个私有网络172.31.0.0/16，那么可以将这个私有网络的IP分为两部分，“172.32”是网络号，后16位是主机号。这个私有网络中的IP地址范围不会和Internet中的IP冲突。但是，要尽量避免和其他VPC中的私有IP地址范围产生冲突。
AWS推荐 /16 的IPv4 CIDR block（例如172.31.0.0/16）。
在VPC中建立subnet
为每个AZ建立一个subnet，这样，如果一个AZ的 subnet出现了问题，就不会影响到其他subnet：172.32.0.0/24，172.32.0.1/24，172.32.0.2/24。
Routing in a VPC
每个VPC都有一个route table，用于告诉系统如何对package进行路由。每个VPC都有一个default table，用于描述package如何在VPC内部进行通讯。用户可以为subnet创建不同的route table。
VPC 内部
通过default table完成
和Internet
和 internet 通讯的三要素：
- 某种形式的connection
- route to internet
- public address
从这张图上可以看到，VPC是如何实现三要素的。
首先，VPC 通过 internet gateway和internet建立连接。在图里是个“门”的形状，不过最新的图里面是这样的图标：
其次，VPC提供了两个route表。一个是igw_id，部署在共有subnet上，用与将目的地址不是本subnet的package发送到internet gateway，以实现同internet的通讯，该网关允许来自internet的请求；另一个route表是Nat_gw_id，部署在私有subnet上，指向NAT gateway，这是一张单向表，只允许从VPC内部访问internet的request（Outbound internet access）通过，不允许internet到VPC内部的request通过。这里为了让私有subnet能够和internet gateway 通讯，引入了一个新的网关，NAT gateway，其图标为：
最后，在launch上面的subnet的时候，为其制定了一个公有IP，即198.51.100.3。
网络安全
Security Group（SG）
首先有一点值得强调，Security Group是Stateful的，如果一个入站（inbound）的traffic是被允许通过的，那么其对应的出站（outbound）的response也必然被允许通过。
具体来说，在下图中共有7个实例，其中4个被标成了黄色，表示需要和internet 通讯的web sever；另外3个被标成了蓝色，表示不需要和外部通讯的backend server。为黄色的实例建立Security Group MyWebServer，为蓝色的实例建立Security Group MyBackendServer，这样可以允许来自任意地址的traffic访问MyWebServer内的实例，而只允许来自MyWebServer访问MyBackendServer内的实例。
Network Access Control List（NACL）
NACL也是VPC的一种安全机制，但是和Security Group 有一些不同之处：
Flow logs
在VPC中，日志有以下几种级别：
- instance level
- subnet level
- VPC level
如以下图所示，VPC将日志信息发送到AWS 的 Bucket 和 Cloud Watch 组件上，进一步用于可视化、问题排查、流量分析。这里，流量分析仅涉及package的描述信息，而不涉及package的payload信息。
这里又多了三个新的图标：
最后，让我们简单看一下VPC flow logs的格式：
这条日志描述了以下信息：
接受从共有地址210.21.226.2的ssh入站package。
Connectivity Options for VPCs
VPC主要涉及两类连接：
- Connecting to other VPCs
-
Connecting to your on-premises networks
Connecting to other VPCs
VPC之间的连接有两种形式，VPC peering 和 Transit gateway。
- 首先，来看VPC peering。
VPC peering 是指在两个VPC之间建立连接，使得他们之间可以相互通讯，就好像在同一个私有网络内一样。VPC Peering 可以跨AWS region，也可以跨 AWS 账户。
VPC Peering 有其自身的局限性，它无法在两个重叠的CIDR block间建立连接。 而且它是1对1的关系，也就是说下图所示的关系是不可能的：
必须以以下方式建立连接：
- 接下来，再看 Transit gateway
在Peering模式下，必须在任意两个VPC之间建立连接。如果有很多VPC，这项工作将变得异常繁重。这个时候，就需要引入Transit Gateway 模式了。
Transit gateway 将多个VPC之间的连接关系集中管理，且这些VPC可以来自不同的账户，尽管他们必须和Transit gateway在同一region。
- 比较 Peering 和 Transit gateway
Connect to on-premises networks
有两种方法在 VPC 和 on-premises 之间建立网络连接：AWS VPN 和 AWS Direct Connection。
AWS VPN
为了建立AWS VPN，首先需要在 on_premise 端建立Customer gateway，并为其配置路由；在VPC端，建立 Virtual private gateway。之后，为这两个 gateway 建立两个独立的IPSec tunnel，之所以需要两个IPSec tunnel，是为了保证通讯的高可用性（HA）。最后，如果没有用动态的路由协议（例如 BGP），那么就需要更新VPC内的路由表，告诉 VPC 如何到达on-premise。
看起来不错，但是 AWS VPN 毕竟是运行在 internet 上的，有一定的不确定性，而 Direct Connect 就可以解决这个问题。
Direct Connect
在AWS上，不仅有VPC，还有各种各样的service，这些service是在VPC之外的。我们希望从on_premise访问VPC的同时，也能访问到这些service。为此，就需要 AWS Direct Connect Location 的帮助。AWS Direct Connect Location 被发布到website上，可以根据data center的位置就近选择。这是一种物理上的专线，在On_Premise端，建立private virtual interface（VLAN），用于访问VPC；同时建立一条public virtual（VLAN），用于访问service。
这里引入了两个新的图标：
在网上还找到了一张清楚些的图，以供参考：
多个VPC
也可以让 On_Premise network 连接多个VPC：
一种方式是建立一个Private virtual interface （VLAN），然后通过Direct Gateway 同多个VPC建立连接：
另一种方式是通过AWS VPC。在没有 transit gateway的时候，需要为每个VPC建立一个AWS VPC connection：
而有了 transit gateway ， 事情变得更加简单，通过一个 transit gateway，就可以建立从 On_Premise 到所有VPCs的连接：
Route 53
AWS DNS
VPC endpoints
在VPC之外，AWS的公有地址空间内还有很多服务，我们可以通过direct connect 和 virtual interface，从On_Premise network 去访问这些资源。但是如何在VPC内部访问这些资源呢？可以通过 IGW, NAT devices的方式访问，但是如果你觉得那样做比较麻烦（因为需要public IP），可以选择 endpoint 的方式实现。
-
通过IGW 访问
有两种方式：gateway endpoint 和 interface endpoint。
gateway endpoint
在route table上，可以配置一个指向AWS service的路由目标，这个gateway就是所谓的gateway endpoint。这里没有public IP，只需要private IP 就可以完成设置。
interface endpoint
通过interface endpoint，不需要任何路由，就你所访问的AWS service好像在VPC内部一样。
这里，有一个新的图标PrivateLink。PrivateLink是interface endpoint得以实现的关键。通过PrivateLink，你可以将你的AWS Service 分享给千千万万个VPC。为此，你需要将被分享的Service放在一个 Network LoadBalancer 后面，使得该服务可以作为一个 endpoint service 被其他VPC访问。其他的VPC可以订阅你的Service，并在他的VPC创建endpoint代表你的Service，通过本地地址的endpoint访问你的Service。
参考资料
AWS 2019 summit 视频地址：https://aws.amazon.com/cn/vpc/?vpc-blogs.sort-by=item.additionalFields.createdDate&vpc-blogs.sort-order=desc
演讲者：Perry Wald and Tom Adamski
参考读书笔记：https://blog.csdn.net/Jerry7810/article/details/103581167
