AWS EC2 Instance Store Storage

Overview

  • An instance store provides temporary block-level storage for an EC2 instance.
  • Instance store storage is located on the disks that are physically attached to the host computer.
  • Instance store is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content, or for data that is replicated across a fleet of instances, such as a load-balanced pool of web servers.
  • An instance store consists of one or more instance store volumes exposed as block devices.
  • Size of an instance store varies by instance type.
  • Virtual devices for instance store volumes are ephemeral[0-23], starting the first one as ephemeral0 and so on.
  • While an instance store is dedicated to a particular instance, the disk subsystem is shared among instances on a host computer.

Instance Store Lifecycle

  • Instance store data lifetime is dependent on the lifecycle of the Instance to which it is attached
  • Data on the Instance store persists when an instance is rebooted
  • However, the data on the instance store does not persists if the
    • underlying disk drive fails
    • instance stops i.e. if the EBS backed instance with instance store volumes attached is stopped
    • instance terminates
  • If an AMI is created from an Instance with Instance strore volume, the data on its instance store volume isn’t preserved

Instance Store Volumes

  • Instance type of an instance determines the size of the instance store available for the instance, and the type of hardware used for the instance store volumes
  • Instance store volumes are included as part of the instance’s hourly cost.
  • Some instance types use solid state drives (SSD) to deliver very high random I/O performance, which is a good option when storage with very low latency is needed, but the data does not need to be persisted when the instance terminates or you can take advantage of fault tolerant architectures.

Instance Store Volumes with EC2 instances

  • EBS volumes and instance store volumes for an instance are specified using a block device mapping
  • Instance store volume can be attached to an EC2 instance only when the instance is launched
  • Instance store volume cannot be detached and reattached to a different instance
  • After an instance is launched, the instance store volumes for the instance should be formatted and mounted before it can be used.
  • Root volume of an instance store-backed instance is mounted automatically.

Instance Store Optimizing Writes

  • Because of the way that Amazon EC2 virtualizes disks, the first write to any location on an instance store volume performs more slowly than subsequent writes.
  • Amortizing (gradually writing off) this cost over the lifetime of the instance might be acceptable.
  • However, if high disk performance is required, AWS recommends initializing the drives by writing once to every drive location before production use

Sample Exam Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Please select the most correct answer regarding the persistence of the Amazon Instance Store
    1. The data on an instance store volume persists only during the life of the associated Amazon EC2 instance
    2. The data on an instance store volume is lost when the security group rule of the associated instance is changed.
    3. The data on an instance store volume persists even after associated Amazon EC2 instance is deleted
  2. A user has launched an EC2 instance from an instance store backed AMI. The user has attached an additional instance store volume to the instance. The user wants to create an AMI from the running instance. Will the AMI have the additional instance store volume data?
    1. Yes, the block device mapping will have information about the additional instance store volume
    2. No, since the instance store backed AMI can have only the root volume bundled
    3. It is not possible to attach an additional instance store volume to the existing instance store backed AMI instance
    4. No, since this is ephemeral storage it will not be a part of the AMI
  3. When an EC2 instance that is backed by an S3-based AMI Is terminated, what happens to the data on the root volume?
    1. Data is automatically saved as an EBS volume.
    2. Data is automatically saved as an EBS snapshot.
    3. Data is automatically deleted
    4. Data is unavailable until the instance is restarted.
  4. A user has launched an EC2 instance from an instance store backed AMI. If the user restarts the instance, what will happen to the ephemeral storage data?
    1. All the data will be erased but the ephemeral storage will stay connected
    2. All data will be erased and the ephemeral storage is released
    3. It is not possible to restart an instance launched from an instance store backed AMI
    4. The data is preserved
  5. When an EC2 EBS-backed instance is stopped, what happens to the data on any ephemeral store volumes?
    1. Data will be deleted and will no longer be accessible
    2. Data is automatically saved in an EBS volume.
    3. Data is automatically saved as an EBS snapshot
    4. Data is unavailable until the instance is restarted
  6. A user has launched an EC2 Windows instance from an instance store backed AMI. The user has also set the Instance initiated shutdown behavior to stop. What will happen when the user shuts down the OS?
    1. It will not allow the user to shutdown the OS when the shutdown behavior is set to Stop
    2. It is not possible to set the termination behavior to Stop for an Instance store backed AMI instance
    3. The instance will stay running but the OS will be shutdown
    4. The instance will be terminated
  7. Which of the following will occur when an EC2 instance in a VPC (Virtual Private Cloud) with an associated Elastic IP is stopped and started? (Choose 2 answers)
    1. The Elastic IP will be dissociated from the instance
    2. All data on instance-store devices will be lost
    3. All data on EBS (Elastic Block Store) devices will be lost
    4. The ENI (Elastic Network Interface) is detached
    5. The underlying host for the instance is changed

References

AWS Elastic Block Store Storage – EBS – Certification

EC2 Elastic Block Storage – EBS Overview

  • Amazon EBS provides highly available, reliable, durable, block-level storage volumes that can be attached to a running instance
  • EBS as a primary storage device is recommended for data that requires frequent and granular updates for e.g. running a database or filesystems
  • An EBS volume behaves like a raw, unformatted, external block device that can be attached to a single EC2 instance at a time
  • EBS volume persists independently from the running life of an instance.
  • An EBS volume can be attached to any instance within the same Availability Zone, and can be used like any other physical hard drive.
  • EBS volumes allows encryption using the Amazon EBS encryption feature. All data stored at rest, disk I/O, and snapshots created from the volume are encrypted. Encryption occurs on the EC2 instance, providing encryption of data-in-transit from EC2 to the EBS volume
  • EBS volumes can be backed up by creating a snapshot of the volume, which is stored in Amazon S3.  EBS volumes can be created from a snapshot can be attached to an another instance within the same region
  • EBS volumes are created in a specific Availability Zone, and can then be attached to any instances in that same Availability Zone. To make a volume available outside of the Availability Zone, create a snapshot and restore that snapshot to a new volume anywhere in that region
  • Snapshots can also be copied to other regions and then restored to new volumes, making it easier to leverage multiple AWS regions for geographical expansion, data center migration, and disaster recovery.
  • EBS Magnetic volumes can be created from 1 GiB to 1 TiB in size; EBS General Purpose (SSD) and Provisioned IOPS (SSD) volumes can be created up to 16 TiB in size
  • General Purpose (SSD) volumes support up to 10,000 IOPS and 160 MB/s of throughput and Provisioned IOPS (SSD) volumes support up to 20,000 IOPS and 320 MB/s of throughput.

Benefits

  • Data Availability
    • EBS volume is automatically replicated in an Availability Zone to prevent data loss due to failure of any single hardware component.
  • Data Persistence
    • EBS volume persists independently of the running life of an EC2 instance
    • EBS volume persists when an instance is stopped and started or rebooted
    • Root EBS volume is deleted, by default, on Instance termination but can be modified by changing the DeleteOnTermination flag
    • All attached volumes persist, by default, on instance termination
  • Data Encryption
    • EBS volumes can be encrypted by EBS encryption feature
    • EBS encryption uses 256-bit Advanced Encryption Standard algorithms (AES-256) and an Amazon-managed key infrastructure.
    • Encryption occurs on the server that hosts the EC2 instance, providing encryption of data-in-transit from the EC2 instance to EBS storage
    • Snapshots of encrypted EBS volumes are automatically encrypted.
  • Snapshots
    • EBS provides the ability to create snapshots (backups) of any EBS volume and write a copy of the data in the volume to Amazon S3, where it is stored redundantly in multiple Availability Zones
    • Snapshots can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones
    • Snapshots are incremental backups and store only the data that was changed from the time the last snapshot was taken.
    • Snapshots size can probably be smaller then the volume size as the data is compressed before being saved to S3
    • Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.

EBS Volume

EBS Volume Types

Refer to My Blog Post about EBS Volume Types

