Use the following checklist to prepare for setting up a new Arpio application.
This checklist should be used for Proof of Concept (POC). The Arpio POC is a 10-day sprint where we onboard a workload and demonstrate Arpio’s ability to back up and restore it across AWS accounts and regions.
It may also be used a a general application onboarding checklist.
1. Choose an application
- An application is a set of AWS resources that work together in a single AWS account and region.
- An application may work together with other applications in other AWS accounts and regions as part of an end-to-end workload.
- Arpio will let you configure all the applications you need, but for a given POC we recommend focusing on just one
- POC is a time-boxed exercise. Therefore, for POC we recommend choosing an AWS workload running in a non-production environment, such as staging or test. Onboarding to Arpio will require changes to permissions and resources, and for a POC, these can usually be done more quickly (with less process) in a non-production environment.
- Select a name to use in Arpio to refer to this application.
2. Source AWS account and region
- Make note of the AWS account (12-digit number) and AWS region (e.g. us-east-1, eu-west-2) that the application currently operates in.
- For a POC, if using a non-production instance of your workload you would provide that non-production source information.
3. Recovery AWS account and region
- Determine the AWS account and AWS region where we will recover this application.
- If you choose cross-account recovery, then ideally the recovery account should be an one reserved for application recovery, and not running any other production workloads.
4. CloudFormation to setup source and destination AWS accounts
- To setup this application, you will need to run CloudFormation templates that Arpio will generate for you in the source and recovery AWS environments.
- Ensure you have IAM credentials with authorization to create the AWS resources listed in Appendix A, or use Admin credentials.
- You will need credentials for both the source and recovery environments.
- If you require InfoSec approval or Change Management approval before installing these templates, please ensure you identify the processes to get these approvals. Please schedule time before your POC to work with Arpio to generate the CloudFormation templates, so you have time to get approvals.
- These CloudFormation stacks are used to give Arpio limited access to your AWS accounts, so that it can protect and recover your AWS workloads.
5. IAM credentials to examine and debug source and destination applications
- Ensure you have IAM credentials that you can use to access the AWS console and/or run AWS CLI commands in the source and destination regions.
- Ensure that you have connectivity to these source and recovery environments.
- This is useful to see firsthand how Arpio has recovered your AWS resources, and adjust if necessary.
- The PowerUserAccess AWS managed policy is well suited for this.
6. Identify the key resources of your application
- You will identify the key resources used by your application. Based on this Arpio will not only backup those key resources, but will also identify and backup all other necessary resources for your application.
- [Optional] If you have a tagging strategy to identify the resources that comprise your application, then please note the tag name and value.
7. Personnel
- POC Engineer: Please designate a Cloud Operations Engineer (or similar role) as the primary point of contact for the Arpio POC or onboarding. This person should be familiar with your AWS environment and have the IAM permissions described above.
-
Application Support: Ensure the relevant application team is aware of the POC and has committed to providing support as needed for any app-specific issues that may arise.
-
Security Support: Since adjustments to IAM policies or SCPs are often required, please confirm that someone from your security team will be available to assist as needed.
[Optional] Worksheet
If it is useful to you, please use this worksheet to collect the required information.
Field |
Description |
Your Value |
1 - Application Name |
An internally recognizable name that describes the workload that you’ll be testing for the POC. |
|
2a- Primary AWS Account ID |
In which AWS account do you currently operate this application? |
|
2b - Primary Region |
Which region hosts the core resources? |
|
3a - Recovery AWS Account ID |
Where do you want to recover this application? This should be distinct from the primary account for ransomware resiliency. |
|
3b - Recovery Region |
This should be distinct from the primary region for regional resiliency. |
|
4 - CloudFormation credentials to set up primary and recovery AWS accounts |
Did you obtain all necessary approvals to install the templates? If you are meeting with Arpio staff to run a POC, will someone with access to the necessary credentials to install the templates be at the meeting? |
|
5 - IAM credentials to examine and debug primary and recovery applications |
If you are meeting with Arpio staff to run a POC, will someone with access to these credentials be at the meeting? |
|
6a - Identify the feature resources of your application |
What are the featured compute and storage resources in this application that you will protect and recovery with Arpio. You do not need to list every resource - once you select the key ones, Arpio can figure out the rest. Choose from featured resources to the right. |
Autoscaling Group AWS SFTP (TransferServer) Cognito DocumentDB DynamoDB EC2 that are not in an auto scaling group or node group ECR ECS Cluster EFS EKS Cluster ElastiCache Fargate FSX (which type?) Lambda OpenSearch RDS (non-Aurora) RDS Aurora S3 Spot by Netapp Elastigroup on AWS
|
6b - List any relevant AWS tag names and values |
Arpio can automatically select resources for replication by matching against tag rules in your app settings. This is optional. |
|
7 - Personnel |
POC Engineer Application support Security support |
|
Resource-specific checklists
If you are protecting these specific resource types, then take these steps to make onboarding your Arpio application a smooth experience.
1. Amazon EKS
- If you can do so, set your cluster's authentication mode to API or API_AND_CONFIG_MAP.
- If using API authentication, then ensure you have access to IAM credentials to run aws eks create-access-entry and aws eks associate-access-policy. During initial application setup, you will use these commands to assign the AmazonEKSClusterAdminPolicy access policy to the Arpio Kubernetes delegate IAM role.
- If you want to access EKS resources for validation or debugging via the AWS console or CLI, you will need to access to an IAM principal that has a cluster access policy.
2. Amazon Dynamo DB
- For each DynamoDB table you protect with Arpio you must enable DynamoDB streams with one of the "NEW IMAGE" options selected.
- Enable Advanced DynamoDB backup features in AWS Backup if they are not already enabled on any DynamoDB tables that are included in your Arpio application.
- If your source and recovery environments are in different AWS account, then you should enable cross-account backup for AWS Backup. This must be done in the management account of your AWS Organization.
- If your recovery Region is an AWS opt-in Region, then please configure the Security Token Service (STS) Global Endpoint to be "Valid in all AWS Regions." Instructions here.
3. Amazon EFS and Amazon FSx
- If your source and recovery environments are in different AWS account, then you should enable cross-account backup for AWS Backup. This must be done in the management account of your AWS Organization.
4. ACM certificates
Prior to initiating recovery with Arpio, you must manually provision any certificates you need in Amazon Certificate Manager (ACM). Instructions are here.
5. Amazon EC2 key pairs
The following only applies if you are using EC2 key pairs. If you are using AWS Systems Manager Session Manager or some other means to access your EC2 instances, then you can disregard this section.
Static EC2 instances
For EC2 instances you deploy directly (for example using CloudFormation AWS::EC2::Instance or boto3 create_instances), the key pair is included in the replicated EC2 instance. You can use the same key pair in the recovery environment as you use in the source environment.
Dynamically launched EC2 instances
For EC2 instances that are created by an Auto Scaling Group using an EC2 Launch Template (including those created as part of Amazon EKS and Amazon ECS clusters), you need to create a new key pair in the recovery environment with the same name as the one used in the source environment. This key pair should be in place prior to initiating recovery using Arpio.
Option 1. Let AWS create the separate key pairs
- You can request AWS create a key pair in the recovery environment with the same name as that used in the source environment. This key pair will contain a different private key than the one in the source environment, and you will need to keep track of which key pair you use to access your EC2 instances in the source environment and the recovery environment.
Option 2. Import common key pair
- You can generate your own key pair using ssh-keygen. Then you import this key pair into the source and recovery environments using the same name in AWS. Then, EC2 instances in both the source and recovery environments would use this same key pair.
Appendix A. Permissions to setup source and destination AWS accounts for Arpio
The CloudFormation templates you run in the source and destination AWS accounts will create or update the following resource types:
- AWS::CloudFormation::CustomResource
- AWS::IAM::ManagedPolicy
- AWS::IAM::Policy
- AWS::IAM::Role
- AWS::Lambda::Function
- AWS::Lambda::LayerVersion
- AWS::S3::Bucket
- AWS::Events::EventBus
- AWS::KMS::Alias
- AWS::KMS::Key
The following AWS IAM policy will allow you to deploy the templates:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ArpioTemplates",
"Effect": "Allow",
"Action": [
"lambda:*",
"cloudformation:*",
"iam:*",
"s3:*",
"kms:*",
"events:*"
],
"Resource": "*"
}
]
}