Discover the design possibilities, both good and bad, of creating multiple VPCs with multiple AWS accounts.
- [Instructor] When we're designing our VPC environment, there are some rules and regulations we want to understand. Number one, the VPCs that we create can span all of the availability zones within the region where we're creating the VPC. This doesn't mean we're going to use all of the availability zones. It means we can. The subnets that we create are also hosted within a specific availability zone. The subnets are also residing within a specific data center in the availability zone. In fact, the EC2 instances are going to be residing on a particular subnet in a particular data center. The traffic from the instance is going to be controlled by a route table that determines where the traffic can flow. So some big picture items on this slide that we need to understand when we're creating VPCs. So how many VPCs since I'm allowed to create a number of them? One? Or two? Here's a couple of reasons why you might want more than one. Let's say you're a developer and you're developing applications. It's a two-tier or a three-tier application. Perhaps you're working on multiple applications. Once you develop them, they go into production. And you've decided to use separate VPCs to isolate the work that you're doing. So multi-VPC design might be based on specific requirements. It might be specific for the application that you're designing. Your stack has to be isolated from any other application stack. Maybe it's a risk factor. Your company has looked at the application that you're designing and they've decided they're going to separate the components out and not place them in the same VPC. Maybe you want to separate production resources from nonproduction resources. Maybe it's a multitenant issue. Maybe the application has to be separated because sharing is not allowed due to compliance. Maybe you're creating a VPC for shared corporate services. Maybe Active Directory and SharePoint is moving to a VPC in the cloud which will be connected to from your on-premise data center. So there's many possibilities as to why you might have more than one VPC. A couple of additional reasons for multiple VPCs aside from the application mix. A VPC has segmentation by default. If I don't give you permission to access a VPC, you're not getting in. Subnet segmentation might not be enough for your existing compliance rules. You might have to place your applications in totally separate VPCs. You also might have a public-facing SaaS application and you want those components to be completely isolated from your private resources. So using dev, test and production VPCs might be a really smart scenario to consider. So how many VPCs should H+ Sports consider? Well, they're going to need two and possibly three VPCs. One for development, one for testing and one for production. The other question that we also have to consider is, how many AZs do we need per VPC? That's kind of an open-ended question depending on is it a two-tier or a three-tier environment?
- Creating a VPC
- Creating subnets
- Default and custom route tables
- IP addressing
- Creating security groups
- Configuring an internet gateway
- Peering VPCs together
- Sharing VPC resources
- Creating flow logs for monitoring
- Controlling access with IAM roles
- Dedicated tenancy
- Using automation for compliance