EBS Volume Creation

  • EBS volume can be created either
    • Creating New volumes
      • Completely new from console or command line tools and can then be attached to an EC2 instance in the same Availability Zone
    • Restore volume from Snapshots
      • EBS volumes can also be restored from a previously created snapshots
      • New volumes created from existing EBS snapshots load lazily in the background.
      • There is no need to wait for all of the data to transfer from S3 to the EBS volume before the attached instance can start accessing the volume and all its data.
      • If the instance accesses the data that hasn’t yet been loaded, the volume immediately downloads the requested data from Amazon S3, and continues loading the rest of the data in the background.
      • EBS volumes restored from encrypted snapshots are encrypted by default
    • EBS volumes can be created and attached to a running EC2 instance by specifying a block device mapping

EBS Volume Detachment

  • EBS volumes can be detached from an instance explicitly or by terminating the instance
  • EBS root volumes can be detached by stopping the instance
  • EBS data volumes, attached to an running instance, can be detached by unmounting the volume from the instance first. If the volume is detached without being unmounted, it might result the volume being stuck in the busy state and could possibly damaged the file system or the data it contains
  • EBS volume can be force detached from an instance, using the Force Detach option, but it might lead to data loss or a corrupted file system as the instance does not get an opportunity to flush file system caches or file system metadata
  • Charges are still incurred for the volume after its detachment

EBS Volume Deletion

  • EBS volume deletion would wipe out its data and the volume can’t be attached to any instance. However, it can be backed up before deletion using EBS snapshots

EBS Volume Snapshots

Refer to My Blog Post about EBS Snapshot

EBS Encryption

  • EBS volumes can be created and attached to a supported instance type, and supports following types of data
    • Data at rest
    • All snapshots created from the volume
    • All disk I/O
  • Encryption occurs on the servers that host EC2 instances, providing encryption of data-in-transit from EC2 instances to EBS storage.
  • EBS encryption is supported with all EBS volume types (gp2, io1 and standard), and has the same IOPS performance on encrypted volumes as with unencrypted volumes, with a minimal effect on latency
  • EBS encryption is only available on select instance types
  • Snapshots of encrypted volumes and volumes created from encrypted snapshots are automatically encrypted using the same volume encryption key
  • EBS encryption uses AWS Key Management Service (AWS KMS) customer master keys (CMK) when creating encrypted volumes and any snapshots created from the encrypted volumes.
  • EBS volumes can be encrypted using either
    • a default CMK is created for you automatically.
    • a CMK that you created separately using AWS KMS, giving you more flexibility, including the ability to create, rotate, disable, define access controls, and audit the encryption keys used to protect your data.
  • Public or shared snapshots of encrypted volumes are not supported, because other accounts would be able to decrypt your data and needs to be migrated to an unencrypted status before sharing.
  • Existing unencrypted volumes cannot be encrypted directly, but can be migrated by
    • create a unencrypted snapshot from the volume
    • create an encrypted copy of unencrypted snapshot
    • create an encrypted volume from the encrypted snapshot
  • Encrypted snapshot can be created from a unencrypted snapshot by create an encrypted copy of the unencrypted snapshot
  • Unencrypted volume cannot be created from an encrypted volume directly but needs to be migrated

EBS Performance

Refer to My Blog Post about EBS Performance

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. _____ is a durable, block-level storage volume that you can attach to a single, running Amazon EC2 instance.
    1. Amazon S3
    2. Amazon EBS
    3. None of these
    4. All of these
  2. Which Amazon storage do you think is the best for my database-style applications that frequently encounter many random reads and writes across the dataset?
    1. None of these.
    2. Amazon Instance Storage
    3. Any of these
    4. Amazon EBS
  3. What does Amazon EBS stand for?
    1. Elastic Block Storage
    2. Elastic Business Server
    3. Elastic Blade Server
    4. Elastic Block Store
  4. Which Amazon Storage behaves like raw, unformatted, external block devices that you can attach to your instances?
    1. None of these.
    2. Amazon Instance Storage
    3. Amazon EBS
    4. All of these
  5. A user has created numerous EBS volumes. What is the general limit for each AWS account for the maximum number of EBS volumes that can be created?
    1. 10000
    2. 5000
    3. 100
    4. 1000
  6. Select the correct set of steps for exposing the snapshot only to specific AWS accounts
    1. Select Public for all the accounts and check mark those accounts with whom you want to expose the snapshots and click save.
    2. Select Private and enter the IDs of those AWS accounts, and click Save.
    3. Select Public, enter the IDs of those AWS accounts, and click Save.
    4. Select Public, mark the IDs of those AWS accounts as private, and click Save.
  7. If an Amazon EBS volume is the root device of an instance, can I detach it without stopping the instance?
    1. Yes but only if Windows instance
    2. No
    3. Yes
    4. Yes but only if a Linux instance
  8. Can we attach an EBS volume to more than one EC2 instance at the same time?
    1. Yes
    2. No
    3. Only EC2-optimized EBS volumes.
    4. Only in read mode.
  9. Do the Amazon EBS volumes persist independently from the running life of an Amazon EC2 instance?
    1. Only if instructed to when created
    2. Yes
    3. No
  10. Can I delete a snapshot of the root device of an EBS volume used by a registered AMI?
    1. Only via API
    2. Only via Console
    3. Yes
    4. No
  11. By default, EBS volumes that are created and attached to an instance at launch are deleted when that instance is terminated. You can modify this behavior by changing the value of the flag_____ to false when you launch the instance
    1. DeleteOnTermination
    2. RemoveOnDeletion
    3. RemoveOnTermination
    4. TerminateOnDeletion
  12. Your company policies require encryption of sensitive data at rest. You are considering the possible options for protecting data while storing it at rest on an EBS data volume, attached to an EC2 instance. Which of these options would allow you to encrypt your data at rest? (Choose 3 answers)
    1. Implement third party volume encryption tools
    2. Do nothing as EBS volumes are encrypted by default
    3. Encrypt data inside your applications before storing it on EBS
    4. Encrypt data using native data encryption drivers at the file system level
    5. Implement SSL/TLS for all services running on the server
  13. Which of the following are true regarding encrypted Amazon Elastic Block Store (EBS) volumes? Choose 2 answers
    1. Supported on all Amazon EBS volume types
    2. Snapshots are automatically encrypted
    3. Available to all instance types
    4. Existing volumes can be encrypted
    5. Shared volumes can be encrypted
  14. How can you secure data at rest on an EBS volume?
    1. Encrypt the volume using the S3 server-side encryption service
    2. Attach the volume to an instance using EC2’s SSL interface.
    3. Create an IAM policy that restricts read and write access to the volume.
    4. Write the data randomly instead of sequentially.
    5. Use an encrypted file system on top of the EBS volume
  15. A user has deployed an application on an EBS backed EC2 instance. For a better performance of application, it requires dedicated EC2 to EBS traffic. How can the user achieve this?
    1. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    2. Launch the EC2 instance as EBS enhanced with PIOPS EBS
    3. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    4. Launch the EC2 instance as EBS optimized with PIOPS EBS
  16. A user is trying to launch an EBS backed EC2 instance under free usage. The user wants to achieve encryption of the EBS volume. How can the user encrypt the data at rest?
    1. Use AWS EBS encryption to encrypt the data at rest (Encryption is allowed on micro instances)
    2. User cannot use EBS encryption and has to encrypt the data manually or using a third party tool (Encryption was not allowed on micro instances before)
    3. The user has to select the encryption enabled flag while launching the EC2 instance
    4. Encryption of volume is not available as a part of the free usage tier
  17. A user is planning to schedule a backup for an EBS volume. The user wants security of the snapshot data. How can the user achieve data encryption with a snapshot?
    1. Use encrypted EBS volumes so that the snapshot will be encrypted by AWS
    2. While creating a snapshot select the snapshot with encryption
    3. By default the snapshot is encrypted by AWS
    4. Enable server side encryption for the snapshot using S3
  18. A user has launched an EBS backed EC2 instance. The user has rebooted the instance. Which of the below mentioned statements is not true with respect to the reboot action?
    1. The private and public address remains the same
    2. The Elastic IP remains associated with the instance
    3. The volume is preserved
    4. The instance runs on a new host computer
  19. A user has launched an EBS backed EC2 instance. What will be the difference while performing the restart or stop/start options on that instance?
    1. For restart it does not charge for an extra hour, while every stop/start it will be charged as a separate hour
    2. Every restart is charged by AWS as a separate hour, while multiple start/stop actions during a single hour will be counted as a single hour
    3. For every restart or start/stop it will be charged as a separate hour
    4. For restart it charges extra only once, while for every stop/start it will be charged as a separate hour
  20. A user has launched an EBS backed instance. The user started the instance at 9 AM in the morning. Between 9 AM to 10 AM, the user is testing some script. Thus, he stopped the instance twice and restarted it. In the same hour the user rebooted the instance once. For how many instance hours will AWS charge the user?
    1. 3 hours
    2. 4 hours
    3. 2 hours
    4. 1 hour
  21. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  22. An organization wants to move to Cloud. They are looking for a secure encrypted database storage option. Which of the below mentioned AWS functionalities helps them to achieve this?
    1. AWS MFA with EBS
    2. AWS EBS encryption
    3. Multi-tier encryption with Redshift
    4. AWS S3 server-side storage
  23. A user has stored data on an encrypted EBS volume. The user wants to share the data with his friend’s AWS account. How can user achieve this?
    1. Create an AMI from the volume and share the AMI
    2. Copy the data to an unencrypted volume and then share
    3. Take a snapshot and share the snapshot with a friend
    4. If both the accounts are using the same encryption key then the user can share the volume directly
  24. A user is using an EBS backed instance. Which of the below mentioned statements is true?
    1. The user will be charged for volume and instance only when the instance is running
    2. The user will be charged for the volume even if the instance is stopped
    3. The user will be charged only for the instance running cost
    4. The user will not be charged for the volume if the instance is stopped
  25. A user is planning to use EBS for his DB requirement. The user already has an EC2 instance running in the VPC private subnet. How can the user attach the EBS volume to a running instance?
    1. The user must create EBS within the same VPC and then attach it to a running instance.
    2. The user can create EBS in the same zone as the subnet of instance and attach that EBS to instance. (Should be in the same AZ)
    3. It is not possible to attach an EBS to an instance running in VPC until the instance is stopped.
    4. The user can specify the same subnet while creating EBS and then attach it to a running instance.
  26. A user is creating an EBS volume. He asks for your advice. Which advice mentioned below should you not give to the user for creating an EBS volume?
    1. Take the snapshot of the volume when the instance is stopped
    2. Stripe multiple volumes attached to the same instance
    3. Create an AMI from the attached volume (AMI is created from the snapshot)
    4. Attach multiple volumes to the same instance
  27. An EC2 instance has one additional EBS volume attached to it. How can a user attach the same volume to another running instance in the same AZ?
    1. Terminate the first instance and only then attach to the new instance
    2. Attach the volume as read only to the second instance
    3. Detach the volume first and attach to new instance
    4. No need to detach. Just select the volume and attach it to the new instance, it will take care of mapping internally
  28. What is the scope of an EBS volume?
    1. VPC
    2. Region
    3. Placement Group
    4. Availability Zone

