AWS VPC 网络架构
AWS VPC Network Architecture
我有以下三种网络架构（类似于 https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario3.html），将用于 web-based、DB-driven 应用程序：
- 有效地增强服务器之间的通信
- 发展安全
- 网络策略确保节点安全有序
记下每个 VPC 和每个子网的 CIDR。每个子网的访问都由路由表和网络访问控制列表控制，为简单起见，图中未显示这些列表。所有子网都不同，有些是 public，有些是私有的，有些需要与其他子网交互，如箭头所示。
问题：
- VPC 架构 2 是对 VPC 架构 1 的增强吗？
- VPC 架构 3 是对 VPC 架构 2 的增强吗？ （注意每个 VPC CIDR 是如何相同的 10.0.0.0/20）
- 如果 VPC 架构 3 具有相同的 VPC CIDR 10.0.0.0/20，是否会或可能会受到惩罚？
- 如果我决定桥接 vpc-4 和 vpc-5 怎么办？
- 如果这些架构中的 none 适合我的 web-db 网络需求，您能否提供或指出好的网络架构指南？
不胜感激。
Is VPC Architecture 2 an enhancement over VPC Architecture 1?
出于所有实际目的，VPC 说明 1 对于您的用例来说更加微妙，并且还可以避免任何区域间或跨区域 VPC 对等 management/costs。
Is VPC Architecture 3 an enhancement over VPC Architecture 2? (Note
how each VPC CIDR is the same 10.0.0.0/20)
不，这不是增强的情况。事实上，无论您是否在您的帐户中进行 VPC 对等互连，您都不应该在 VPC 之间有重叠的 CIDR 范围
Is there or could there be a penalty for VPC Architecture 3 to have
the same VPC CIDR of 10.0.0.0/20? What if I decide to bridge vpc-4 and
vpc-5?
是的，您不应该创建另一个具有重叠或匹配 CIDR 范围的 VPC
If none of these architectures are good for my web-db networking
needs, could you provide or point me towards good network architecture
guidelines?
对于此用例的所有实际需求，插图 1 适合初学者
谢谢@Raunak-Jhawar。关于 VPC Architecture 1 适合初学者的说法是正确的。但是随着越来越多的节点加入到VPC中，这个架构会变得越来越复杂和难以管理。
我所有的 VPC 网络架构设计都是正确的，并且会根据您的需要工作。不过，我想分享一些 AWS Support 的大佬们给我的信息。
VPC Architecture 1:
This Architecture is pretty much simple.Everything will work like a
charm. You can deploy the application servers in public subnet and db
servers in a private subnet(If you do not wish to grant access to the
DB server from internet).This Architecture will be easy to manage and
all your requirements will be fulfilled with this type of
Architecture.
VPC Architecture 2:
I can see that in VPC2, the CIDR block give was 10.0.0.0/20 which
gives us ip range from 10.0.0.0 to 10.0.15.255. However, the VPC3 has
a CIDR block given as 10.0.2.0/20, which also comes in a same range as
of VPC 2 ip addresses. Hence, the Architecture 2 and 3 become same
here.I believe, you wanted to show non overlapping CIDR range in VPC 2
and 3. Following my assumption, I would like to inform you that this
Architecture can also be used. Customers use this kind of Architecture
when they have multiple end customers. And these end customers also
want to communicate with each other through VPC peering. VPC peering
is possible when the VPC's has non overlapping subnets.
VPC Architecture 3:
This Architecture could also work however, the VPC peering/bridging is
not possible in this case.Because, VPC 4 and 5 have same CIDR ip
range. Hence, this is not a valid Architecture if you want to make
VPC 4 and 5 communicate with each other.
这是很好的信息。
我有以下三种网络架构（类似于 https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario3.html），将用于 web-based、DB-driven 应用程序：
- 有效地增强服务器之间的通信
- 发展安全
- 网络策略确保节点安全有序
记下每个 VPC 和每个子网的 CIDR。每个子网的访问都由路由表和网络访问控制列表控制，为简单起见，图中未显示这些列表。所有子网都不同，有些是 public，有些是私有的，有些需要与其他子网交互，如箭头所示。
问题：
- VPC 架构 2 是对 VPC 架构 1 的增强吗？
- VPC 架构 3 是对 VPC 架构 2 的增强吗？ （注意每个 VPC CIDR 是如何相同的 10.0.0.0/20）
- 如果 VPC 架构 3 具有相同的 VPC CIDR 10.0.0.0/20，是否会或可能会受到惩罚？
- 如果我决定桥接 vpc-4 和 vpc-5 怎么办？
- 如果这些架构中的 none 适合我的 web-db 网络需求，您能否提供或指出好的网络架构指南？
不胜感激。
Is VPC Architecture 2 an enhancement over VPC Architecture 1?
出于所有实际目的，VPC 说明 1 对于您的用例来说更加微妙，并且还可以避免任何区域间或跨区域 VPC 对等 management/costs。
Is VPC Architecture 3 an enhancement over VPC Architecture 2? (Note how each VPC CIDR is the same 10.0.0.0/20)
不，这不是增强的情况。事实上，无论您是否在您的帐户中进行 VPC 对等互连，您都不应该在 VPC 之间有重叠的 CIDR 范围
Is there or could there be a penalty for VPC Architecture 3 to have the same VPC CIDR of 10.0.0.0/20? What if I decide to bridge vpc-4 and vpc-5?
是的，您不应该创建另一个具有重叠或匹配 CIDR 范围的 VPC
If none of these architectures are good for my web-db networking needs, could you provide or point me towards good network architecture guidelines?
对于此用例的所有实际需求，插图 1 适合初学者
谢谢@Raunak-Jhawar。关于 VPC Architecture 1 适合初学者的说法是正确的。但是随着越来越多的节点加入到VPC中，这个架构会变得越来越复杂和难以管理。
我所有的 VPC 网络架构设计都是正确的，并且会根据您的需要工作。不过，我想分享一些 AWS Support 的大佬们给我的信息。
VPC Architecture 1:
This Architecture is pretty much simple.Everything will work like a charm. You can deploy the application servers in public subnet and db servers in a private subnet(If you do not wish to grant access to the DB server from internet).This Architecture will be easy to manage and all your requirements will be fulfilled with this type of Architecture.
VPC Architecture 2:
I can see that in VPC2, the CIDR block give was 10.0.0.0/20 which gives us ip range from 10.0.0.0 to 10.0.15.255. However, the VPC3 has a CIDR block given as 10.0.2.0/20, which also comes in a same range as of VPC 2 ip addresses. Hence, the Architecture 2 and 3 become same here.I believe, you wanted to show non overlapping CIDR range in VPC 2 and 3. Following my assumption, I would like to inform you that this Architecture can also be used. Customers use this kind of Architecture when they have multiple end customers. And these end customers also want to communicate with each other through VPC peering. VPC peering is possible when the VPC's has non overlapping subnets.
VPC Architecture 3:
This Architecture could also work however, the VPC peering/bridging is not possible in this case.Because, VPC 4 and 5 have same CIDR ip range. Hence, this is not a valid Architecture if you want to make VPC 4 and 5 communicate with each other.
这是很好的信息。