Don't forget to create account on our site to get access to more material made only for free registered user.  

AWS Developer Certification : Associate Level AWS Sysops Administrator Certification : Assciate Level   AWS Solution Architect Certification : Associate Level  AWS Solution Architect Certification : Associate Level

1.    Boot time -> Amazon EBS-Backed: Usually less than 1 minute. Amazon Instance Store-Backed: Usually less than 5 minutes

2.    Upgrading -> Amazon EBS-Backed: The instance type, kernel, RAM disk, and user data can be changed while the instance is stopped. Amazon Instance Store-Backed: Instance attributes are fixed for the life of an instance.

3.    Ephemeral disk is a temporary storage that it is added to your instance, and depending on your instance type the bigger is such storage.

4.    Instance store is dedicated to a particular instance.

5.    You can't attach instance store volumes to an instance after you've launched it.

6.    After you launch the instance, you must ensure that the instance store volumes for your instance are formatted and mounted before you can use them.

7.    Note that the root volume of an instance store-backed instance is mounted automatically.

8.    When you launch an Amazon EC2 instance store-backed AMI, all the parts have to be retrieved from Amazon S3 before the instance is available. With an Amazon EBS-backed AMI, only the parts required to boot the instance need to be retrieved from the snapshot before the instance is available.

9.    For the best performance, we recommend that you use current generation instance types and HVM AMIs when you launch your instances. 

10. Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The 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.

11. Unlike PV guests, HVM guests can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system. 

12. Amazon can't vouch for the integrity or security of AMIs shared by other Amazon EC2 users. Therefore, you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence.

13. Amazon's public images have an aliased owner, which appears as amazon in the account field. This enables you to find AMIs from Amazon easily. Other users can't alias their AMIs.

14. Before you use a shared AMI, take the following steps to confirm that there are no pre-installed credentials that would allow unwanted access to your instance by a third party and no pre-configured remote logging that could transmit sensitive data to a third party.

15. To ensure that you don't accidentally lose access to your instance, we recommend that you initiate two SSH sessions and keep the second session open until you've removed credentials that you don't recognize and confirmed that you can still log into your instance using SSH.

16. To prevent preconfigured remote logging, you should delete the existing configuration file and restart the rsyslog service.

17. AMIs are a regional resource. Therefore, sharing an AMI makes it available in that region. To make an AMI available in a different region, copy the AMI to the region and then share it. 

18. If an AMI has a product code, you can't make it public. You must share the AMI with only specific AWS accounts.

19. You do not need to share the Amazon EBS snapshots that an AMI references in order to share the AMI. Only the AMI itself needs to be shared; the system automatically provides the instance access to the referenced Amazon EBS snapshots for the launch.

20. If you have created a public AMI, or shared an AMI with another AWS user, you can create a bookmark that allows a user to access your AMI and launch an instance in their own account immediately. This is an easy way to share AMI references, so users don't have to spend time finding your AMI in order to use it.

21. For AMIs backed by instance store, we recommend that your AMIs download and upgrade the Amazon EC2 AMI creation tools during startup. This ensures that new AMIs based on your shared AMIs have the latest AMI tools.

22. Using a fixed root password for a public AMI is a security risk that can quickly become known. Even relying on users to change the password after the first login opens a small window of opportunity for potential abuse. To solve this problem, disable password-based remote logins for the root user.

23. When you work with shared AMIs, a best practice is to disable direct root logins. 

24. If you plan to share an AMI derived from a public AMI, remove the existing SSH host key pairs located in /etc/ssh. This 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.

25. If you forget to remove the existing SSH host key pairs from your public AMI, our routine auditing process notifies you and all customers running instances of your AMI of the potential security risk. After a short grace period, we mark the AMI private.

26. Currently, there is no easy way to know who provided a shared AMI, because each AMI is represented by an account ID. We recommend that you post a description of your AMI, and the AMI ID, in the Amazon EC2 forum. This provides a convenient central location for users who are interested in trying new shared AMIs. You can also post the AMI to the Amazon Machine Images (AMIs) page.

27. We recommend using the --exclude directory option on ec2-bundle-vol to skip any directories and subdirectories that contain secret information that you would not like to include in your bundle. In particular, exclude all user-owned SSH public/private key pairs and SSH authorized_keys files when bundling the image. The Amazon public AMIs store these in /root/.ssh for the root account, and /home/user_name/.ssh/ for regular user accounts.

28. Always delete the shell history before bundling. If you attempt more than one bundle upload in the same AMI, the shell history contains your secret access key.

29. Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled (such as the instance store).

30. The developer of a paid AMI can enable you to purchase a paid AMI that isn't listed in AWS Marketplace. The developer provides you with a link that enables you to purchase the product through Amazon