AWS EC2 EBS Monitoring

EBS Monitoring

Amazon Web Services (AWS) support EBS monitoring by automatically providing data, such as Amazon CloudWatch metrics and volume status checks to help monitor EBS volumes

CloudWatch Monitoring

  • CloudWatch metrics are statistical data that you can use to view, analyze, and set alarms on the operational behavior of the EBS volumes
  • CloudWatch provides the below by default
    • Basic – Data, in 5-minute periods at no charge, which includes data from the root devices volumes for EBS backed instances
    • Detailed – Provisioned IOPS (SSD) volumes send one-minute metrics
  • EBS Metrics
    • VolumeReadBytes & VolumeWriteBytes
      • Provides information on the I/O operations in a specified period of time, in bytes
    • VolumeReadOps & VolumeWriteOps
      • Total number (count) of I/O operations in a specified period of time
    • VolumeTotalReadTime & VolumeTotalWriteTime
      • Total number of seconds spent by all operations that completed in a specified period of time
    • VolumeIdleTime
      • Total number of seconds, in a specific period, when the volume was idle (no read and write operations)
    • VolumeQueueLength
      • Number of read and write operations, in a specific period, waiting to be completed
    • VolumeThroughputPercentage (Provisioned IOPS (SSD) volumes only)
      • Percentage of I/O operations per second (IOPS) delivered of the total IOPS provisioned
    • VolumeConsumedReadWriteOps (Provisioned IOPS (SSD) volumes only)
      • Total amount of read and write operations (normalized to 256K capacity units) consumed in a specified period of time

Volume Status Checks Monitoring

EC2 EBS Volume Status Check Monitoring

  • Volume status checks are automated tests that run every 5 minutes and return a pass or fail status.
  • Volume check status
    • Ok – all the status checks passed
    • Imparied – if the status checks failed
    • Insufficient-Data – checks are still in progress
    • Warning – the I/O performance of the volume is below expectations
  • When Amazon EBS determines the volume’s data is potentially inconsistent, it disables the I/O to the EBS volume from the attached EC2 instance to prevent any data corruption. This leads to the status check to fail and the volume status to be impaired. Amazon waits for the I/O to be enabled, giving you an opportunity to perform consistency checks
  • If the auto disabling of I/O is not needed, it can be overridden by enabling the Auto-Enabled IO flag, which would make the EBS volume auto available immediately after impaired status
  • Events would be fire for notification whenever the I/O for an EBS volume is disabled
  • I/O performance status checks, applicable only for Provisioned IOPS (SSD) volumes, compares actual volume performance with the expected volume performance and alerts if performing below expectations. This status check is performed every 1 minutes, however is collected by CloudWatch every 5 mins.
  • While initializing Provisioned IOPS (SSD) volumes that were restored from snapshots, the performance of the volume may drop below 50 percent of its expected level, which causes the volume to display a warning state in the I/O Performance status check. This is expected and can be ignored.

EC2 EBS Volume Status

Volume Events Monitoring

  • Amazon EBS generates events for volume status checks
  • Each event includes a start time that indicates the time at which the event occurred, and a duration that indicates how long I/O for the volume was disabled
  • Events description can be Awaiting Action (to enabled I/O), IO enabled, IO Auto-Enabled, or whether the status check resulted in Normal, Degraded, Severely Degraded or stalled status

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has configured CloudWatch monitoring on an EBS backed EC2 instance. If the user has not attached any additional device, which of the below mentioned metrics will always show a 0 value?
    1. DiskReadBytes
    2. NetworkIn
    3. NetworkOut
    4. CPUUtilization
  2. What does it mean if you have zero IOPS and a non-empty I/O queue for all EBS volumes attached to a running EC2 instance?
    1. The I/O queue is buffer flushing.
    2. Your EBS disk head(s) is/are seeking magnetic stripes.
    3. The EBS volume is unavailable. (EBS volumes are unavailable when all of the attached volumes perform zero read write IO, with pending IO in the queue Refer link)
    4. You need to re-mount the EBS volume in the OS.
  3. While performing the volume status checks, if the status is insufficient-data, what does it mean?
    1. checks may still be in progress on the volume
    2. check has passed
    3. check has failed

References

AWS EC2 Instance Types – Certification

EC2 Instance Types Overview

  • EC2 Instance types determines the hardware of the host computer used for the instance.
  • Each instance type offers different compute, memory, and storage capabilities and are grouped in instance families based on these capabilities
  • EC2 provides each instance with a consistent and predictable amount of CPU capacity, regardless of its underlying hardware.
  • EC2 dedicates some resources of the host computer, such as CPU, memory, and instance storage, to a particular instance.
  • EC2 shares other resources of the host computer, such as the network and the disk subsystem, among instances. If each instance on a host computer tries to use as much of one of these shared resources as possible, each receives an equal share of that resource. However, when a resource is under-utilized, an instance can consume a higher share of that resource while it’s available

Current Generation Instance Types

EC2 Instance Types

EC2 Instance Type selection criteria

  • Some Instance types support only HVM virtualization type while others support both the PV and HVM virtualization types. AWS, however, recommends using HVM for taking advantage of the underlying hardware
  • All the instances are available in a VPC, however, few instance types are not available in an EC2-classic. AWS recommends VPC to take advantage of enhanced networking, multiple IP addresses, finer security control etc.
  • Some Instances types support only EBS volumes, while others support both EBS and Instance store volumes. Some instances that support instance store volumes use solid state drives (SSD) to deliver very high random I/O performance
  • Some instances can be launched as EBS optimized instances with a dedicated capacity for Amazon EBS I/O
  • Some instances can be launched in placement group for to optimize instances for High Performance Computing
  • Some instance support Enhanced Networking,  to get significantly higher packet per second (PPS) performance, lower network jitter, and lower latencies
  • Some Instances allow EBS volumes to be encrypted

