Instance Launch Behavior With Amazon EC2 Boot Modes

By Ashwin Venugopal -

 




About

When a computer starts up, the initial software it executes is tasked with setting up the platform and offering an interface for the operating system to carry out operations specific to the platform. Amazon EC2 supports two types of boot mode software: Unified Extensible Firmware Interface (UEFI) and Legacy BIOS.

Possible boot mode parameters on an AMI

An AMI can possess one of these boot mode parameter values: uefi, legacy-bios, or uefi-preferred. The boot mode parameter for an AMI is not mandatory. Instances launched from AMIs that lack a boot mode parameter will utilize the default boot mode value associated with the specific instance type.

Purpose of the AMI boot mode parameter

The AMI boot mode setting indicates to Amazon EC2 the boot mode to utilize during instance launch. When this parameter is configured to uefi, EC2 will try to start the instance using UEFI. If the operating system isn’t set up to support UEFI, the instance will fail to launch.

UEFI Preferred boot mode parameter

You can generate AMIs compatible with both UEFI and Legacy BIOS by utilizing the uefi-preferred boot mode parameter. When this boot mode parameter is configured to uefi-preferred, and the instance type is UEFI-compatible, the instance will boot in UEFI mode. Conversely, if the instance type lacks UEFI support, it will boot using Legacy BIOS.

Requirements to launch an EC2 instance in UEFI boot mode

The boot mode of an instance is influenced by the AMI configuration, the operating system within it, and the type of instance being used. To initiate an instance using UEFI boot mode, you need to fulfill the following criteria:

AMI

The AMI must be configured for UEFI as follows-

  • Operating system- The operating system contained in the AMI must be configured to use UEFI; otherwise, the instance launch will fail.

  • AMI boot mode parameter- The boot mode parameter of the AMI must be set to uefi or uefi-preferred.

  • Linux- The Amazon Linux 2023 and Amazon Linux 2 (Graviton instance types only) support UEFI. For other Linux AMIs, you must configure the AMI, import the AMI through VM Import/Export, or import the AMI through CloudEndure.

  • Windows- The Windows_Server-2025-* (except for AMIs with the BIOS- name prefix) and TPM-Windows_Server-2022-English-Full-Base support UEFI.

Determine the boot mode parameter of an Amazon EC2 AMI

The boot mode parameter for an AMI is not mandatory. An AMI may have a boot mode parameter set to either uefi, legacy-bios, or uefi-preferred. Some AMIs lack a boot mode parameter altogether. If an AMI does not include a boot mode parameter, the instances launched from that AMI will adopt the default setting based on the instance type, which is uefi for Graviton and legacy-bios for Intel and AMD instance types.

Determine the supported boot modes of an EC2 instance type

You can identify the boot modes that an instance type supports. The Amazon EC2 console does not show the supported boot modes for an instance type.

Determine the boot mode of an EC2 instance

The boot mode of an instance can be viewed in the Boot mode section of the Amazon EC2 console, as well as through the currentInstanceBootMode parameter in the AWS CLI. When an instance is started, its boot mode is set according to the boot mode parameter of the AMI from which it was launched.

Determine the boot mode of the operating system for your EC2 instance

The boot mode specified in the AMI informs Amazon EC2 about the boot mode to utilize when starting an instance. To determine if your instance's operating system is set up for UEFI, you must access your instance via SSH for Linux instances or RDP for Windows instances.

Set the boot mode of an Amazon EC2 AMI

By default, an AMI takes on the boot mode of the EC2 instance that was used to create it. If you generate an AMI from an EC2 instance that has a boot mode of UEFI preferred, the new AMI will also have a boot mode of UEFI preferred. When you register an AMI, you have the option to specify its boot mode as UEFI, legacy BIOS, or UEFI preferred.

If you configure the AMI boot mode to be UEFI-preferred, the operating system must be capable of booting in both UEFI and Legacy BIOS modes. To change an already existing Legacy BIOS-based instance to UEFI, or switch an existing UEFI-based instance to Legacy BIOS, you need to first adjust the instance's volume and operating system to accommodate the chosen boot mode. Next, create a snapshot of the modified volume. Finally, generate an AMI from that snapshot.

Considerations

  • Changing the AMI boot mode parameter does not automatically set up the operating system for that specified boot mode. You need to first modify the instance's volume and operating system appropriately to allow booting with the chosen boot mode. Failing to do so will render the AMI unusable. For instance, if you are switching a Windows instance from Legacy BIOS to UEFI, you can utilize Microsoft's MBR2GPT tool to convert the system disk from MBR to GPT. The required modifications depend on the specific operating system in use.

  • The register-image command or the Register-EC2Image cmdlet cannot be utilized to create an AMI that is compatible with both NitroTPM and UEFI Preferred.

  • Some features, like UEFI Secure Boot, are only available on instances that boot on UEFI. When you use the uefi-preferred AMI boot mode parameter with an instance type that does not support UEFI, the instance launches as Legacy BIOS and the UEFI-dependent feature is disabled. If you rely on the availability of a UEFI-dependent feature, set your AMI boot mode parameter to uefi.

Conclusion

The instance launch behavior  with Amazon EC2 boot modes is discussed with the help of above methods.













































































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