anchor.diff:  This variable is pretty simple.  Greenplum needs at least 8GB of RAM per segment process to work optimally.  More RAM per segment helps with concurrency and also helps hide disk performance deficiencies.  
   
   #### <a id="aws-network"></a>Network
  -AWS provides 25Gbit network performance on the largest instance types.  This alleviates any network bottleneck concerns for large Greenplum clusters in AWS.  Additionally, instance types provide 10Gbit as well as "up to 10Gbit" network performance.  For production workloads, Pivotal requires 10Gbit or better network performance.
  +AWS provides 25Gbit network performance on the largest instance types, but the network is typically not the bottleneck in AWS. The "up to 10Gbit" network is sufficient in AWS.
   
  -Loading network drivers is also required in AWS and depends on the instance type.  Some instance types use an Intel driver while others use an Amazon ENA driver.  Loading the driver requires modifying the machine image (AMI).
  +Installing network drivers in the VM is also required in AWS, and depends on the instance type.  Some instance types use an Intel driver while others use an Amazon ENA driver.  Loading the driver requires modifying the machine image (AMI) to take advantage of the driver.
   
   
   ### <a id="storage"></a>Storage
   
  -#### <a id="aws-ebs"></a>EBS
  -The AWS default disk type is General Performance (GP2) which is ideal for IOP dependent applications.  It has relatively poor performance for throughput.  The operating system and swap volumes are ideal for GP2.  GP2 uses SSD disks and, relative to other disk types in AWS, is expensive.
  +#### <a id="aws-ebs"></a>Elastic Block Storage (EBS)
  +The AWS default disk type is General Performance (GP2) which is ideal for IOP dependent applications. GP2 uses SSD disks and relative to other disk types in AWS, is expensive.  The operating system and swap volumes are ideal for GP2 disks because of the size and higher random I/O needs.
   
  -Throughput Optimized Disks (ST1) is ideal for throughput and thus, ideal for Greenplum.  These disks are based on HDD rather than SSD and are less expensive than GP2.  Performance of ST1 disks is influenced by the disk size and peaks at 12.5TB.  However, the larger instance types have throughput limits that are larger than what a single ST1 disk can provide.  Therefore, up to 4 ST1 disks are needed to reach the throughput limit of a given virtual machine.
  +Throughput Optimized Disks (ST1) are a disk type designed for high throughput needs such as Greenplum.  These disks are based on HDD rather than SSD, and are less expensive than GP2.  Use this disk type for the optimal performance of loading and querying data in AWS.
  +
  +Cold Storage (SC1) provides the best value for EBS storage in AWS.  Using multiple 2TB or larger disks provides enough disk throughput to reach the throughput limit of many different instance types. Therefore, it is possible to reach the throughput limit of a VM by using SC1 disks.
   
   EBS storage is durable so data is not lost when a virtual machine is stopped.  EBS also provides infrastructure snapshot capabilities that can be used to create volume backups.  These snapshots can be copied to different regions to provide a disaster recovery solution.  The Greenplum Cloud utility `gpsnap`, available in the AWS Cloud Marketplace, automates backup, restore, delete, and copy functions using EBS snapshots.
   
  +Storage can be grown in AWS with "gpgrow".  This tool is included with the Greenplum on AWS deployment and allows you to grow the storage independently of compute.  This is an online operation in AWS too.
  +
   #### <a id="aws-ephemeral"></a>Ephemeral
   
  -Ephemeral storage is the last storage option and is available on the Storage Optimized instance types.  These disks are directly attached and have up to 24 2TB disks per virtual machine.  These are the instance types that Redshift uses.
  +Ephemeral Storage is directly attached to VMs, but has many drawbacks:
  +- Data loss when stopping a VM with ephemeral storage
  +- Encryption is not supported
  +- No Snapshots
  +- Same speed can be achieved with EBS storage
  +- Not recommended
   
  -The main problem with Ephemeral storage is the durability.  If you stop a VM with Ephemeral storage, all data is lost.  The second problem is the number of disks.  There are more disks (24) than Greenplum can have segments per host.  Therefore, software RAID is needed to match the number of mounts to the number of segments.  Note that mount options for software RAID can greatly impact performance.
  +#### <a id="aws-recommend"></a>AWS Recommendations
   
  -Instance types that have Ephemeral storage also are more expensive than Instance types that do not.  You have to balance the cost of compute plus storage to determine which is the best for a particular use case.
  +##### Master
  +| Instance Type | Memory | vCPUs | Data Disks |
  +| ------------- | ------ | ----- | ---------- |
  +| r5.xlarge     | 32     | 4     | 1          |
  +| r5.2xlarge    | 64     | 8     | 1          |
  +| r5.4xlarge    | 128    | 16    | 1          |
   
  -#### <a id="aws-ebs-vs-ephemeral"></a>EBS vs Ephemeral
  +##### Segments
  +| Instance Type | Memory | vCPUs | Data Disks |
  +| ------------- | ------ | ----- | ---------- |
  +| r5.4xlarge    | 128    | 16    | 3          |
   
  -Performance testing has found that there is virtually no performance difference for Greenplum when comparing EBS vs Ephemeral storage.   Therefore, Pivotal recommends using EBS storage so that the disks are durable and disk snapshots can be used for backup and disaster recovery.
  +Performance testing has indicated that the Master node can be deployed on the smallest r5.xlarge instance type to save money without a measurable difference in performance.  Testing was performed using the TPC-DS benchmark.
   
  -### <a id="aws-recommend"></a>AWS Recommendations
  -#### R5 Series
  -
  -| Instance Type | Storage Type  | Storage Size | Memory | vCPUs | Network Speed | Use                           |
  -|---------------|---------------|------------|--------|------|---------------|-------------------------------|
  -| r5.xlarge     | EBS           | 6TB          | 32     | 4     | Up to 10GBit  | Dev/Test                      |
  -| r5.xlarge     | EBS Encrypted | 6TB          | 32     | 4     | Up to 10GBit  | Dev/Test                      |
  -| r5.2xlarge    | EBS           | 12TB         | 64     | 8     | Up to 10GBit  | Dev/Test                      |
  -| r5.2xlarge    | EBS Encrypted | 12TB         | 64     | 8     | Up to 10GBit  | Dev/Test                      |
  -| r5.4xlarge    | EBS           | 24TB         | 128    | 16    | Up to 10GBit  | Dev/Test                      |
  -| r5.4xlarge    | EBS Encrypted | 24TB         | 128    | 16    | Up to 10GBit  | Dev/Test                      |
  -| r5.12xlarge   | EBS           | 48TB         | 384    | 48    | 10GBit        | Production                    |
  -| r5.12xlarge   | EBS Encrypted | 48TB         | 384    | 48    | 10GBit        | Production                    |
  -| r5.24xlarge   | EBS           | 48TB         | 768    | 96    | 25GBit        | Production - High Concurrency |
  -| r5.24xlarge   | EBS Encrypted | 48TB         | 768    | 96    | 25GBit        | Production - High Concurrency |
  -
  -#### R4 Series
  -
  -| Instance Type | Storage Type  | Storage Size | Memory | vCPUs | Network Speed | Use                           |
  -|---------------|---------------|--------------|--------|-------|---------------|-------------------------------|
  -| r4.xlarge     | EBS           | 6TB          | 30.5   | 4     | Up to 10GBit  | Dev/Test                      |
  -| r4.xlarge     | EBS Encrypted | 6TB          | 30.5   | 4     | Up to 10GBit  | Dev/Test                      |
  -| r4.2xlarge    | EBS           | 12TB         | 61     | 8     | Up to 10GBit  | Dev/Test                      |
  -| r4.2xlarge    | EBS Encrypted | 12TB         | 61     | 8     | Up to 10GBit  | Dev/Test                      |
  -| r4.4xlarge    | EBS           | 24TB         | 122    | 16    | Up to 10GBit  | Dev/Test                      |
  -| r4.4xlarge    | EBS Encrypted | 24TB         | 122    | 16    | Up to 10GBit  | Dev Test                      |
  -| r4.8xlarge    | EBS           | 48TB         | 244    | 32    | 10GBit        | Production                    |
  -| r4.8xlarge    | EBS Encrypted | 48TB         | 244    | 32    | 10GBit        | Production                    |
  -| r4.16xlarge   | EBS           | 48TB         | 488    | 64    | 25GBit        | Production - High Concurrency |
  -| r4.16xlarge   | EBS Encrypted | 48TB         | 488    | 64    | 25GBit        | Production - High Concurrency |
  -
  -#### D2 Series
  -
  -Storage Optimized instances with local HDD ephemeral storage that is optimized for throughput.  Ephemeral storage is lost if the nodes are stopped.  
  -
  --  Does not support snapshot backups using the Greenplum Cloud `gpsnap` utility
  --  Data loss when nodes are stopped
  -
  -| Instance Type | Storage Type | Storage Size | Memory | vCPUs | Network Speed | Use        |
  -|---------------|--------------|--------------|--------|-------|---------------|------------|
  -| d2.xlarge     | Ephemeral    | 6TB          | 30.5   | 4     | Moderate      | Dev/Test   |
  -| d2.2xlarge    | Ephemeral    | 12TB         | 61     | 8     | High          | Dev/Test   |
  -| d2.4xlarge    | Ephemeral    | 24TB         | 122    | 16    | High          | Dev/Test   |
  -| d2.8xlarge    | Ephemeral    | 48TB         | 244    | 36    | 10GBit        | Production |
  +The Segment instances run optimally on the r5.4xlarge instance type.  This provides the highest performance given the cost of the AWS resources.
   
   ## <a id="gcp"></a>Google Compute Platform (GCP)
   
  
positive.code: net.ipv4.ip_local_reserved_ports=65330
  ```
  
  AWS requires loading network drivers and also altering the AMI to use the faster networking capabilities.  More information on this is provided in the AWS documentation.
  
  ## <a id="cd-storage"></a>Storage
  
  
negative.code: 
  The HighMem instance type is slightly faster for higher concurrency.  Furthermore, SSD disks are slightly faster also but come at a cost.
  
  ##### Master and Segment Instances
  | Instance Type | Memory | vCPUs | Data Disks |
  | ------------- | ------ | ----- | ---------- |
  | n1-standard-8 | 30     | 8     | 1          |
  | n1-highmem-8  | 52     | 8     | 1          |
  
  ## <a id="azure"></a>Azure
  
  