EBS-Optimized

  • EBS-optimized instance uses an optimized configuration stack and provides additional, dedicated capacity for EBS I/O
  • EBS-optimized instances enable you to get consistently high performance for the EBS volumes by eliminating contention between EBS I/O and other network traffic from the instance
  • EBS-optimized instances deliver dedicated throughput to EBS, with options between 500 Mbps and 4,000 Mbps, depending on the instance type you use.
  • When attached to an EBS–optimized instance, General Purpose (SSD) volumes are designed to deliver within 10 percent of their baseline and burst performance 99.9 percent of the time in a given year, and Provisioned IOPS (SSD) volumes are designed to deliver within 10 percent of their provisioned performance 99.9 percent of the time in a given year.
  • EBS optimization can be enabled for an instance that is not EBS–optimized, by default

Placement Groups

Refer to My Blog Post @ EC2 Placement Groups

Instance Types

Screen Shot 2016-04-15 at 7.06.50 AM.png

T2 Instances (General Purpose)

  • T2 instances are designed to provide moderate baseline performance and the capability to burst to significantly higher performance as required by your workload.
  • Mainly intended for workloads that don’t use the full CPU often or consistently, but occasionally need to burst.
  • T2 instances are well suited for
    • general purpose workloads, such as web servers, developer environments, remote desktops and small databases
  • Requirements
    • can be launched only with HVM AMI
    • can be launched into a  VPC only, and not supported on the EC2-Classic platform
    • are available as EBS-backed instances only
    • are available as On-Demand or Reserved instances, but do not allow spot instances
    • By default, 20 (soft limit) T2 instances can run simultaneously
    • cannot be launched as a Dedicated instance

CPU Credits

  • CPU Credits (Similar to I/O Credits in case of the EBS general purpose storage) provides the performance of a full CPU core for one minute
  • T2 instances provide a baseline level of CPU performance, while CPU governs the ability to burst above the baseline level
  • One CPU credit is equal to one vCPU running at 100% utilization for one minute. for e.g. you can have One vCPU running at 100% for One minute OR One vCPU running @ 50% for 2 minutes OR Two vCPU running @ 25% for 2 minutes
  • Each T2 instance receives a healthy initial credit balance for startup performance
  • Initial CPU credits do not expire, but they are used first when an instance uses CPU credits.
  • Each T2 instance then continuously (at a millisecond-level resolution) receives a set rate of CPU credits per hour, depending on instance size for e.g. t2.nano earns 3/hour while a t2.large earns 36/hour
  • Each T2 instance accumulates the CPU credit when it uses fewer CPU resources than its allowed baseline performance levels
  • Maximum earned credit balance for an instance is equal to the number of CPU credits received per hour times 24 hours for e.g. t2.nano can earn max 72 (24 * 3) credits
  • CPU credit balance is available for a period of 24 hours and it expires 24 hours after they were earned. Expired credits are removed from the balance before new ones are added
  • CPU credit cease to persist between an instance stop – start. However, after the start, the instance receives the initial CPU credits again
  • When credit balance is completely exhausted, the instance will perform at its baseline performance

C4 Instances (Compute Intensive)

  • C4 instances are ideal for compute-bound applications that benefit from high performance processors
  • Well suited for
    • Batch processing workloads,
    • Media transcoding,
    • High-traffic web servers, massively multiplayer online (MMO) gaming servers, and ad serving engines,
    • High-traffic web servers, massively multiplayer online (MMO) gaming servers, and ad serving engines
  • Features
    • are EBS-optimized, by default
    • can be enabled for Enhanced Networking capabilities
    • can be clustered in a placement group
  • requirements
    • requires 64-bit HVM AMI
    • can be launched into a  VPC only, and not supported on the EC2-Classic platform

G2 Instances (Graphic Intensive)

  • GPU instances provide  high parallel processing capability
  • Well suited for
    • to accelerate many scientific, engineering, and rendering applications by leveraging the Compute Unified Device Architecture (CUDA) or OpenCL parallel computing frameworks
    • graphics applications, including game streaming, 3-D application streaming, and other graphics workloads
  • Requirements
    • requires HVM AMI
    • can’t access GPU unless NVIDIA drivers installed
  • Features
    • can be clustered in a placement group

I2 Instances (I/O Intensive)

  • I2 instances are optimized to deliver tens of thousands of low-latency, random I/O operations per second (IOPS) to applications.
  • Well suited for applications
    • NoSQL databases (for example, Cassandra and MongoDB)
    • Clustered databases
    • Online transaction processing (OLTP) systems
  • Features
    • Primary data storage is SSD-based instance storage.
    • can be enabled for Enhanced Networking capabilities
    • can be clustered in a placement group
    • can enable EBS–optimization to obtain additional, dedicated capacity for Amazon EBS I/O
  • Requirements
    • requires HVM AMI
  • HI1 is the equivalent previous generation instance
    • supports both PV and HVM AMIs

