Page Comparison

...

There are three types of VPCs we will be utilizing: Cloud Management VPC, Shard Management VPCs and Shard Service VPCs.  A single Cloud Management VPC holds the centralized cloud management services for the OpenMethods Cloud solution.  Each cloud shard will have a single Shard Management VPC that hosts the common, centralized components that are shared between customers that reside in the shard.  These Shard Management VPCs will share the 10.255.0.0/16 address space.  The first (left to right) three bits of the third byte will be used to indicate which of 8 possible shards the Shard Management VPC belongs to.  The forth bit is used to subnet between the two availability zones used for redundancy.  The remaining address space is used for instances within the VPC and availability zone subnets.  Here’s the table of shard prefixes in binary:

...

The second type of VPC we will use is a Shard Service VPC.  Shard Service VPCs will host the services related to specific customers and the IPSec connectivity needed to communicate with any on premise CTI or data endpoints.  Each shard will have any number of service VPCs distributed around the globe.  Although AWS often provides many data centers (called regions) globally, we will be creating a logical grouping of these AWS regions into larger geographical areas:

• North America
• South America
• EMEA
• APAC
• Oceana
• South America

For example, we consider Canada, US, and Mexico to be a single area called North America, while AWS has multiple regions within this area. To support the multi-dimensional deployments of Service VPCs, we will use a slightly different network addressing scheme.  Each geographical region will have one (or more as we expand) /16 address space used across the service vpcs in that area:

...

As with Shard Management VPCs, Shard Service VPCs belong to a single cloud shard and are not shared.  The ownership of the Service VPC is designated by the first (left to right) three bits of the third byte.  Unlike Core VPCs, the address space needs to be divided up further to allow multiple Service VPCs to be created and to limit the size of the VPC subnets to eliminate customer overlap where possible.  This is handled by using the 4^th through 7^th bits ^th bit of the third octet to identify the Service VPC specifically.  The eighth fifth bit is used to segment off the availability zone subnet space.  Here’s the breakdown of the Shard 1, North American network address space:The full service VPC address space is laid out below with grey rows not being implemented today but may be in the future:

The vast majority of the time there will only be 1 or 2 Service VPCs VPC in a given geographical area associated with a shard.  As with Core VPCs, you’ll be able to tell which geographical region based on the second octet.  The associated shard can be determined by looking at the range of the third octet, 10.254.0.0 – 10.254.31.255 indicates shard 1.  The Service VPC is determined by the sub range, 10.254.0.0 – 10.254.115.255 for Service VPC 1.  The availability zone can be determined by evens high or odds low values of the third octet , even is AZ A which odd is AZ Bwithin the VPC range.

User interaction and design

Create Shard

1. An adminstrator logs in 

Open Questions

...