Amazon EC2 AMI Lifecycle (Part 2)

By Ashwin Venugopal -

 How to launch AWS Ec2 Instance | 2024




Create an Amazon EBS-backed AMI

You can generate your own Amazon EBS-backed AMI from an Amazon EC2 instance or a snapshot of the root volume of an Amazon EC2 instance. To generate an Amazon EBS-backed AMI from an instance, begin by launching an instance using an existing Amazon EBS-backed AMI. This AMI could be one sourced from the AWS Marketplace, made through VM Import/Export, or any other AMI that you have access to. After you modify the instance to suit your particular needs, create and register a new AMI. You can then utilize the new AMI to launch additional instances with your modifications. The AMI creation process is different for instance store-backed AMIs.

Overview of AMI creation from an instance

The steps below outline how to create an Amazon EBS-backed AMI from an active EC2 instance: Begin with an existing AMI, start an instance, personalize it, generate a new AMI from that instance, and ultimately launch an instance using your newly created AMI.

AMI #1: Start with an existing AMI- Find an existing AMI that is similar to the AMI that you'd like to create. This can be an AMI obtained from the AWS Marketplace, an AMI created using VM Import/ Export, or any other AMI that you can access.

Launch instance from existing AMI- The way to configure an AMI is to launch an instance from the AMI on which you'd like to base your new AMI, and then customize the instance. Then, you'll create a new AMI that includes the customizations.

EC2 instance #1: Customize the instance- Connect to your instance and customize it for your needs. Your new AMI will include these customizations. You can perform any of the following actions on your instance to customize it:

Install software and applications

Copy data

Reduce start time by deleting temporary files and defragmenting your hard drive

Attach additional EBS volumes

Create image- When you create an AMI from an instance, Amazon EC2 powers down the instance before creating the AMI to ensure that everything on the instance is stopped and in a consistent state during the creation process. During the AMI-creation process, Amazon EC2 creates snapshots of your instance's root volume and any other EBS volumes attached to your instance. Depending on the size of the volumes, it can take several minutes for the AMI-creation process to complete (sometimes up to 24 hours). You might find it more efficient to create snapshots of your volumes before creating your AMI. This way, only small, incremental snapshots need to be created when the AMI is created, and the process completes more quickly (the total time for snapshot creation remains the same).

AMI #2: New AMI- After the process completes, you have a new AMI and snapshot created from the root volume of the instance. If you added instance-store volumes or EBS volumes to the instance, in addition to the root device volume, the block device mapping for the new AMI contains information for these volumes.

Launch instance from new AMI- You can use the new AMI to launch an instance.

EC2 instance #2: New instance- When you launch an instance using the new AMI, Amazon EC2 creates a new EBS volume for the instance's root volume using the snapshot. If you added instance-store volumes or EBS volumes when you customized the instance, the block device mapping for the new AMI contains information for these volumes, and the block device mappings for instances that you launch from the new AMI automatically contain information for these volumes. The instance-store volumes specified in the block device mapping for the new instance are new and don't contain any data from the instance store volumes of the instance you used to create the AMI. The data on EBS volumes persists.

When you create a new instance from an EBS-backed AMI, you should initialize both its root volume and any additional EBS storage before putting it into production.

Conclusion

Amazon EBS-backed AMI is created 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