D2 Instances (Density Intensive)

  • D2 instances are designed for workloads with very high storage density and that require high sequential read and write access to very large data sets on local storage.
  • Well suited for applications
    • Massive parallel processing (MPP) data warehouse
    • MapReduce and Hadoop distributed computing
    • Log or data processing applications
  • Features
    • Primary data storage for D2 instances is HDD-based instance storage
    • are EBS-optimized, by default
    • can be enabled for Enhanced Networking capabilities
    • can be clustered in a placement group
  • requirements
    • requires 64-bit HVM AMI
  • HS1 is the equivalent previous generation instance
    • supports both EBS and Instance store backed AMIs
    • supports both PV and HVM AMIs

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following instance types are available as Amazon EBS-backed only? Choose 2 answers
    1. General purpose T2
    2. General purpose M3
    3. Compute-optimized C4
    4. Compute-optimized C3
    5. Storage-optimized 12
  2. A t2.medium EC2 instance type must be launched with what type of Amazon Machine Image (AMI)?
    1. An Instance store Hardware Virtual Machine AMI
    2. An Instance store Paravirtual AMI
    3. An Amazon EBS-backed Hardware Virtual Machine AMI
    4. An Amazon EBS-backed Paravirtual AMI
  3. You have identified network throughput as a bottleneck on your m1.small EC2 instance when uploading data Into Amazon S3 In the same region. How do you remedy this situation? Add an additional ENI
    1. Change to a larger Instance
    2. Use DirectConnect between EC2 and S3
    3. Use EBS PIOPS on the local volume
  4. You are using an m1.small EC2 Instance with one 300 GB EBS volume to host a relational database. You determined that write throughput to the database needs to be increased. Which of the following approaches can help achieve this? Choose 2 answers
    1. Use an array of EBS volumes (Striping to increase throughput)
    2. Enable Multi-AZ mode.
    3. Place the instance in an Auto Scaling Groups
    4. Add an EBS volume and place into RAID 5 (RAID 5 is not recommended as it provides parity and EBS volumes are already replicated across multiple servers in an Availability Zone for availability and durability, so AWS recommends striping for performance rather than durability)
    5. Increase the size of the EC2 Instance.
    6. Put the database behind an Elastic Load Balancer.
  5. You are tasked with setting up a cluster of EC2 Instances for a NoSQL database. The database requires random read IO disk performance up to a 100,000 IOPS at 4KB block side per node. Which of the following EC2 instances will perform the best for this workload?
    1. A High-Memory Quadruple Extra Large (m2.4xlarge) with EBS-Optimized set to true and a PIOPs EBS volume
    2. A Cluster Compute Eight Extra Large (cc2.8xlarge) using instance storage
    3. High I/O Quadruple Extra Large (hi1.4xlarge) using instance storage
    4. A Cluster GPU Quadruple Extra Large (cg1.4xlarge) using four separate 4000 PIOPS EBS volumes in a RAID 0 configuration
  6. You are implementing a URL whitelisting system for a company that wants to restrict outbound HTTP’S connections to specific domains from their EC2-hosted applications you deploy a single EC2 instance running proxy software and configure It to accept traffic from all subnets and EC2 instances in the VPC. You configure the proxy to only pass through traffic to domains that you define in its whitelist configuration You have a nightly maintenance window or 10 minutes where ail instances fetch new software updates. Each update Is about 200MB In size and there are 500 instances In the VPC that routinely fetch updates After a few days you notice that some machines are failing to successfully download some, but not all of their updates within the maintenance window The download URLs used for these updates are correctly listed in the proxy’s whitelist configuration and you are able to access them manually using a web browser on the instances What might be happening? (Choose 2 answers) [PROFESSIONAL]
    1. You are running the proxy on an undersized EC2 instance type so network throughput is not sufficient for all instances to download their updates in time.
    2. You have not allocated enough storage to the EC2 instance running me proxy so the network buffer is filling up causing some requests to fall
    3. You are running the proxy in a public subnet but have not allocated enough EIPs to support the needed network throughput through the Internet Gateway (IGW)
    4. You are running the proxy on a affluently-sized EC2 instance in a private subnet and its network throughput is being throttled by a NAT running on an undersized EC2 instance
    5. The route table for the subnets containing the affected EC2 instances is not configured to direct network traffic for the software update locations to the proxy.
  7. You have been asked to design the storage layer for an application. The application requires disk performance of at least 100,000 IOPS in addition; the storage layer must be able to survive the loss of an individual disk, EC2 instance, or Availability Zone without any data loss. The volume you provide must have a capacity of at least 3TB. Which of the following designs will meet these objectives? [PROFESSIONAL]
    1. Instantiate an i2.8xlarge instance in us-east-1a. Create a RAID 0 volume using the four 800GB SSD ephemeral disks provided with the instance. Provision 3×1 TB EBS volumes attach them to the instance and configure them as a second RAID 0 volume. Configure synchronous, block-level replication from the ephemeral backed volume to the EBS-backed volume. (Same AZ will not survive the AZ loss)
    2. Instantiate an i2.8xlarge instance in us-east-1a. Create a RAID 0 volume using the four 800GB SSD ephemeral disks provided with the Instance Configure synchronous block-level replication to an identically configured Instance in us-east-1b.
    3. Instantiate a c3.8xlarge Instance in us-east-1. Provision an AWS Storage Gateway and configure it for 3 TB of storage and 100,000 IOPS. Attach the volume to the instance. (Need synchronous replication to prevent any data loss)
    4. Instantiate a c3.8xlarge instance in us-east-1 provision 4x1TB EBS volumes, attach them to the instance, and configure them as a single RAID 5 volume Ensure that EBS snapshots are performed every 15 minutes. (RAID 5 not recommended by AWS and Need synchronous replication to prevent any data loss)
    5. Instantiate a c3 8xlarge Instance in us-east-1 Provision 3x1TB EBS volumes attach them to the instance, and configure them as a single RAID 0 volume Ensure that EBS snapshots are performed every 15 minutes. (Need synchronous replication to prevent any data loss)

References

AWS EC2 Amazon Machine Image – AMI – Certification

Amazon Machine Image – AMI

  • An Amazon Machine Image (AMI) provides the information required to launch an instance, which is a virtual server in the cloud.
  • An AMI is basically an template and can be used to launch as many instances as needed
  • Within an VPC, instances can be launched from as many different AMIs
  • An AMI includes the following:
    • A template for the root volume for the instance for e.g. an operating system, an application server, and applications
    • Launch permissions that control which AWS accounts can use the AMI to launch instances for e.g. AWS account ids with whom the AMI is shared
    • A block device mapping that specifies the volumes to attach to the instance when it’s launched
  • AMIs can be either
    • AWS managed, provided and published AMIs
    • Third party or Community provided public custom AMIs
    • Private AMIs created by other AWS accounts and shared with you
    • Private and Custom AMIs created by you
  • AMI lifecycle
    • After you create and register an AMI
    • you can use it to launch new instances. (You can also launch instances from an AMI if the AMI owner grants you launch permissions.)
    • You can copy an AMI to the same region or to different regions.
    • When you are finished launching instance from an AMI, you can deregister the AMI

AMI Types

  • Region & Availability Zone
    • AMIs are specific to a region and if needed in other region must be copied over
  • Operating system
    • AMIS are available in a variety of OS flavors for e.g. linux, windows, ubuntu etc
  • Architecture (32-bit or 64-bit)
  • Launch Permissions
    • Launch permissions define who has access to the AMI
      • Public – Accessible to all AWS accounts
      • Explicit – Shared with specific AWS accounts
      • Private – Owned and available for AMI creator AWS account only
  • Root device storage
    • AMIs can have EBS or Instance store as the root device storage
    • EBS backed
      • EBS volume are independent of the EC2 instance lifecycle and can persist independently
      • EBS backed instances can be stopped without losing the volumes
      • EBS instance can also be persist without losing the volumes on instance termination, if the Delete On Termination flag is disabled
      • EBS backed instances boot up uch faster than the Instance store backed instances as only the parts required to boot the instance needs to be retrieved from the snapshot before the instance is made available
      • AMI creation is much easier for AMIs backed by Amazon EBS. The CreateImage API action creates your Amazon EBS-backed AMI and registers it
    • Instance Store backed
      • Instance store is an ephemeral storage and is dependent on the lifecycle of the Instance
      • Instance store is deleted if the instance is terminated or if the EBS backed instance, with attached instance store volumes, is stopped
      • Instance store volumes cannot be stopped
      • Instance store volumes have their AMI in S3 and have higher boot times compared to EBS backed instances, as all the parts have to be retrieved from Amazon S3 before the instance is made available
      • To create Linux AMIs backed by instance store, you must create an AMI from your instance on the instance itself using the Amazon EC2 AMI tools.
    • More detailed @ EBS vs Instance Store

Amazon Linux AMI

Amazon Linux AMI is a supported and maintained Linux image provided by AWS with the following features

  • A stable, secure, and high-performance execution environment for applications running on Amazon EC2.
    • Amazon Linux does not allow remote root SSH by default.
    • Password authentication is disabled to prevent brute-force password attacks.
    • Instances launched using Amazon Linux AMI must be provided with a key pair at launch to enable SSH logins
    • Inbound security group must allow SSH access
    • By default, the only account that can log in remotely using SSH is ec2-user; this account also has sudo privileges.
    • Amazon Linux AMIs are configured to download and install security updates at launch time.
  • Provided at no additional charge to Amazon EC2 users.
  • Repository access to multiple versions of MySQL, PostgreSQL, Python, Ruby, Tomcat, and many more common packages.
  • Updated on a regular basis to include the latest components, and these updates are also made available in the yum repositories for installation on running instances.
  • Includes pre-installed packages to enable easy integration with AWS services, such as the AWS CLI, Amazon EC2 API and AMI tools, the Boto library for Python, and the Elastic Load Balancing tools.

Linux Virtualization Types

  • Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM).
  • Main difference between PV and HVM AMIs is the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.
  • For the best performance, AWS recommends use of current generation instance types and HVM AMIs when you launch your instances.
  • HVM AMIs
    • HVM AMIs are presented with a fully virtualized set of hardware and boot by executing the master boot record of the root block device of your image.
    • HVM virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware.
    • Amazon EC2 host system emulates some or all of the underlying hardware that is presented to the guest.
    • HVM guests, unlike PV guest, can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system.
    • HVM AMIs are required to take advantage of enhanced networking and GPU processing. In order to pass through instructions to specialized network and GPU devices, the OS needs to be able to have access to the native hardware platform; HVM virtualization provides this access.
    • All current generation instance types support HVM AMIs.The CC2, CR1, HI1, and HS1 previous generation instance types support HVM AMIs.
  • PV AMIs
    • PV AMIs boot with a special boot loader called PV-GRUB, which starts the boot cycle and then chain loads the kernel specified in the menu.lst file on your image.
    • Paravirtual guests can run on host hardware that does not have explicit support for virtualization, but they cannot take advantage of special hardware extensions such as enhanced networking or GPU processing.
    • C3 and M3 current generation instance types support PV AMIs. The C1, HI1, HS1, M1, M2, and T1 previous generation instance types support PV AMIs.

