五个会让你追悔的错误VPC 配置

使用虚拟私有云VPC，用户可以获得理想的灵活度和安全保障。Amazon的VPC允许用户在一个隔离的虚拟网络中提供计算资源（比如EC2实例和RDS部署），让用户可以完全控制网络流量。根据实际使用场景，用户可以选择IP地址范围、子网集、路由表以及网络网关配置。使用VPC，用户可以得到真正的控制权。

下面是VPC提供的几个优势：

鉴于在AWS VPC中发布的实例不可以被公网直接访问，因此用户可以获得更高的安全保障。

VPC简化了安全，允许ACLs、路由规则和安全组的无缝集成

用户可以添加多重网络接口。

用户可以直接将本地网络连接到AWS VPC。

VPC可以简化安全实施和多层网络部署（比如将一个公共应用连接到一个私有子网中的私有数据库）。

通过专用连接，基于VPC连通性的灾难恢复备份镜像可以让业务关键数据恢复起来更加容易和可靠。

专注发布的实例运行在只为单个客户服务的硬件上，从而获得额外的隔离性。

换句话说

即使VPC设计如此精良，它仍然不是万无一失的，更不说其中还存在着人为因素。鉴于每个人都期望接近完美的部署，那么注意了，一定要确保部署时已经避免了下述错误，这是AWS VPC部署过程中可能会犯的5个错误：

1. 不当的subnet/CIDR Block规划。

在设计VPC subnet和CIDR Block时，管理员通常无法保障网络兼容性和未来需求。注意，AWS VPC 子网块一旦分配，后续就无法修改，因此你在规划每个子网的时候要考虑未来它可能需要部署的节点数量。这里需要注意的是，建立一个/24或者/27 CIDR可能会无法满足你对足够地址数量的需求。还有，如果你给VPC子网分配了10.0.0.0/16 block，但是却想把与之连接的本地数据中心分配10.0.26.0/24，那么最终肯定会不欢而散。

2. 公共IP地址。

当你将一个实例发布到非默认的VPC公共子网时（在默认设置下），如果使用旧的EC2-Classic方式，它将不会获得一个公共IP或者主机名。一旦创建，唯一让实例可公共寻址的途径就是给节点分配一个弹性的IP。弹性IP并不能无限使用，每个账户只可以使用5个（当然你可以通过其他方式获得更多）。

3. 共享生产和开发环境。

如果将应用的所有阶段（开发和生产环境）都塞到同一个VPC，未来将出现大量的混淆，遭受没玩没了的安全组及路由表冲突。

4. 忽略NAT实例的分布式冗余。

聪明的管理员永远都会把应用程序高可用性放在足够重要的位置，但是仍然有一部分管理员会做这样的事情——他们把应用程序或者数据库部署到一个私有子网中，但是却通过单机NAT实例将之与远程服务（比如S3、SQS、补丁和升级）连接。那么，一旦NAT实例挂掉，整个应用程序将崩溃。

5. 认为AWS VPC需要非常复杂的网络技巧。

VPC并不是交换机，VPC网络也不是路由器，更不是防火墙。虽然它执行着这3个硬件工具的职能，但是VPC其实是一个软件定义网络（SDN）。从上到下，AWS尽可能地将其设计的简单明了。当然，你也需要理解一些类似路由、NAT、VPN及ACL等的基本网络概念，然而AWS已经帮你完成了大部分重活。

总结

如果你仍然使用EC2-Classic来托管你的实例，你需要认真地考虑一下是否要迁移到AWS VPC，从而享受VPC带来的大量益处。但是无论如何，你时刻都不能丢开最佳实践也时刻为未来的使用场景考虑