Disable an Amazon EC2 AMI

By Ashwin Venugopal -

 






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 launches in the EC2 console. For example, a disabled AMI does not appear in the AMI catalog in the launch instance wizard or when creating a launch template.

  • Launch services, such as launch templates and Auto Scaling groups, can continue to reference disabled AMIs. Subsequent instance launches from a disabled AMI will fail, so it is recommended to update launch templates and Auto Scaling groups to reference available AMIs only.

  • EC2 instances that were previously launched using an AMI that is subsequently disabled are not affected, and can be stopped, started, and rebooted.

  • You can't delete snapshots associated with disabled AMIs. Attempting to delete an associated snapshot results in the snapshot is currently in use error.

When an AMI is re-enabled:

  • The AMI's state changes to available, and it can be used to launch instances.

  • The AMI can be shared.

  • AWS accounts, organizations, and Organizational Units that lost access to the AMI when it was disabled do not regain access automatically, but the AMI can be shared with them again.

Costs

When you disable an AMI, it does not get deleted. If the AMI is backed by EBS, you'll still incur charges for the AMI's EBS snapshots. If you wish to retain the AMI, you may be able to lower your storage expenses by archiving the snapshots. For additional details, refer to the section on Archiving Amazon EBS snapshots in the Amazon EBS User Guide. If you decide against keeping the AMI and its snapshots, you need to deregister the AMI and remove the snapshots.

Prerequisites

To disable or re-enable an AMI, you must be the owner of the AMI.

Conclusion

 The method of how a disabled Amazon EC2 AMI works is discussed. 

 

 


































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