Shared AMIs

  • Shared AMI is an AMI that can be created and shared with others for use
  • a Shared AMI with all the components needed can be used to get started and then add custom components as and when needed
  • Shared AMI can be risky as Amazon does not perform an detailed checks and vouch for the integrity and security of these AMIs
  • Before using a Shared AMI, check for any pre-installed credentials that would allow unwanted access to the instance by a third party and no pre-configured remote logging that could transmit sensitive data to a third party
  • Amazon allows you to share an AMI, by defining launch permissions, to all (making it public) or only to a specific AWS accounts
  • Launch permissions work at the AWS account level only; and can’t be used to restrict specific users within an AWS account.
  • Guidelines for Shared Linux AMIs
    • Update the AMI Tools at Boot Time
      • Update the AMI tools or any software during startup.
      • Take into account the software updates not not break any software and consider the WAN traffic as the downloads will be charged to the AMI user
    • Disable Password-Based Remote Logins for Root
      • Fixed root passwords can be a security risk and needs to be disabled
    • Disable Local Root Access
      • Working with shared AMIs, a best practice is to disable direct root logins
    • Remove SSH Host Key Pairs
      • Remove the existing SSH host key pairs located in /etc/ssh, which forces SSH to generate new unique SSH key pairs when someone launches an instance using your AMI, improving security and reducing the likelihood of “man-in-the-middle” attacks
    • Install Public Key Credentials
      • Amazon EC2 allows users to specify a public-private key pair name when launching an instance.
      • A valid key pair name needs to be provided when launching an instance, the public key, the portion of the key pair that Amazon Ec2 maintains on the server, is made available to the instance through an HTTP query against the instance metadata and appended to the authorized keys
      • Users can launch instances of your AMI with a key pair and log in without requiring a root password
    • Disabling sshd DNS Checks (Optional)
      • Disabling sshd DNS checks slightly weakens your sshd security. However, if DNS resolution fails, SSH logins still work. If you do not disable sshd checks, DNS resolution failures prevent all logins.
    • Identify Yourself
      • AMI is only represented by an account ID without any further information, so it is better to provide more information to help describe the AMI
    • Protect Yourself
      • Don’t store any sensitive data or software on the AMI
      • Exclude & Skip any directories which hold the sensitive data or secret information and delete the shell history before creating an AMI

AMI Creation

EBS-Backed Linux AMI

Screen Shot 2016-04-12 at 7.39.18 AM.png

  • EBS-Backed Linux AMI can be created from the instance directly or from the EBS snapshot
  • EBS-backed linux AMI creation process :-
    1. Select an AMI #1 similar to what you want to have your new AMI #2
    2. Launch an Instance from AMI #1 and configure the instance accordingly
    3. Stop the instance to ensure data integrity and then create AMI #2 OR
    4. Create an EBS snapshot and then create an AMI #2 from the snapshot
    5. Amazon automatically register the EBS-backed AMI for you
    6. AMI #2 an be used to now launch new instances
  • By default, EC2 shuts down the instance, takes snapshots of any attached volumes, creates and registers the AMI, and then reboots the instance.
  • Shut down & Reboot of the Instance can be prevented using the No reboot option, however the file system integrity of the created image can’t be guaranteed
  • EC2 creates snapshots of the 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 any additional instance-store volumes or EBS volumes, 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.
  • While data on EBS volumes persists, 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.
  • Its more efficient to create an EBS-backed AMI with EBS snapshots already taken as the snapshot created during AMI creation is just an incremental one
  • You are charged for the storage of both the AMI and the snapshots

Instance Store-Backed Linux AMI

Screen Shot 2016-04-12 at 7.39.28 AM.png

  • Instance Store-Backed Linux AMI creation process
    1. Select an AMI #1 similar to what you want to have your new AMI #2
    2. Launch an Instance from AMI #1 and configure the instance accordingly
    3. Bundle the Instance. It takes several minutes for the bundling process to complete.
    4. After the process completes, you have a bundle, which consists of an image manifest (image.manifest.xml) and files (image.part.xx) that contain a template for the root volume.
    5. Upload the bundle to your Amazon S3 bucket
    6. Register the Instance Store-backed AMI.
    7. Launching an instance using the new AMI #2, the root volume for the instance is created using the bundle that you uploaded to Amazon S3.
  • Charges are incurred for rhe storage space used by the bundle in Amazon S3 until deleted
  • For additional instance store not root volumes, 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.

Deregistering AMI

  • Charges are incurred on the AMI created and they can be deregistered, if not needed.
  • Deregistering an AMI does not delete the EBS snapshots or the bundles in the S3 buckets and have to be removed separately
  • Once deregistered, new instances cannot be launched from the AMI. However, it does not impact already created instances from the AMI
  • Clean up EBS-Backed AMI
    • Screen Shot 2016-04-12 at 8.11.28 AM.png
    • Deregister the EBS-Backed AMI
    • Delete the EBS Snapshot, as deregistering the AMI doesn’t impact the snapshot
  • Clean up Instance Store-backed AMI
    • Screen Shot 2016-04-12 at 8.11.21 AM.png
    • Deregister the EBS-Backed AMI
    • Delete the bundle from the S3 bucket, as deregistering the AMI doesn’t effect the bundles stored in the S3 bucket

AMIs with Encrypted Snapshots

  • AMIs, with EBS backed snapshots, can be attached with both an encrypted root and data volume
  • AMIs copy image can be used to create AMIs with encrypted snapshots from AMIs with unencrypted snapshots. By default, copy image preserves the encryption status of the snapshots
  • Snapshots can be encrypted with either your default AWS Key Management Service customer master key (CMK), or with a custom key that you specify

AMI Copying

  • Amazon EBS-backed AMIs and instance store-backed AMIs can be copied.
  • Copying an AMI
    • An identical target AMI is created, but with its own unique identifier
    • For EBS Backed AMI, an identical but distinct root and data snapshots are created
    • Encryption status of the snapshots are preserved
    • However, Launch permissions, user-defined tags, or Amazon S3 bucket permissions are not copied from the source AMI to the new AMI. After the copy operation is complete, different launch permissions, user-defined tags, and Amazon S3 bucket permissions to the new AMI
  • Source AMI can be deregistered without any impact to the Target AMI
  • You can copy your owned AMIs, AMIs shared with you with proper permissions
  • AMIs are created specific to a region and can be copied within or across regions which can help to aid in consistent global deployment and build highly scalable and available applications
  • AMI copy image can be used to encrypt an AMI from an unencrypted AMI
  • AMI copy image can’t be used to create an unencrypted an AMI from an encrypted AMI

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has launched an EC2 instance from an instance store backed AMI. The infrastructure team wants to create an AMI from the running instance. Which of the below mentioned credentials is not required while creating the AMI?
    1. AWS account ID
    2. 509 certificate and private key
    3. AWS login ID to login to the console
    4. Access key and secret access key
  2. A user has launched an EC2 Windows instance from an instance store backed AMI. The user wants to convert the AMI to an EBS backed AMI. How can the user convert it?
    1. Attach an EBS volume to the instance and unbundle all the AMI bundled data inside the EBS
    2. A Windows based instance store backed AMI cannot be converted to an EBS backed AMI
    3. It is not possible to convert an instance store backed AMI to an EBS backed AMI
    4. Attach an EBS volume and use the copy command to copy all the ephemeral content to the EBS Volume
  3. A user has launched two EBS backed EC2 instances in the US-East-1a region. The user wants to change the zone of one of the instances. How can the user change it?
    1. Stop one of the instances and change the availability zone
    2. The zone can only be modified using the AWS CLI
    3. From the AWS EC2 console, select the Actions – > Change zones and specify new zone
    4. Create an AMI of the running instance and launch the instance in a separate AZ
  4. A user has launched a large EBS backed EC2 instance in the US-East-1a region. The user wants to achieve Disaster Recovery (DR) for that instance by creating another small instance in Europe. How can the user achieve DR?
    1. Copy the running instance using the “Instance Copy” command to the EU region
    2. Create an AMI of the instance and copy the AMI to the EU region. Then launch the instance from the EU AMI
    3. Copy the instance from the US East region to the EU region
    4. Use the “Launch more like this” option to copy the instance from one region to another
  5. A user has launched an EC2 instance store backed instance in the US-East-1a zone. The user created AMI #1 and copied it to the Europe region. After that, the user made a few updates to the application running in the US-East-1a zone. The user makes an AMI#2 after the changes. If the user launches a new instance in Europe from the AMI #1 copy, which of the below mentioned statements is true?
    1. The new instance will have the changes made after the AMI copy as AWS just copies the reference of the original AMI during the copying. Thus, the copied AMI will have all the updated data
    2. The new instance will have the changes made after the AMI copy since AWS keeps updating the AMI
    3. It is not possible to copy the instance store backed AMI from one region to another
    4. The new instance in the EU region will not have the changes made after the AMI copy
  6. George has shared an EC2 AMI created in the US East region from his AWS account with Stefano. George copies the same AMI to the US West region. Can Stefano access the copied AMI of George’s account from the US West region?
    1. No, copy AMI does not copy the permission
    2. It is not possible to share the AMI with a specific account
    3. Yes, since copy AMI copies all private account sharing permissions
    4. Yes, since copy AMI copies all the permissions attached with the AMI
  7. EC2 instances are launched from Amazon Machine images (AMIS). A given public AMI can:
    1. be used to launch EC2 Instances in any AWS region.
    2. only be used to launch EC2 instances in the same country as the AMI is stored.
    3. only be used to launch EC2 instances in the same AWS region as the AMI is stored. (An AMI is tied to the region where its files are located within Amazon S3)
    4. only be used to launch EC2 instances in the same AWS availability zone as the AMI is stored.

