EBS = Elastic Block Store
i. One of the storage option for EC2 instance.
ii. EBS provides persistent block storage volumes for use with EC2 instances in the AWS cloud. Each EBS volume is automatically replicated within its AZ.
iii. Block storage volume to use with EC2
iv. EBS volume is automatically replicated within its AZ to protect from component failure.
v. Offers high availability and durability
vi. Virtual hard disk in the cloud
EC2 Instance >> EBS >> Volumes, Snapshots and Life cycle manager
General Purpose (SSD) (gp2) Provisioned IOPS (SSD) (iO1) Throughput Optimized Hard Disk Drive (St1) Cold Hard Disk Drive (SC1) Magnetic
Balances price & performance for a wide variety of transactional workloads For fast inputs & outputs per second Physical HDD Magnetic Previous generation HDD
Use case: Most work loads Highest performance SSD volume designed for mission critical applications Its not SSD, its magnetic Lowest cost HDD volume designed for less frequently accessed workloads. Use case: Workloads where data is infrequently accessed
API Name: gp2 Use case: Databases Low cost HDD volume designed for frequently accessed, throughput intensive workloads Use case: File servers API Name: standard
Volume size: 1 GB – 16 TB API Name: iO1 Use case: Big data & data warehouses API Name: Sc1 1GB – 1TB
Max IOPS/ Volume: 16000 4GB – 16TB API Name: St1 500GB – 16TB 40-200
64000 500GB – 16TB 250
i. EBS volume will always be in the same AZ as in EC2 instance. Terminating EC2 instance will delete root EBS volume automatically. While creating an EC2 instance then at Step 4: Add Storage is the step where we create EBS volumes. Default volume type is root with device as /dev/xvda and the EBS volume type is General Purpose SSD (gp2). Delete on termination is checked automatically. On the root device volume OS is installed.
ii. Increase in size means increase the HDD. Also we may need to extend the OS file system on the volume to use any newly allocated.space. We can change volume type or size from one volume type or size to another w/o shutdown or terminate. Ideally EBS volume and EC2 instance remains in same AZ. However we can move EBS root device volume to another AZ.
iii. Snapshot = Photograph of disk. Create snapshot of EBS root device volume. We can create volume or create image from EBS snapshot. In example, created image and use that image to be deployed into another AZ. We can see these images under Images >> AMIs & Bundle Tasks
iv. Select AMI & click on launch >> rest steps follows as creation of EC2 instance. Starts from step 2: Choose an instance type. In step 3: configure instance details, choose different subnet [east-1a]
v. Terminating an EC2 instance will delete root EBS volume but the additional volumes that are attached to EC2 instance still be available. We can delete these additional volumes manually. We can delete snapshots and deregister AMIs manually.
vi. Volumes exist on EBS. EBS is like a virtual HDD in the cloud. Snapshots exists on S3. Think of snapshots as a photograph of the disk. Snapshots are point in time copies of volumes. Snapshots are incremental. This means that only the blocks that have changed since your last snapshot are moved to S3. First snapshot will take time to create. To create a snapshot for EBS volumes that serve as root devices, the best practice is to stop the instance before taking the snapshot. However we can take a snapshot while the instance is running. We can create AMIs from snapshots and volumes.
vii. We can change EBS volume sizes on the fly, including changing the storage type. Volumes will always be in the same AZ as EC2 instance. To move EC2 volume from one AZ to another, take a snapshot it, create an AMI from snapshot and then use the AMI to launch the EC2 instance in a new AZ. To move an EC2 volume from one region to another, take a snaphot of it, create an AMI from the snapshot and then copy the AMI from one region to another then use AMI to launch the EC2 instance in a new region.
viii. Termination protection is turned off by default and we must turn it on explicitly. On the EBS backed instance, the default action is for the root EBS volume to be deleted when the instance is terminated. So if we terminate an EC2 instance the root device volume will be automatically deleted. But if we attach additional volumes to EC2 instance, then those volumes wont be deleted automatically, unless we check that checkbox.
ix. EBS root volumes of default AMIs can be encrypted. We can also use a third party tool like bit locker to encrypt the root volume or this can be done when creating AMIs in AWS console or using API. Additional volumes can also be encrypted. Snapshots of encrypted volumes are encrypted automatically. Volumes restored from encrypted snapshots are encrypted automatically.
A company runs an application on an Amazon EC2 instance the requires 250 GB of storage space. The application is not used often and has small spikes in usage on weekday mornings and afternoons. The disk I/O can vary with peaks hitting a maximum of 3,000 IOPS. A Solutions Architect must recommend the most cost-effective storage solution that delivers the performance required.
Which solution should the solutions architect recommend?
A. Amazon EBS Throughput Optimized HDD (st1)
B. Amazon EBS Provisioned IOPS SSD (io1)
C. Amazon EBS Cold HDD (sc1)
D. Amazon EBS General Purpose SSD (gp2)
General Purpose SSD (gp2) volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time.
Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 16,000 IOPS (at 5,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. AWS designs gp2 volumes to deliver their provisioned performance 99% of the time. A gp2 volume can range in size from 1 GiB to 16 TiB.
In this configuration the volume will provide a baseline performance of 750 IOPS but will always be able to burst to the required 3,000 IOPS during periods of increased traffic.
CORRECT: “Amazon EBS General Purpose SSD (gp2)” is the correct answer.
INCORRECT: “Amazon EBS Provisioned IOPS SSD (i01)” is incorrect. The i01 volume type will be more expensive and is not necessary for the performance levels required.
INCORRECT: “Amazon EBS Cold HDD (sc1)” is incorrect. The sc1 volume type is not going to deliver the performance requirements as it cannot burst to 3,000 IOPS.
INCORRECT: “Amazon EBS Throughput Optimized HDD (st1)” is incorrect. The st1 volume type is not going to deliver the performance requirements as it cannot burst to 3,000 IOPS.
A persistent database must be migrated from an on-premises server to an Amazon EC2 instances. The database requires 64,000 IOPS and, if possible, should be stored on a single Amazon EBS volume.
Which solution should a Solutions Architect recommend?
A. Create an Amazon EC2 instance with four Amazon EBS General Purpose SSD (gp2) volumes attached. Max out the IOPS on each volume and use a RAID 0 stripe set
B. Create a Nitro-based Amazon EC2 instance with an Amazon EBS Provisioned IOPS SSD (i01) volume attached. Provision 64,000 IOPS for the volume
C. Create an Amazon EC2 instance with two Amazon EBS Provisioned IOPS SSD (i01) volumes attached. Provision 32,000 IOPS per volume and create a logical volume using the OS that aggregates the capacity
D. Use an instance from the I3 I/O optimized family and leverage instance store storage to achieve the IOPS requirement
Amazon EC2 Nitro-based systems are not required for this solution but do offer advantages in performance that will help to maximize the usage of the EBS volume. For the data storage volume an i01 volume can support up to 64,000 IOPS so a single volume with sufficient capacity (50 IOPS per GiB) can be deliver the requirements.
CORRECT: “Create a Nitro-based Amazon EC2 instance with an Amazon EBS Provisioned IOPS SSD (i01) volume attached. Provision 64,000 IOPS for the volume” is the correct answer.
INCORRECT: “Use an instance from the I3 I/O optimized family and leverage instance store storage to achieve the IOPS requirement” is incorrect.
INCORRECT: “Create an Amazon EC2 instance with four Amazon EBS General Purpose SSD (gp2) volumes attached. Max out the IOPS on each volume and use a RAID 0 stripe set” is incorrect. This is not a good use case for gp2 volumes. It is much better to use io1 which also meets the requirement of having a single volume with 64,000 IOPS.
INCORRECT: “Create an Amazon EC2 instance with two Amazon EBS Provisioned IOPS SSD (i01) volumes attached. Provision 32,000 IOPS per volume and create a logical volume using the OS that aggregates the capacity” is incorrect. There is no need to create two volumes and aggregate capacity through the OS, the Solutions Architect can simply create a single volume with 64,000 IOPS.
A company plans to make an Amazon EC2 Linux instance unavailable outside of business hours to save costs. The instance is backed by an Amazon EBS volume. There is a requirement that the contents of the instance’s memory must be preserved when it is made unavailable.
How can a solutions architect meet these requirements?
A. Terminate the instance outsode business hours. Recover the instance again when required
B. Stop the instance outside business outs. Start the instance again when required
C. Hibernate the instance outside business hours. Start the instance again when required
D. Use Auto Scaling to scale down the instance oustide of business hours. Scale up the instance when required.
When you hibernate an instance, Amazon EC2 signals the operating system to perform hibernation (suspend-to-disk). Hibernation saves the contents from the instance memory (RAM) to your Amazon Elastic Block Store (Amazon EBS) root volume. Amazon EC2 persists the instance’s EBS root volume and any attached EBS data volumes. When you start your instance:
– The EBS root volume is restored to its previous state
– The RAM contents are reloaded
– The processes that were previously running on the instance are resumed
– Previously attached data volumes are reattached and the instance retains its instance ID
CORRECT: “Hibernate the instance outside business hours. Start the instance again when required” is the correct answer.
INCORRECT: “Stop the instance outside business hours. Start the instance again when required” is incorrect. When an instance is stopped the operating system is shut down and the contents of memory will be lost.
INCORRECT: “Use Auto Scaling to scale down the instance outside of business hours. Scale out the instance when required” is incorrect. Auto Scaling scales does not scale up and down, it scales in by terminating instances and out by launching instances. When scaling out new instances are launched and no state will be available from terminated instances.
INCORRECT: “Terminate the instance outside business hours. Recover the instance again when required” is incorrect. You cannot recover terminated instances, you can recover instances that have become impaired in some circumstances.
A freelance developer has built a Python based web application. The developer would like to upload his code to AWS Cloud and have AWS handle the deployment automatically. He also wants access to the underlying operating system for further enhancements.
As a solutions architect, which of the following AWS services would you recommend for this use-case?
• AWS Elastic Container Service (ECS)
• AWS CloudFormation
• AWS Elastic Beanstalk(Correct)
• Amazon EC2
AWS Elastic Beanstalk
AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS. Simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time. There is no additional charge for Elastic Beanstalk – you pay only for the AWS resources needed to store and run your applications.
AWS CloudFormation – AWS CloudFormation allows you to use programming languages or a simple text file (in YAML or JSON format) to model and provision, in an automated and secure manner, all the resources needed for your applications across all Regions and accounts. Think infrastructure as code; think CloudFormation. This is very different from Beanstalk where you just upload your application code and Beanstalk automatically figures out what resources are required to deploy that application. In CloudFormation, you have to explicitly specify which resources you want to provision.
Amazon EC2 – Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides secure, resizable compute capacity in the cloud, per-second billing, and access to the underlying OS. It is designed to make web-scale cloud computing easier for developers. Maintaining the server and its software has to be done by the customer. EC2 cannot handle the application deployment automatically, so this option is not correct.
AWS Elastic Container Service (ECS) – Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster. ECS cannot handle the application deployment automatically, so this option is not correct.
A big data analytics company is working on a real-time vehicle tracking solution. The data processing workflow involves both I/O intensive and throughput intensive database workloads. The development team needs to store this real-time data in a NoSQL database hosted on an EC2 instance and needs to support up to 25,000 IOPS per volume.
As a solutions architect, which of the following EBS volume types would you recommend for this use-case?
• Provisioned IOPS SSD (io1) (Correct)
• General Purpose SSD (gp2)
• Throughput Optimized HDD (st1)
• Cold HDD (sc1)
Provisioned IOPS SSD (io1)
Provisioned IOPS SSD (io1) is backed by solid-state drives (SSDs) and is a high-performance EBS storage option designed for critical, I/O intensive database and application workloads, as well as throughput-intensive database workloads. io1 is designed to deliver a consistent baseline performance of up to 50 IOPS/GB to a maximum of 64,000 IOPS and provide up to 1,000 MB/s of throughput per volume. Therefore, the io1 volume type would be able to meet the requirement of 25,000 IOPS per volume for the given use-case.
General Purpose SSD (gp2) – gp2 is backed by solid-state drives (SSDs) and is suitable for a broad range of transactional workloads, including dev/test environments, low-latency interactive applications, and boot volumes. It supports max IOPS/Volume of 16,000.
Cold HDD (sc1) – sc1 is backed by hard disk drives (HDDs). It is ideal for less frequently accessed workloads with large, cold datasets. It supports max IOPS/Volume of 250.
Throughput Optimized HDD (st1) – st1 is backed by hard disk drives (HDDs) and is ideal for frequently accessed, throughput-intensive workloads with large datasets and large I/O sizes, such as MapReduce, Kafka, log processing, data warehouse, and ETL workloads. It supports max IOPS/Volume of 500.