Cloud Block Store on AWS Prerequisites

Convertible Reserve Instances (Strongly Recommended)

A Cloud Block Store instance is composed of various underlying AWS resources including EC2 instances. AWS provides customers the option to pay for the EC2 instances on an On-demand basis or through a pre-committed purchase of EC2 instances called Reserved Instances (RI). Paying for On-Demand EC2 instances allows customers to only get charged for the EC2 when it is powered on. It is expensive on a per-hour basis when turned on compared to Reserve Instances. Reserved Instances are heavily discounted and are much more inexpensive per hour, but customers are committed to paying for them regardless if the EC2 instance is powered on or off. Reserved Instances come in two types, Standard RI's and Convertible RIs. Standard RI's provide the most significant discount. Convertible RI's do not have as large of a discount, but offer the flexibility to apply the discount towards other EC2 types. This is important for Cloud Block Store because as AWS releases new EC2 instance types that may be cheaper and/or more powerful, Cloud Block Store can take advantage of them by performing non-disruptive upgrades (NDU) to the underlying EC2 instances. This can provide a better overall performance and cost-effective solution as new EC2 types are released over time. Because of the flexibility that Convertible RI's offer, Pure Storage strongly recommends customers to purchase Convertible RI's for the underlying Cloud Block Store resources. More information can be found on the AWS Reserved Instance page.

Verify EC2 Instance vCPU Limits

You should ensure that your total vCPU maximum limits are sufficient to deploy Cloud Block Store. To view your current limits, go to your Amazon EC2 console.

1. Click on Limits
2. Set the search filter to Running Instances.
3. View the total limits for your A,C,D,H,I,M,R,T,Z instances.

When deploying a Cloud Block Store instance, you have the option to choose the Cloud Block Store instance type. Each Cloud Block Store instance type will use up a certain amount of vCPUs relative to your quota. Each customer’s AWS account has a default max limit for the total vCPUs within each region. Prior to deploying Cloud Block Store resources, ensure that your max limit can accommodate the vCPUs needed for your Cloud Block Store instances . If you need to request an EC2 quota increase, please consult this link for instructions.

The Cloud Block Store minimum vCPUs required for deployments are as follows:
 

Cloud Block Store Type	Total vCPUs required per CBS instance (Initial deployment)	Total vCPUs required per CBS instance (After one capacity upgrade)
//V10-R1	128 (Based on 2 x c5n.9xlarges and 7 x i3.2xlarges)	184 (Based on adding 7 x i3.2xlarges)
//V20-R1	228 (Based on 2 x c5n.18xlarges and 7 x i3en.3xlarges)	312 (Based on adding 7 x i3en.3xlarges)

EC2 Instance Tenancy

During Cloud Block Store deployment, it is required to select the EC2 tenancy of whether to launch CBS controllers on default or dedicated tenancy. 

By default, when an instance is launched with default tenancy it runs on shared instance hardware shared with different AWS accounts. Conversely, if you choose dedicated tenancy during the instance deployment it launches on dedicated instance runs on hardware that's dedicated to a single AWS account. The main drive with this selection is to give flexible billing options, however there are no cost advantages in choosing between both these two tenancy options. If the cost is a concern consider checking Convertible Reserved Instances earlier in this section of the guide.   

Default vs Customer-Managed Keys for Encryption (Optional)

AWS Key Management Service (KMS) is a service that creates and controls the encryption keys used to encrypt your data, it is natively integrated with most of the AWS services. Therefore, CBS is leveraging KMS to encrypt EBS volumes attached to its instance and there are two options that can be specified during the CBS CloudFormation stack deployment.

1. By default, CBS uses regional AWS managed keys. This option requires no configuration prior/during CBS deployment. AWS creates, manages, and uses the KMS keys on your behalf, therefore, you cannot use these keys directly, modify their policies, or rotate them.

2. The other option is to use Customer-managed keys (CMK). With these keys, you have full control over creating, owning, and managing         their policies, rotation, enabling ,and disabling them.  For more information on how to use CMK keys with CBS, please refer to Create Customer-managed encryption keys for Cloud Block Store in AWS. 

Networking Private Subnets

Cloud Block Store deploys with the following four Ethernet interfaces on each controller:

1. System
2. iSCSI
3. Management
4. Replication

During deployment, users will be asked to provide a private subnet for each interface.

• As a security requirement, all subnets for Cloud Block Store must be private subnets.
• It is a recommended best practice that the Cloud Block Store Ethernet interfaces reside on a subnet that is different from the EC2 host initiators. iSCSI traffic between Cloud Block Store and EC2 host initiators can flow using route tables. In most cases, route tables between subnets are set to "local", which allows traffic to flow between subnets in the same Amazon VPC. There are two reasons for this recommendation:
  • Separate subnets minimize the chance that an EC2 host initiator would accidentally use IP addresses belonging to the Cloud Block Store Ethernet interfaces.
  • Cloud Block Store instances will need seven new IP addresses for a capacity upgrade. Placing Cloud Block Store Ethernet interfaces on a separate subnet from EC2 host initiators reduces the chance that the subnet runs out of IP addresses.