References

AWS EC2 Best Practices

AWS recommends the following to get maximum benefit and satisfaction from EC2

Security & Network

  • Implement the least permissive rules for your security group.
  • Regularly patch, update, and secure the operating system and applications on your instance
  • Launch your instances into a VPC instead of EC2-Classic (If aws account is newly created VPC is used by default)
  • Manage access to AWS resources and APIs using identity federation, IAM users, and IAM roles
  • Establish credential management policies and procedures for creating, distributing, rotating, and revoking AWS access credentials

Storage

  • EC2 supports Instance store and EBS volumes, so its best to understand the implications of the root device type for data persistence, backup, and recovery
  • Use separate Amazon EBS volumes for the operating system (root device) versus your data.
  • Ensure that the data volume (with your data) persists after instance termination
  • Use the instance store available for your instance to only store temporary data. (Remember that the data stored in instance store is deleted when you stop or terminate your instance)
  • If you use instance store for database storage, ensure that you have a cluster with a replication factor that ensures fault tolerance.

Resource Management

  • Use instance metadata and custom resource tags to track and identify your AWS resources
  • View your current limits for Amazon EC2. Plan to request any limit increases in advance of the time that you’ll need them.

Backup & Recovery

  • Regularly back up your instance using Amazon EBS snapshots (not done automatically) or a backup tool.
  • Data Lifecycle Manager (DLM) to automate the creation, retention, and deletion of snapshots taken to back up the EBS volumes
  • Implement High Availability by deploying critical components of the application across multiple Availability Zones, and replicate the data appropriately
  • Monitor and respond to events.
  • Design your applications to handle dynamic IP addressing when your instance restarts.
  • Implement failover. For a basic solution, you can manually attach a network interface or Elastic IP address to a replacement instance
  • Regularly test the process of recovering your instances and Amazon EBS volumes if they fail.

References

AWS EC2 – Placement Groups – Certification

Placement Groups Overview

  • Placement group determines how instances are placed on underlying hardware
  • AWS now provides three types of placement groups
    • Cluster – clusters instances into a low-latency group in a single AZ
    • Partition – spreads instances across logical partitions, ensuring that instances in one partition do not share underlying hardware with instances in other partitions
    • Spread – spreads instances across underlying hardware

Cluster Placement Group

  • is a logical grouping of instances within a single Availability Zone
  • don’t span across Availability Zones
  • recommended for applications that benefits from low network latency, high network throughput, or both.
  • To provide the lowest latency, and the highest packet-per-second network performance for the placement group, choose an instance type that supports enhanced networking
  • recommended to launch all group instances at the same time to ensure enough capacity
  • instances can be added later, but there are chances of encountering an insufficient capacity error
  • for moving an instance into the placement group,
    • create an AMI from the existing instance,
    • and then launch a new instance from the AMI into a placement group.
  • stopping and starting an instance within the placement group, the instance still runs in the same placement group
  • in case of an capacity error, stop and start all of the instances in the placement group, and try the launch again. Restarting the instances may migrate them to hardware that has capacity for all requested instances
  • is only available within a single AZ either in the same VPC or peered VPCs
  • is more of an hint to AWS that the instances need to be launched physically close to each together
  • enables applications to participate in a low-latency, 10 Gbps network.

AWS EC2 Placement Group

Partition Placement Groups

  • is a group of instances spread across partitions. Partitions are logical groupings of instances, where contained instances do not share the same underlying hardware across different partitions.
  • can be used to spread deployment of large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct hardware to reduce the likelihood of correlated failures
  • can have a maximum of seven partitions per Availability Zone
  • can span multiple Availability Zones in the same Region.

Spread Placement Groups

  • is a group of instances that are each placed on distinct underlying hardware
  • recommended for applications that have a small number of critical instances that should be kept separate from each other.
  • reduces the risk of simultaneous failures that might occur when instances share the same underlying hardware.
  • provide access to distinct hardware, and are therefore suitable for mixing instance types or launching instances over time.
  • can span multiple AZs, and can have a maximum of seven running instances per AZ per group.
  • If the start or launch an instance in a spread placement group fails cause of insufficient unique hardware to fulfill the request, the request can be tried later as EC2 makes more distinct hardware available over time

Placement Group Rules and Limitations

  • Ensure unique Placement group name within AWS account for the region
  • Placement groups cannot be merged
  • An instance can be launched in one placement group at a time; it cannot span multiple placement groups.
  • Instances with a tenancy of host cannot be launched in placement groups.
  • Cluster Placement group
    • can’t span multiple Availability Zones.
    • supported by Specific Instance types (General Purpose, GPU, Compute, Memory, Storage Optimized – c4.8xlarge, c3.8xlarge, g2.8xlarge, i2.8xlarge, r3.8xlarge, m4.10xlarge, d2.8xlarge) which support 10 Gigabyte network
    • maximum network throughput speed of traffic between two instances in a cluster placement group is limited by the slower of the two instances, so choose the instance type properly.
    • can use up to 10 Gbps for single-flow traffic.
    • Traffic to and from S3 buckets within the same region over the public IP address space or through a VPC endpoint can use all available instance aggregate bandwidth.
    • recommended to use the same instance type i.e. homogenous instance types. Although multiple instance types can be launched into a cluster placement group. However, this reduces the likelihood that the required capacity will be available for your launch to succeed
    • Network traffic to the internet and over an AWS Direct Connect connection to on-premises resources is limited to 5 Gbps.
  • Partition placement groups
    • supports a maximum of seven partitions per Availability Zone
    • with Dedicated Instances can have a maximum of two partitions
    • are not supported for Dedicated Hosts
    • are currently only available through the API or AWS CLI.
  • Spread placement groups
    • supports a maximum of seven running instances per Availability Zone for e.g., in a region that has three AZs, then a total of 21 running instances in the group (seven per zone).
    • are not supported for Dedicated Instances or Dedicated Hosts.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. What is a placement group?
    • A collection of Auto Scaling groups in the same Region
    • Feature that enables EC2 instances to interact with each other via high bandwidth, low latency connections
    • A collection of Elastic Load Balancers in the same Region or Availability Zone
    • A collection of authorized Cloud Front edge locations for a distribution
  2. In order to optimize performance for a compute cluster that requires low inter-node latency, which feature in the following list should you use?
    • AWS Direct Connect
    • Placement Groups
    • VPC private subnets
    • EC2 Dedicated Instances
    • Multiple Availability Zones
  3. What is required to achieve gigabit network throughput on EC2? You already selected cluster-compute, 10GB instances with enhanced networking, and your workload is already network-bound, but you are not seeing 10 gigabit speeds.
    1. Enable biplex networking on your servers, so packets are non-blocking in both directions and there’s no switching overhead.
    2. Ensure the instances are in different VPCs so you don’t saturate the Internet Gateway on any one VPC.
    3. Select PIOPS for your drives and mount several, so you can provision sufficient disk throughput
    4. Use a placement group for your instances so the instances are physically near each other in the same Availability Zone. (You are not guaranteed 10 gigabit performance, except within a placement group. Using placement groups enables applications to participate in a low-latency, 10 Gbps network)
  4. You need the absolute highest possible network performance for a cluster computing application. You already selected homogeneous instance types supporting 10 gigabit enhanced networking, made sure that your workload was network bound, and put the instances in a placement group. What is the last optimization you can make?
    1. Use 9001 MTU instead of 1500 for Jumbo Frames, to raise packet body to packet overhead ratios. (For instances that are collocated inside a placement group, jumbo frames help to achieve the maximum network throughput possible, and they are recommended in this case)
    2. Segregate the instances into different peered VPCs while keeping them all in a placement group, so each one has its own Internet Gateway.
    3. Bake an AMI for the instances and relaunch, so the instances are fresh in the placement group and do not have noisy neighbors
    4. Turn off SYN/ACK on your TCP stack or begin using UDP for higher throughput.