31. You can retrieve the AWS Marketplace product code for your instance using its instance metadata.

32. During the AMI-creation process, Amazon EC2 creates snapshots of your instance's root volume and any other EBS volumes attached to your instance. If any volumes attached to the instance are encrypted, the new AMI only launches successfully on instances that support Amazon EBS encryption. 

33. In the navigation pane, choose Instances and select your instance. Choose Actions, Image, and Create Image. If this option is disabled, your instance isn't an Amazon EBS-backed instance.

34. You can convert an instance store-backed Linux AMI that you own to an Amazon EBS-backed Linux AMI.

35. You can't convert an instance store-backed Windows AMI to an Amazon EBS-backed Windows AMI and you cannot convert an AMI that you do not own.

36. AMIs that are backed by Amazon EBS snapshots can take advantage of Amazon EBS encryption. Snapshots of both data and root volumes can be encrypted and attached to an AMI.

37. The CopyImage action can be used to create an AMI with encrypted snapshots from an AMI with unencrypted snapshots.

38. You can create an AMI from a running Amazon EC2 instance (with or without encrypted volumes) using either the Amazon EC2 console or the command line

39. This scenario starts with an AMI backed by a root-volume snapshot (encrypted to key #1), and finishes with an AMI that has two additional data-volume snapshots attached (encrypted to key #2 and key #3). The CopyImage action cannot apply more than one encryption key in a single operation. However, you can create an AMI from an instance that has multiple attached volumes encrypted to different keys. The resulting AMI has snapshots encrypted to those keys and any instance launched from this new AMI also has volumes encrypted to those keys.

40. You can copy an Amazon Machine Image (AMI) within or across an AWS region using the AWS Management Console, the command line, or the Amazon EC2 API, all of which support the CopyImage action. Both Amazon EBS-backed AMIs and instance store-backed AMIs can be copied.

41. The source AMI can be changed or deregistered with no effect on the target AMI. The reverse is also true.

42. AWS does not copy launch permissions, user-defined tags, or Amazon S3 bucket permissions from the source AMI to the new AMI.

43. You can copy an AMI across AWS accounts. This includes AMIs with encrypted snapshots, but does not include encrypted AMIs.

44. You can't copy an encrypted AMI between accounts. Instead, if the underlying snapshot and encryption key have been shared with you, you can copy the snapshot to another account while re-encrypting it with a key of your own, and then register this privately owned snapshot as a new AMI.

45. When you launch an instance from an AMI, it resides in the same region where the AMI resides. If you make changes to the source AMI and want those changes to be reflected in the AMIs in the target regions, you must recopy the source AMI to the target regions.

46. When you first copy an instance store-backed AMI to a region, we create an Amazon S3 bucket for the AMIs copied to that region. All instance store-backed AMIs that you copy to that region are stored in this bucket. 

47. Prior to copying an AMI, you must ensure that the contents of the source AMI are updated to support running in a different region. For example, you should update any database connection strings or similar application configuration data to point to the appropriate resources. Otherwise, instances launched from the new AMI in the destination region may still use the resources from the source region, which can impact performance and cost.

48. Encrypting during copying applies only to Amazon EBS-backed AMIs. Because an instance-store-backed AMIs does not rely on snapshots, the CopyImage action cannot be used to change its encryption status.

49. The following table shows encryption support for various scenarios. Note that while it is possible to copy an unencrypted snapshot to yield an encrypted snapshot, you cannot copy an encrypted snapshot to yield an unencrypted one.

 

Scenario        Description    Supported

1          Unencrypted-to-unencrypted        Yes

2          Encrypted-to-encrypted      Yes

3          Unencrypted-to-encrypted Yes

4          Encrypted-to-unencrypted No 

 

50. You can deregister an AMI when you have finished using it. After you deregister an AMI, you can't use it to launch new instances.

51. When you deregister an AMI, it doesn't affect any instances that you've already launched from the AMI. 

52. When you deregister an Amazon EBS-backed AMI, it doesn't affect the snapshot that was created for the root volume of the instance during the AMI creation process. You'll continue to incur storage costs for this snapshot. Therefore, if you are finished with the snapshot, you should delete it.

53. When you deregister an instance store-backed AMI, it doesn't affect the files that you uploaded to Amazon S3 when you created the AMI. You'll continue to incur usage costs for these files in Amazon S3. Therefore, if you are finished with these files, you should delete them.

54. Micro instances can only be launched by with EBS volumes.

55. You can detach an EBS volume from an instance and attach it to another instance. But you cannot do the same with Instance store.

56. If your data can easily re-generated (and you are less worried about data loss, then you should use instance store backed instances).

57. If you want to create databases with high IO like nosql databases MongoDB, Cassandra etc. Then use Instance store backed SSD instance.