Your company currently has a 2-tier web application running in an on-premises data center. You have
experienced several infrastructure failures in the past two months resulting in significant financial losses. Your
CIO is strongly agreeing to move the application to AWS. While working on achieving buy-in from the other
company executives, he asks you to develop a disaster recovery plan to help improve Business continuity in the
short term. He specifies a target Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective
(RPO) of 1 hour or less. He also asks you to implement the solution within 2 weeks. Your database is 200GB in
size and you have a 20Mbps Internet connection. How would you do this while minimizing costs?
A.
Create an EBS backed private AMI which includes a fresh install of your application. Develop a
CloudFormation template which includes your AMI and the required EC2, AutoScaling, and ELB resources
to support deploying the application across Multiple- Availability-Zones. Asynchronously replicate
transactions from your on-premises database to a database instance in AWS across a secure VPN
connection.
B.
Deploy your application on EC2 instances within an Auto Scaling group across multiple availability zones.
Asynchronously replicate transactions from your on-premises database to a database instance in AWS
across a secure VPN connection.
C.
Create an EBS backed private AMI which includes a fresh install of your application. Setup a script in your
data center to backup the local database every 1 hour and to encrypt and copy the resulting file to an S3
bucket using multi-part upload.
D.
Install your application on a compute-optimized EC2 instance capable of supporting the application’s
average load. Synchronously replicate transactions from your on-premises database to a database instance
in AWS across a secure Direct Connect connection.
Explanation:
Overview of Creating Amazon EBS-Backed AMIs
First, launch an instance from an AMI that’s similar to the AMI that you’d like to create. You can connect to your
instance and customize it. When the instance is configured correctly, ensure data integrity by stopping the
instance before you create an AMI, then create the image. When you create an Amazon EBS-backed AMI, we
automatically register it for you.Amazon EC2 powers down the instance before creating the AMI to ensure that everything on the instance is
stopped and in a consistent state during the creation process. If you’re confident that your instance is in a
consistent state appropriate for AMI creation, you can tell Amazon EC2 not to power down and reboot the
instance. Some file systems, such as XFS, can freeze and unfreeze activity, making it safe to create the image
without rebooting the instance.
During the AMI-creation process, Amazon EC2 creates snapshots of your instance’s root volume and any other
EBS volumes attached to your instance. If any volumes attached to the instance are encrypted, the new AMI
only launches successfully on instances that support Amazon EBS encryption. For more information, see
Amazon EBS Encryption.
Depending on the size of the volumes, it can take several minutes for the AMI-creation process to complete
(sometimes up to 24 hours).You may find it more efficient to create snapshots of your volumes prior to creating
your AMI. This way, only small, incremental snapshots need to be created when the AMI is created, and the
process completes more quickly (the total time for snapshot creation remains the same). For more information,
see Creating an Amazon EBS Snapshot.
After the process completes, you have a new AMI and snapshot created from the root volume of the instance.
When you launch an instance using the new AMI, we create a new EBS volume for its root volume using the
snapshot. Both the AMI and the snapshot incur charges to your account until you delete them. For more
information, see Deregistering Your AMI.
If you add instance-store volumes or EBS volumes to your instance in addition to the root device volume, the
block device mapping for the new AMI contains information for these volumes, and the block device mappings
for instances that you launch from the new AMI automatically contain information for these volumes. The
instance-store volumes specified in the block device mapping for the new instance are new and don’t contain
any data from the instance store volumes of the instance you used to create the AMI. The data on EBS
volumes persists. For more information, see Block Device Mapping.
A
A