HOME / LIBRARY /

How Many VPCs?

Advisory
This analysis of the architecture guidance on the number of production VPCs (Virtual Private Clouds) for services deployed in AWS examines four dimensions: Security, Cost, Operations, and Business Continuity and Disaster Recovery.
 
Authors
  • Scott Bradner (Office of the CTO)
  • Greg Charest (Enterprise Architecture)
Version 1.0
Last Revised 07-Jul-2016
Status Draft
Document Type Single Topic Guidance
Audience Level
  • Strategy Planning and EA Leader
  • Solution Architect and Program Manager

  1. Summary

    Request to revisit existing Cloud architecture guidance on the number of production VPCs for HUIT services deployed in AWS. Specific concern related to support implications of existing quantity of VPCs.

  2. Conclusion

    We did not find specific reasons to recommend that the current number of VPCs in AWS be increased or decreased. In general we concluded that:

    • The number of VPCs should continue to be driven by the support structures of the deployed applications.
    • One VPC should be managed by a single operations support group.
    • Application support groups should have authority to manage only their own applications, regardless of how many applications are deployed in the VPC. If this is not possible then the application should be moved to another VPC.

    These conclusions are in line with the previous Enterprise Architecture work on this topic.

  3. Discussion/Considerations

    The analysis of this question examined the drivers for the number of VPCs along four dimensions: Security, Cost, Operations, and BC/DR.

    Considering the dimension of security, we noted that the planned Harvard-managed physical firewall located near the AWS data centers to front-end Harvard's AWS Internet-facing services will provide the major part of the security and monitoring functions for the Internet-facing services. The operation and cost of this service is not directly related to the number of VPCs. The number of applications within a VPC does impact the granularity of the types of protection the firewall can offer and this would tend to indicate more VPCs with fewer applications in each would be better but there is also increased complexity with additional VPCs. We concluded that these two factors generally canceled each other. Inter-VPC communications are pairwise and also are not directly impacted by the number of VPCs. Our conclusion is that the number of VPCs do not have a significant impact on the security risk or security management of Harvard's AWS services.

    Our assessment of the cost dimension shows that there is no significant correlation of cost to HUIT to the number of deployed VPCs. The AWS model assesses cost based on usage of resources and thus is variable and proportionate to the use of the application. The one current 'fixed' cost, the DirectConnect network link between AWS and on-premise networks, is divided equally across all VPCs, and recalculated periodically to reflect the total VPC count. Thus HUIT-level cost is not a material driver for the number of AWS VPCs. Additional VPCs are not charged for by AWS but if a individual application group requires more than one production VPC their costs will be higher than an application which only requires a single VPC because the DirectConnect costs will be applied individually to each production VPC.

    The assessment of the operational dimension showed the greatest potential for driving the number of VPCs. The key observation is that each VPC needs support structure to manage the binding of the deployed application onto the AWS infrastructure. This organization requires privileged access to resources. In the event that more than one service from different support organizations is deployed into one VPC, there is the inherent risk that one support organization may use privileged means to inadvertently interact with another organization's application. Hence our recommendation that each VPC infrastructure be managed by only one support organization, regardless of how many applications may be deployed in the VPC.

    Lastly, our assessment of the impact of individual application BC/DR designs on the question of the number of VPCs showed low potential for driving application architectures with respect to the number of VPCs. In general, AWS BC/DR capabilities are sufficiently granular that the configurations can be crafted in support of individual applications, or subsets of applications. As such, creation of BC/DR resources is a function of the application architecture and can be considered variable cost extensions to individual application architectures, albeit with a specific purpose.

a54d3b3f70a15a25e8eef64048e10d7f