Blogs by Ashwin

  About When you deregister an AMI, it is permanently removed from Amazon EC2. Once an AMI is deregistered, it can no longer be used to launch new instances. You might want to deregister an AMI after you have finished using it. To safeguard against accidental or intentional deregistration of an AMI, you can enable protection. If you mistakenly deregister an EBS-backed AMI, you have the option to use the deregistration Recycle Bin to restore it, provided you do so within the specified time frame before it is permanently deleted. When you deregister an AMI, you have the option to delete its associated snapshots simultaneously. However, if a snapshot is linked to several AMIs, it will not be removed even if you choose to delete it; the AMI will still be deregistered. Any snapshots that are not deleted will still result in ongoing storage charges. Deregistering an AMI does not impact any instances that were started from it. You can still operate these instances without any issues. By d...

  About You can deactivate an AMI to stop it from being utilized for instance launches. Launching new instances from a deactivated AMI is not possible. A disabled AMI can be reactivated, allowing it to be used again for instance launches. Both public and private AMIs can be deactivated. To lower storage expenses for infrequently used disabled EBS-backed AMIs that must be kept long-term, you can archive their related snapshots. How AMI disable works? When an AMI is disabled: The AMI's state changes to disabled. A disabled AMI can't be shared. If an AMI was public or previously shared, it is made private. If an AMI was shared with an AWS account, organization, or Organizational Unit, they lose access to the disabled AMI. A disabled AMI does not appear in DescribeImages API calls by default. A disabled AMI does not appear under the Owned by me console filter. To find disabled AMIs, use the Disabled images console filter. A disabled AMI is not available to select for instance launc...

  Introduction You can mark an AMI as deprecated to show that it is outdated and should be avoided. Additionally, you can set a future date for the deprecation of an AMI, signaling when it will no longer be considered up to date. After an AMI is deprecated: For AMI users, the deprecated AMI does not appear in DescribeImages API calls unless you specify its ID or specify that deprecated AMIs must appear. AMI owners continue to see deprecated AMIs in DescribeImages API calls. For AMI users, the deprecated AMI is not available to select via the EC2 console. For AMI users, if you know the ID of a deprecated AMI, you can continue to launch instances using the deprecated AMI by using the API, CLI, or the SDKs. Launch services, such as launch templates and Auto Scaling groups, can continue to reference deprecated AMIs. EC2 instances that were launched using an AMI that is subsequently deprecated are not affected, and can be stopped, started, and rebooted. You can deprecate both priva...

  Introduction When you save an AMI in an S3 bucket, a task for storing the image is initiated. This store image task allows you to track the progress and result of the procedure. Securing your AMIs It is crucial to verify that the S3 bucket is set up with adequate security to protect the content of the AMI and that this security is upheld for the entire duration that the AMI objects are stored in the bucket. If this cannot be achieved, it is advisable to refrain from using these APIs. Make sure that public access to the S3 bucket is prohibited. It is suggested to activate Server-side encryption for the S3 buckets where you keep the AMIs, even though it’s not mandatory. When AMI snapshots are transferred to the S3 object, they are sent over TLS connections. It is possible to save AMIs that contain encrypted snapshots; however, the snapshots will be decrypted during the storing process. Identify the source AMI used to create a new Amazon EC2 AMI You can determine the AMI that was us...

  CreateStoreImageTask The CreateStoreImageTask API stores an AMI as a single object in an S3 bucket. The API initiates a task that collects all the data from the AMI and its associated snapshots, subsequently using an S3 multipart upload to store this data in an S3 object. It gathers all elements of the AMI, including most of the non-Region-specific metadata and all EBS snapshots included in the AMI, and consolidates them into a single object in S3. During the upload process, the data is compressed to minimize the space utilized in S3, which means that the S3 object could be smaller than the total sizes of the snapshots in the AMI. If the account making this API call has access to AMI and snapshot tags, they will be retained. The S3 object shares the same ID as the AMI, except it has a .bin extension. Additionally, the S3 metadata tags for the object include the AMI name, AMI description, AMI registration date, AMI owner account, and a timestamp indicating when the store operation...

  Store and restore an AMI using S3 You have the ability to save an Amazon Machine Image (AMI) in an Amazon S3 bucket, transfer the AMI to a different S3 bucket, and subsequently restore it from there. By utilizing S3 buckets to store and retrieve an AMI, you can move AMIs between various AWS partitions, such as from the primary commercial partition to the AWS GovCloud (US) partition. Additionally, you can create backup copies of AMIs by keeping them in an S3 bucket. Use cases Use the store and restore APIs to do the following: Copy an AMI between AWS partitions- By storing and restoring an AMI using S3 buckets, you can copy an AMI from one AWS partition to another, or from one AWS Region to another. Make archival copies of AMIs- You can make archival copies of AMIs by storing them in an S3 bucket. The AMI is packed into a single object in S3, and all of the AMI metadata (excluding sharing information) is preserved as part of the stored AMI. The AMI data is compressed as part of th...

  Resource permissions To duplicate an AMI that has been shared with you from a different account, the owner of the original AMI needs to provide you with read access to the storage that supports the AMI, not merely for the AMI itself. This storage could be the linked EBS snapshot (for an Amazon EBS-backed AMI) or an associated S3 bucket (for an instance store-backed AMI). If the AMI being shared includes encrypted snapshots, the owner must also share the encryption key or keys with you. Time-based AMI copy operations When you commence a time-based AMI copy process for an EBS-backed AMI that has one associated snapshot, it operates similarly to an individual time-based snapshot copy process, and the same constraints on throughput are enforced. When you start a time-based AMI copy operation for an EBS-backed AMI that has multiple associated snapshots, it functions similarly to simultaneous time-based snapshot copy operations, and the same throughput restrictions are enforced. Each a...

  How Amazon EC2 AMI copy works? Creating a copy of a source AMI produces a new AMI that is identical but distinct, commonly known as the target AMI. The target AMI comes with its unique AMI ID. Modifying or deregistering the source AMI will not impact the target AMI. Likewise, changes to the target AMI have no effect on the source AMI. When using an EBS-backed AMI, each of its underlying snapshots is replicated to a separate but identical target snapshot. When an AMI is copied to a different Region, the snapshots created are complete copies, not incremental ones. If you choose to encrypt unencrypted backing snapshots or change them to a new KMS key, the resulting snapshots will also be complete copies rather than incremental ones. Any further copy operations of an AMI will yield incremental copies of the associated snapshots. Cross-Region copying Copying an AMI across geographically diverse Regions provides the following benefits: Consistent global deployment: Copying an AMI from...

  Copy an Amazon EC2 AMI When it's necessary to maintain a uniform configuration for Amazon EC2 instances across different Regions, you can utilize a single Amazon Machine Image (AMI) as your base template for launching all instances. However, it's important to note that AMIs are specific to each Region, if you want to launch an instance in a particular AWS Region, the AMI must reside within that Region. Consequently, to employ the same AMI across multiple Regions, you need to copy it from the original Region to each desired target Region. The method you use to copy an AMI depends on whether you're copying across Regions within the same partition or across different partitions: Cross-Region copying- Copy AMIs across Regions within the same partition, for example, across the Regions within the commercial partition. Cross-partition copying- Copy AMIs from one partition to another partition, for example, from the commercial partition to the AWS GovCloud (US) partition. Cross-...

  Create an Amazon EC2 AMI using Windows Sysprep The Microsoft System Preparation (Windows Sysprep) tool produces a generalized version of the operating system by removing instance-specific system configurations before capturing a new image. It is advisable to utilize EC2 Image Builder to automate the processes of creating, managing, and deploying customized, secure, and current "golden" server images that have software and settings pre-installed and configured. Additionally, you can use Windows Sysprep to generate a standardized AMI by employing the Windows launch agents. Windows Sysprep phases Windows Sysprep runs through the following phases: Generalize: The Sysprep utility eliminates information and configurations that are specific to an image. For instance, Windows Sysprep eliminates the security identifier (SID), the device name, the event logs, and certain drivers, among others. Once this process is finished, the operating system (OS) is prepared to generate an AMI. Sp...