【发布时间】：2018-06-18 07:59:07
【问题描述】：
在 AWS 上创建 EC2 实例（或其他类型的东西）时，会出现一个默认 VPC。
另外，作为另一种选择，可以预先创建一个 VPC，并在 EC2 实例创建等过程中进行选择。
那么，在哪些用例中我们应该创建一个新的 VPC 而不是使用默认的 VPC？
【问题讨论】：
标签： amazon-web-services amazon-vpc
【发布时间】：2018-06-18 07:59:07
【问题描述】：
AWS Documentation 很好地描述了他们如何创建默认 VPC。
当我们创建一个默认 VPC 时，我们执行以下操作来设置它 你：
- 创建一个大小为 /16 IPv4 CIDR 块 (172.31.0.0/16) 的 VPC。这提供了多达 65,536 个私有 IPv4 地址。
- 在每个可用区中创建一个大小为 /20 的默认子网。这为每个子网提供了多达 4,096 个地址，其中一些是保留的 供我们使用。
- 创建一个互联网网关并将其连接到您的默认 VPC。
- 为您的默认 VPC 创建一个主路由表，其中包含将所有发往 Internet 的 IPv4 流量发送到 Internet 的规则 网关。
- 创建一个默认安全组并将其与您的默认 VPC 关联。
- 创建默认网络访问控制列表 (ACL) 并将其与您的默认 VPC 关联。
- 将为您的 AWS 账户设置的默认 DHCP 选项与您的默认 VPC 相关联。
这对于简单的应用程序和概念验证非常有用，但不适用于生产部署。例如，数据库实例不应该公开可用，并且应该放置在私有子网中，这是默认 VPC 所没有的。然后，您将创建某种类型的后端实例，该实例将连接到数据库并向公众公开一个 REST 接口。
另一个原因可能是您正在运行多个相互复制的环境（DEV、QA、PROD）。在这种情况下，您可能希望它们彼此完全隔离，以免在 DEV 环境中部署不当而意外影响 PROD 环境。
这个列表可能还有其他原因，而且可能有一些比我今天向您介绍的更好。
【讨论】：
-
体面的。那么，您的意思是说这个想法可以主要概括为两类：对于 Intranet 结构和多个环境级别？
-
我想你可以说它们是我想出的两个用例。另一个可能是您想要设置一个堡垒主机，该主机可以访问只能通过 SSH 隧道访问的资源。所有项目的最终目标是访问控制，资源应该只能访问它需要工作的内容。将一堆 EC2 实例放在公共子网中不会提供此功能。
如果您相当了解 VPC，那么您应该始终创建自己的 VPC。这是因为您可以完全控制结构。
我怀疑提供默认 VPC 的主要原因是人们无需先了解 VPC 即可启动 Amazon EC2 实例。
【讨论】：