• There are two typical network configurations we recommend:
  • The simplest topology is to place all Cloud Block Store interfaces (system, iSCSI, management, replication) onto a dedicated subnet. In this scenario, create a new private subnet with /26 subnet mask (255.255.255.192), which is dedicated to only Cloud Block Store interfaces. See the following network configurations diagram.  This option is recommended for quick testing/POC types of activities rather than production deployment.
  • Cloud Block Store also supports multiple private subnets, one for each Cloud Block Store Ethernet interface type. This network topology offers an optimal solution because it allows traffic isolation. To minimize the chance of having a network overlap, this network topology is recommended when replicating between a Cloud Block Store instance and a FlashArray on-premises (or another Cloud Block Store instance) on a different network via Site-to-Site VPN, VPC Peering, or Transit Gateway. See the following network configurations diagram for an example of this topology.
    • If multiple private subnets are used for Cloud Block Store, they must be all in the same Availability zone.
    • Ensure the private subnet for the System interface has internet access; see the Internet Access section.

Network configuration Options Diagram:

The following table summarizes the requirements for each interface type:

Interface Name	Interface	Subnet Type	Internet Access Required?
System	eth0	Private	Y (port 443)
Replication	eth1	Private	N
iSCSI	eth2	Private	N
Management	eth3	Private	N

Internet Access (Mandatory)

The private subnet for the System interface must have internet access. Internet access ensures that Cloud Block Store can phone home to Pure1 providing logs, alerts, give Pure storage support access and additional cloud management services. The simplest configuration is to route traffic from the System private subnet to a NAT Gateway, which resides in the public subnet.

For additional details on call home port requirements see the Cloud Block Store on AWS Phone Home Requirements.

VPC Endpoint to Amazon S3 and Amazon DynamoDB (Strongly Recommended)

 A Cloud Block Store instance copies all written data to Amazon S3 to ensure high durability. In addition, a Cloud Block Store instance stores metadata information pertaining to the Cloud Block Store configuration in DynamoDB.

It is important to ensure this traffic travels within the AWS network rather than through the public internet. The benefits of VPC Endpoints include:

• VPC Endpoints ensures that data stays within the AWS network which eliminates the dramatic egress costs for sending data to Amazon S3 and Amazon DynamoDB.
• VPC Endpoints for Amazon S3 also prevents additional network hops through the public internet which can significantly improve performance.
• VPC Endpoints is a standard AWS best practice for security reasons.

It is highly advised that customers use VPC Endpoints for Amazon S3 and Amazon DynamoDB. See Appendix A for steps to add an Amazon S3 and Amazon DynamoDB VPC Endpoint to an existing subnet.

VPC DNS Resolution (Mandatory)

Ensure that the Amazon VPC used for Cloud Block Store has DNS resolution enabled. By default, DNS resolution is enabled when an Amazon VPC is created. To view or change the DNS resolution setting for your Amazon VPC, see instruction from AWS.

IP Addresses

Deploying a new Cloud Block Store instance requires 20 initial private IP addresses. For a capacity upgrade, an additional seven private IP addresses are required from the subnet where System interfaces reside. This results in a maximum of 27 IP addresses per V10 or V20 instance. It is recommended that the subnet used for the System interfaces has a network mask of 255.255.255.192 (/26) at minimum. This ensures that there is enough space for capacity expansion.

Replication 

When replicating from an on-premises FlashArray to a Cloud Block Store instance in an Amazon VPC, ensure that there is network connectivity between the respective sites. Likewise, replication between multiple Cloud Block Store instances requires network connectivity between the instances. More specifically, in order to replicate between a Cloud Block Store instance and a physical FlashArray (or another Cloud Block Store instance), the management and replication ports must communicate. Configure all security groups, network ACLs, and routing tables to allow traffic between the two sites for the respective management and replication ports. The following table provides the port number for each interface.

When replicating between a physical datacenter and the Amazon VPC, you can achieve network connectivity a number of ways, including AWS Direct Connect or a Site-to-Site-VPN connection.

For additional details on replication requirements and limits, see the Purity Replication Requirements and Interoperability Matrix.

ActiveCluster - ActiveCluster allows customers to synchronously replicate their Cloud Block Store volumes between two different CBS instances and Availability Zones. This protects customers from a full Availability Zone outage. However, there is no support for ActiveCluster with Cloud Block Store in the Oregon region (us-west-2).  This is because the Pure1 Cloud Mediator for ActiveCluster resides in the same Oregon region, sharing the same physical fault domain.  

