VPC Architectural Options


In this post I’m going to go into further detail regarding the varying Amazon VPC Architectural Options.  When first deploying VPC it seems similar to a traditional Data Centre, however there are a variety of reasons to consider a multi-VPC strategy. These reasons include:

  • Security
    • Provide security configuration appropriate to VPC, improving overall security posture.
    • De-risk changes by minimizing the blast radius, accelerate deployment of changes.
  • Supportability
    • VPC specific configurations, rather than multiple configurations within a single VPC.
    • Simplifies operational viewpoint based on the segregation.
  • Networking
    • Provides granular network control and integration, only connecct to relevant networks.
    • Leverage multiple VPC constructs effectively, route tables, subnets, NACLs, Peering, DNS.
  • Automation
    • Supports automated deployment of resources into segregated VPCs.
    • VPC can become part of the automation fabric, removing Data Centre mindset.
  • Limits
    • Mitigates limits for very large VPCs, e.g. maximum practical security groups and rule limits.
    • Reduce risk of VPCs constraints, e.g. network, subnet size is fixed at creation time.

There are many viewpoints on the correct approach to segment VPC’s.  These may include:

  • Data Centre Centric
    • Single large private VPC is used, similar to a traditional Data Centre; other VPC constructs provide isolation, e.g. multiple subnets.
  • Information Classification
    • VPCs are segregated based on information classification level, e.g. applications handling information classed as sensitive are deployed within a discreet VPC.
  • Workload or Application
    • VPCs are segregated from based on workload or application to avoid running in shared environment.
  • Environment or Lifecycle
    • Segregation based on Environment type, e.g. Production & Development workloads in separate VPCs, with the same AWS Account.
    • Often this is handled with AWS Account level segmentation.

Design Pattern 1 – Single Large VPC

Design Pattern 1

Design Pattern 1 ProCons

Design Pattern 2 – Multiple VPCs by Classification

Design Pattern 2

Design Pattern 2 ProCons

Design Pattern 3 – Multiple VPCs by Workload

Design Pattern 3

Design Pattern 3 ProCons

Design Pattern 4 – Multiple VPCs by Environment

Design Pattern 4

Design Pattern 4 ProCons

Design Pattern 5 – Multiple VPCs and Account

Design Pattern 5

Design Pattern 5 ProCons

Advanced Enterprise Pattern

The below diagram shows an advanced environment that will leverage multiple design patterns to accommodate different requirements.

Design Pattern 6

Best Practices

  • Security Groups v NACLs
    • Excessive NACL and Security Group use exponentially increases the complexity of a VPC with limited or no benefit.
    • Use Security Groups as much as possible; more dynamic, flexible and easier to understand behaviour.
    • If you need to use NACLs, set some broad rules at the beginning and then leave them alone; don’t use for fine-grained flow control.
    • Too much complexity leads to difficulty of change, which leads to operational instability.
  • VPC
    • Get your VPC architecture right – once you’ve built a VPC, deployed security controls and applications it’s hard to change the base configuration.  Plan your VPC architecture with you’re future needs in mind.
    • Understand VPC limits – subnets cannot be resized, although additional IP space can now be added.  There are recommended limits for efficient security group operation, maximum number of rules per security group and security groups per resource.  Understand them as part of your VPC design process.
    • Use VPCs to isolate resources – choosing the correct VPC isolation technique can support security, governance and operational needs; consider how best to isolate workloads.
    • Use IAM and delegation of duties with VPC – Once a VPC is created there is very little need to perform changes, therefore ensure that IAM is used to restrict access to these rights.
    • Choose your CIDR blocks – too small and you’ll fast run out of IP space within your VPC or not be able to allocate subnets evenly across all availability zones. Too bug and you will waste IP space which cannot be reclaimed without starting from the ground up and migrating resources.
    • Span subnets across all availability zones – make sure that you have sufficient address  space to leverage all the availability zones in a region.
    • Use multiple route table – you can isolate subnets from external networks by associating them with dedicated route tables with no other routes outside of the VPC.
    • Ensure that you correctly assign subnets to the correct route tables to mitigate concerns that internet facing resources also have direct access to internal networks.  You should create a public and private route table, use the default as a catch-all.
    • Have a naming standard –  give everything a clear naming convention in VPC, all constructs support tagging so ensure you have an appropriate scheme to support your operational and automation needs.
    • Use EIP’s and Public IP’s only when needed – if a resource has a route to the internet via an IGW and is deployed in a public subnet then a misconfigured security group could unwittingly allow access from the outside world.  Consider carefully why you are assigning an EIP and if there is an alternative method to gain access to the internet.
    • VPN is good to start, but understand the limitations – you can only allocate one remote VPN endpoint IP (CGW) per VPC, per region.  If you plan to have multiple VPCs then ensure you can provide the required tunnels or consider using a Direct Connect to create multiple tunnels from your network to your VPCs.
    • Use VPC Peering – use VPC peering to route traffic between resources in different VPCs where network communication is required, this allows you to segment and isolate your VPCs and still use VPC security to control traffic.  Use peering to create a shared services VPC common across the organization.
    • Use VPC Flow Logs sparingly – you can control which interfaces are logged using VPC Flow Logs, including the actions which are logged.  Ensure you understand the granularity of this option before you capture data to ensure that you can actually process it in a timely manner.  There is no point trying to respond to a security event 3 day later if you are capturing data for every single interface in a VPC and unable to process it and respond in near-time.

The following patterns interact with on-premises:

Hybrid 3-Tier

Hybrid 3-Tier

Hybrid Shared Services VPC

Hybrid Shared Services VPC

  • Support tools such as Active Directory and anti-virus are replicated from on-premises to the Shared Services VPC.
  • On-site admins proxy connections through bastion servers to configure EC2 instances.

Multiple VPN/Direct Connect VIFs

This design pattern leverages AWS Direct Connect to route traffic between VPCs, and offers customer the ability to incorporate transitive routing.

Multiple VPN and DirectConnect

This option is best suited for customers with the following requirements:

  • They have an existing AWS Direct Connect connection.
  • They can use the AWS Direct Connect connection for transitive routing between VPCs.
  • They need to create more than 100 connections per VPC.

This can also be used to leverage existing on-premises resources, like CI/CD infrastructure for deployments.

Transit VPC

This approach uses customer-managed Amazon EC2 VPN instances in a dedicated transit VPC with an internet gateway.

Transit VPC

This option is best suited for customers with the following requirements:

  • They have already implemented a transit VPC.
  • They want to leverage it to manage more advanced connection types, such as inter-region connectivity, or multi-VPC connectivity to on-premises resources.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s