What are best practices for setting up Network & VPC Configurations?

There are many types of configurations our customers have used to setup their Turbot Managed Networks and VPCs. The following summary of best practices and considerations are a summary of guidance given within the following help document: Turbot Managed Network and VPC Configurations Overview. In general, customers consider default patterns to be applied for networks and vpcs to simplify their management across 10s to 100s of accounts. Staying with a consistent default pattern than making exceptions to that pattern provides a more effective flexible model. Few examples:

  • Initial creation of Turbot Managed networks should represent a larger ecosystem of your applications patterns (e.g. all us-east-1 workloads with connectivity to US on-premise).

  • The CIDR range for this network should cover a large range (e.g. /16) that is big enough to associate 10s to 100s of VPCs. It is a balance of covering standard cloud workloads without wasting IP space. However it is a delicate balance between limiting your VPC where you need migrate out to another VPC when your workloads sprawls beyond the subnet size.

  • Consider standard VPC CIDR ranges that can be applied as a default size, than making exceptions for larger or smaller patterns. E.g. a standard VPC CIDR range of a /25 provides two large internal subnets, or 4 appropriate size subnets for 2 Public and 2 Internal subnets. And provides over 500 possible VPCs to be associated in a /16 network.

  • Consider having a minimum 2 subnets per VPC to allow for high available patterns – plus many AWS services depend on at least two subnets.

  • When sizing your VPCs and Subnets, understand the AWS VPC Service Limits. E.g. /28 is the smallest subnet size, and /16 is the largest. However when considering 2 subnets, a /27 is the smallest and /17 is the largest.

    • Note: there are service dependencies that require available IP availablity, e.g. ELBneeds at least 8 available IPs before provisioning.
  • Consider simplifying the initial networking configurations to internal facing applications only, or external facing applications only. Hybrid solutions are possible and often used in Turbot / AWS, however it can add more complexity at the start to consider if they are not the common application pattern.

  • Allowing S3 Endpoints across all VPCs enables quick latency between your VPC to S3. Alternatively having this disabled in an environment with a Direct Connect or VPN would route your S3 traffic from the VPC back through on-premise which would increase latency. Some customers prefer to route all traffic back on-premise for web filtering, however depending on your application patterns there could be justified exceptions considering the latency benefits.

    • Consider using default tenancy for the VPC configuration to allow flexibility for both multi-tenancy and dedicated hardware when needed. Only consider Dedicated Tenancy for the VPC if required by an external regulation (e.g. HIPPA) or internal policies. Otherwise using default tenancy should cover most of the workloads without a dedicated hardware requirement.
  • Enabling VPC peering allows for quick latency between accounts. Although a full mesh peering is only possible up to 125 Active VPC Peers (as of October 10th, 2016).

Was this article helpful?
0 out of 0 found this helpful