Deregister an Amazon EC2 AMI

By Ashwin Venugopal -

 







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 default, deregistering an AMI does not affect any snapshots created when the AMI was made. You will still accrue usage charges for these instances and storage fees for the snapshots. Thus, to prevent unnecessary expenses, we advise that you terminate any instances and remove any snapshots that are not needed. You can either delete the snapshots automatically when deregistering or do so manually afterward.

Considerations

You can't deregister an AMI that is not owned by your account.

You can't use Amazon EC2 to deregister an AMI that is managed by the AWS Backup service. Instead, use AWS Backup to delete the corresponding recovery points in the backup vault.

Deregister an AMI

You have the option to deregister both EBS-backed AMIs and instance store-backed AMIs. When deregistering EBS-backed AMIs, you may also choose to delete the corresponding snapshots concurrently. Nonetheless, if a snapshot is linked to other AMIs, it will remain intact even if you indicate that you want it deleted.

Avoid Costs From Unused Resources

Deregistering an AMI does not automatically remove all resources linked to the AMI. These resources consist of snapshots for EBS-backed AMIs and the files in Amazon S3 for instance store-backed AMIs. Additionally, when an AMI is deregistered, it does not stop or terminate any instances that were created from the AMI.

You will still be charged for the storage of snapshots and files, as well as for any active instances. To prevent incurring these unnecessary expenses, it is advisable to delete any resources that are no longer needed.

Protect an Amazon EC2 AMI From Deregistration

You can enable deregistration protection on an AMI to safeguard against accidental or malicious deletion. Once you enable this protection, the AMI cannot be deregistered by any user, irrespective of their IAM permissions. To deregister the AMI, you must first disable the deregistration protection.

When you enable deregistration protection on an AMI, you have the option to set a 24-hour cooldown period. This cooldown period refers to the duration during which deregistration protection stays active after you disable it. Throughout this cooldown timeframe, the AMI is not allowed to be deregistered. After the cooldown period concludes, the AMI can be deregistered. By default, deregistration protection is off for all current and newly created AMIs.

Turn off Deregistration Protection

If you opted to set a 24-hour cooldown period when enabling deregistration protection for the AMI, then upon disabling deregistration protection, you won’t be able to deregister the AMI right away. The cooldown period is the 24-hour interval during which deregistration protection is still active even after you switch it off. During this cooldown interval, the AMI cannot be deregistered. Once the cooldown period concludes, the AMI becomes eligible for deregistration.

Conclusion

Some features of deregistering a Amazon EC2 AMI are discussed above. 







 

 





























Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more