In order to use the ActiveCluster feature, it must first be enabled by Pure Storage Support. 

Once ActiveCluster is enabled, steps to configure ActiveCluster can be found in the  ActiveCluster Quick Start Guide.

CloudSnap - For cost-conscious customers who are looking for a lower cost DR alternative to replication, CloudSnap is a viable option. FlashArray customers can use CloudSnap to send snapshots of their volumes to Amazon S3 buckets. The snapshots are self-contained with the meta-data needed to restore onto any other FlashArray or to Cloud Block Store. For the DR use case, customers can periodically send CloudSnap snapshots to Amazon S3. In a DR event where the primary site is inaccessible, customers can deploy a new Cloud Block Store instance on-demand and restore their CloudSnap snapshots. Once the CloudSnap snapshots are fully restored from S3, customers can attach the volumes to the application compute instances in their Amazon VPC to resume application services. This DR alternative provides a lower cost option for customers who have a higher RTO/RPO tolerance. Since volumes are being restored from Amazon S3, the RTO will largely depend on the amount of data that has to be restored. 

Setup and best practices for using CloudSnap with Cloud Block Store can be found at this link.

If you expect to use CloudSnap with Cloud Block Store, ensure you allow https traffic (port 443) on your Replication interface. 

Security Groups

A Cloud Block Store instance has four Ethernet interfaces that are used for the following types of traffic: iSCSI, management, replication, and system intercommunication. Each Ethernet interface requires different types of TCP access.

• As a security best practice, create three different security group as shown in the table below with the appropriate TCP access for the replication, iSCSI, and management interfaces. Each security group will be applied during the Cloud Block Store deployment.
• The security group for the System interface is auto-created during the deployment.
• The three security groups must be in the same region and VPC.

Security Group	Inbound	Outbound
System (eth0*)	Automatically created created upon deployment	Automatically created upon deployment
Replication (eth1)	8117	8117 443 (if using CloudSnap)
iSCSI (eth2)	3260
Management (eth3)	22, 80, 443, 8084	443

IAM Role and Permissions (Mandatory)

To automate a Cloud Block Store deployment, upgrade, or termination, an IAM role with appropriate permissions is required. Even with Administrator permissions elevated, the IAM role is still required. You must create a new IAM policy with the appropriate IAM permissions. Then create the IAM role and attach the IAM policy to your IAM role.

This section provides steps on creating the IAM roles and permissions required to Deploy and Upgrade Cloud Block Store. First, create the permissions policy. Then create the IAM role that is required to launch CBS, and attach the permissions policy to the role.

1. Go to the main IAM console.
2. Create a new policy by selecting Policies and click Create policy.