References

EC2_User_Guide – Placement_Groups

AWS Bastion Host – Certification

Bastion Host Overview

  • Bastion means a structure for Fortification to protect things behind it
  • In AWS, a Bastion host (also referred to as a Jump server) can be used to securely access instances in the private subnets.
  • Bastion host launched in the Public subnets would act as a primary access point from the Internet and acts as a proxy to other instances.

Bastion Host

Key points

  • Bastion host is deployed in the Public subnet and acts as a proxy or a gateway between you and your instances
  • Bastion host is a security measure that helps to reduce attack on your infrastructure and you have to concentrate to hardening a single layer
  • Bastion host allows you to login to instances in the Private subnet securely without having to store the private keys on the Bastion host (using ssh-agent forwarding or RDP gateways)
  • Bastion host security can be further tightened to allow SSH/RDP access from specific trusted IPs or corporate IP ranges
  • Bastion host for your AWS infrastructure shouldn’t be used for any other purpose, as that could open unnecessary security holes
  • Security for all the Instances in the private subnet should be hardened to accept SSH/RDP connections only from the Bastion host
  • Deploy a Bastion host within each Availability Zone for HA, cause if the Bastion instance or the AZ hosting the Bastion server goes down the ability to connect to your private instances is lost completely

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A customer is running a multi-tier web application farm in a virtual private cloud (VPC) that is not connected to their corporate network. They are connecting to the VPC over the Internet to manage all of their Amazon EC2 instances running in both the public and private subnets. They have only authorized the bastion-security-group with Microsoft Remote Desktop Protocol (RDP) access to the application instance security groups, but the company wants to further limit administrative access to all of the instances in the VPC. Which of the following Bastion deployment scenarios will meet this requirement?
    1. Deploy a Windows Bastion host on the corporate network that has RDP access to all instances in the VPC.
    2. Deploy a Windows Bastion host with an Elastic IP address in the public subnet and allow SSH access to the bastion from anywhere.
    3. Deploy a Windows Bastion host with an Elastic IP address in the private subnet, and restrict RDP access to the bastion from only the corporate public IP addresses.
    4. Deploy a Windows Bastion host with an auto-assigned Public IP address in the public subnet, and allow RDP access to the bastion from only the corporate public IP addresses.
  2. You are designing a system that has a Bastion host. This component needs to be highly available without human intervention. Which of the following approaches would you select?
    1. Run the bastion on two instances one in each AZ
    2. Run the bastion on an active Instance in one AZ and have an AMI ready to boot up in the event of failure
    3. Configure the bastion instance in an Auto Scaling group Specify the Auto Scaling group to include multiple AZs but have a min-size of 1 and max-size of 1
    4. Configure an ELB in front of the bastion instance
  3. You’ve been brought in as solutions architect to assist an enterprise customer with their migration of an ecommerce platform to Amazon Virtual Private Cloud (VPC) The previous architect has already deployed a 3- tier VPC. The configuration is as follows: VPC vpc-2f8t>C447
    IGW ig-2d8bc445
    NACL acl-2080c448
    Subnets and Route Tables:
    Web server’s subnet-258bc44d
    Application server’s subnet-248DC44c
    Database server’s subnet-9189c6f9
    Route Tables:
    rtb-2i8bc449
    rtb-238bc44b
    Associations:
    Subnet-258bc44d: rtb-2i8bc449
    Subnet-248DC44c: rtb-238bc44b
    Subnet-9189c6f9: rtb-238bc44b
    You are now ready to begin deploying EC2 instances into the VPC. Web servers must have direct access to the internet Application and database servers cannot have direct access to the internet. Which configuration below will allow you the ability to remotely administer your application and database servers, as well as allow these servers to retrieve updates from the Internet?

    1. Create a bastion and NAT Instance in subnet-258bc44d and add a route from rtb-238bc44b to subnet-258bc44d. (Route should point to the NAT)
    2. Add a route from rtb-238bc44b to igw-2d8bc445 and add a bastion and NAT instance within Subnet-248DC44c. (Adding IGW to routertb-238bc44b would expose the Application and Database server to internet. Bastion and NAT should be in public subnet)
    3. Create a Bastion and NAT Instance in subnet-258bc44d. Add a route from rtb-238bc44b to igw-2d8bc445. And a new NACL that allows access between subnet-258bc44d and subnet-248bc44c. (Route should point to NAT and not Internet Gateway else it would be internet accessible.)
    4. Create a Bastion and NAT instance in subnet-258bc44d and add a route from rtb-238bc44b to the NAT instance. (Bastion and NAT should be in the public subnet. As Web Server has direct access to Internet, the subnet subnet-258bc44d should be public and Route rtb-2i8bc449 pointing to IGW. Route rtb-238bc44b for private subnets should point to NAT for outgoing internet access)
  4. You are tasked with setting up a Linux bastion host for access to Amazon EC2 instances running in your VPC. Only clients connecting from the corporate external public IP address 72.34.51.100 should have SSH access to the host. Which option will meet the customer requirement?
    1. Security Group Inbound Rule: Protocol – TCP. Port Range – 22, Source 72.34.51.100/32
    2. Security Group Inbound Rule: Protocol – UDP, Port Range – 22, Source 72.34.51.100/32
    3. Network ACL Inbound Rule: Protocol – UDP, Port Range – 22, Source 72.34.51.100/32
    4. Network ACL Inbound Rule: Protocol – TCP, Port Range-22, Source 72.34.51.100/0

AWS – EC2 – Troubleshooting Connecting to an Instance

  1. Verify the Security groups are properly configured to allow ssh access from the ip to the EC2 instance. For Security groups, Inbound traffic from the public ip address should be enabled
  2. Verify the NACLs are properly configured to allow ssh access from the ip to the EC2 instance. For NACLs, Inbound traffic from the public ip address should be enabled as well as the Outbound traffic for the response should be enabled
  3. Verify you are using the private key file that corresponds to the key pair that you selected when you launched the instance
  4. Verify you are connecting with the appropriate user name for your AMI. Mind the user names used to connect to the EC2 instance are different depending upon the AMI (which also determines the OS for the Instance)
  5. Private User key file is not recognized by the Server

Exam Scenario Question

  1. You try to connect via SSH to a newly created Amazon EC2 instance and get one of the following error messages: “Network error: Connection timed out” or “Error connecting to instance], reason: -> Connection timed out: connect,” You have confirmed that the network and security group rules are configured correctly and the instance is passing status checks. What steps should you take to identify the source of the behavior? Choose 2 answers
    • Verify that the private key file corresponds to the Amazon EC2 key pair assigned at launch.
    • Verify that your IAM user policy has permission to launch Amazon EC2 instances.
    • Verify that you are connecting with the appropriate user name for your AMI.
    • Verify that the Amazon EC2 Instance was launched with the proper IAM role.
    • Verify that your federation trust to AWS has been established.

 

References

EC2 User Guide