3. Click the JSON tab. Replace the default content of the JSON file with the following permissions. You can copy/paste the following content directly into the JSON file.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "application-autoscaling:DeleteScalingPolicy",
                "application-autoscaling:DeregisterScalableTarget",
                "application-autoscaling:DescribeScalableTargets",
                "application-autoscaling:DescribeScalingPolicies",
                "application-autoscaling:DescribeScheduledActions",
                "application-autoscaling:PutScalingPolicy",
                "application-autoscaling:RegisterScalableTarget",
                "autoscaling:CreateAutoScalingGroup",
                "autoscaling:CreateLaunchConfiguration",
                "autoscaling:CreateOrUpdateTags",
                "autoscaling:DeleteAutoScalingGroup",
                "autoscaling:DeleteLaunchConfiguration",
                "autoscaling:DeleteTags",
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "autoscaling:PutLifecycleHook",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup",
                "autoscaling:UpdateAutoScalingGroup",
                "dynamodb:CreateTable",
                "dynamodb:DeleteTable",
                "dynamodb:DescribeTable",
                "dynamodb:ListTables",
                "dynamodb:ListTagsOfResource",
                "dynamodb:TagResource",
                "dynamodb:UntagResource",
                "dynamodb:UpdateTable",
                "ec2:AttachNetworkInterface",
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupEgress",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateNetworkInterface",
                "ec2:CreatePlacementGroup",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:CreateLaunchTemplate",
                "ec2:CreateLaunchTemplateVersion",
                "ec2:DeleteLaunchTemplate",
                "ec2:DeleteNetworkInterface",
                "ec2:DeletePlacementGroup",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteTags",
                "ec2:DeleteVolume",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeLaunchTemplates",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribePlacementGroups",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeTags",
                "ec2:DescribeVolumes",
                "ec2:DescribeVolumesModifications",
                "ec2:DescribeVpcs",
                "ec2:DetachNetworkInterface",
                "ec2:ModifyNetworkInterfaceAttribute",
                "ec2:ModifyVolumeAttribute",
                "ec2:ModifyInstanceAttribute",
                "ec2:RevokeSecurityGroupEgress",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:RunInstances",
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:TerminateInstances",
                "iam:AddRoleToInstanceProfile",
                "iam:AttachRolePolicy",
                "iam:CreateInstanceProfile",
                "iam:CreatePolicy",
                "iam:CreateRole",
                "iam:CreateServiceLinkedRole",
                "iam:DeleteInstanceProfile",
                "iam:DeletePolicy",
                "iam:DeleteRole",
                "iam:DeleteRolePolicy",
                "iam:DetachRolePolicy",
                "iam:GetInstanceProfile",
                "iam:GetPolicy",
                "iam:GetRole",
                "iam:GetRolePolicy",
                "iam:ListRoleTags",
                "iam:PassRole",
                "iam:PutRolePolicy",
                "iam:RemoveRoleFromInstanceProfile",
                "iam:SimulatePrincipalPolicy",
                "iam:TagRole",
                "iam:UntagRole",
                "kms:CreateAlias",
                "kms:CreateKey",
                "kms:DeleteAlias",
                "kms:DescribeKey",
                "kms:DisableKey",
                "kms:EnableKey",
                "kms:ListAliases",
                "kms:ListKeyPolicies",
                "kms:ListKeys",
                "kms:ListResourceTags",
                "kms:PutKeyPolicy",
                "kms:ScheduleKeyDeletion",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:UpdateAlias",
                "lambda:CreateFunction",
                "lambda:DeleteFunction",
                "lambda:GetFunction",
                "lambda:GetFunctionConfiguration",
                "lambda:InvokeFunction",
                "lambda:ListTags",
                "lambda:TagResource",
                "lambda:UntagResource",
                "lambda:UpdateFunctionCode",
                "lambda:UpdateFunctionConfiguration",
                "s3:CreateBucket",
                "s3:DeleteBucket",
                "s3:DeleteBucketPolicy",
                "s3:GetBucketPolicy",
                "s3:GetBucketTagging",
                "s3:ListBucket",
                "s3:PutBucketPolicy",
                "s3:PutBucketTagging",
                "s3:PutBucketVersioning",
                "s3:PutMetricsConfiguration",
                "s3:PutBucketPublicAccessBlock",
                "sts:assumerole"
            ],
            "Resource": "*"
        }
    ]
}

4. Click Review Policy.
5. Provide a name for the policy. For example, you can call it PurityServicePermission.
6. Click Create policy.
7. Go back in the main IAM console.
8. Create a role by selecting Roles and click Create role.
9. Select the trusted entity by selecting:
   1. AWS service
   2. CloudFormation

10. Click Next: Permission.
11. In the search box, type the policy name PurityServicePermission created in step 4, and check the box for this policy.

12. Click Next: Tags.
13. (Optional) Add Tag if desired and click Next: Review.
14. Enter the role name PurityServiceRole and click Create role.

This completes the process of creating the PurityServiceRole.

In addition to the PurityServiceRole, another role is needed in order to deploy Cloud Block Store. This role is called AWSServiceRoleForApplicationAutoScaling_DynamoDBTable. Follow the steps below to check whether this role already exists, and to create the role if needed.

1. Log into the AWS Management Console either as a user with full administrative access, or at least as a user with permissions that allow the action iam:CreateServiceLinkedRole on either all resources, or at least on the AWS Service Application Auto Scaling.
    
2. After logging in, go to Identity and Access Management (IAM); and then to Roles; and search for the role AWSServiceRoleForApplicationAutoScaling_DynamoDBTable:

3. If the role already exists, proceed to step #8 below. If this role does not exist, click on Create role to create this role. The following screen will appear:

4. Under Type of trusted entity, select AWS service, and scroll down. From the list of AWS services, select Application Auto Scaling.

5. On the next screen, select Application Auto Scaling – DynamoDB, and click on Next: Permissions.

On the screen above, you should see the message The service-linked role that you selected requires the following policy, and the following policy should be listed under Policy name:

AWSApplicationAutoscalingDynamoDBTablePolicy

6. Click on Next a couple of times, and the following Review screen will appear.

7. Review the information for accuracy, and click on Create role to create the new role.
    
8. After the role has been successfully created, search for the AWSServiceRoleForApplicationAutoScaling_DynamoDBTable role and click on it. Make sure that the AWSApplicationAutoscalingDynamoDBTablePolicy policy is attached to it.
    
9. Click on the policy; then click on Permissions and { } JSON; and make sure that the following permissions exist:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeTable",
                "dynamodb:UpdateTable",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:DescribeAlarms",
                "cloudwatch:DeleteAlarms"
            ],                                                  
            "Resource": "*"
        }
    ]
}

Appendix A