How AMI Store & Restore Works?

By Ashwin Venugopal -

 




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 occurred.

The duration required to finish the task is influenced by the size of the AMI. Additionally, it is affected by the number of other tasks currently running, as tasks are processed in a queue. You can monitor the status of the task by using the DescribeStoreImageTasks API.

DescribeStoreImageTasks

The DescribeStoreImageTasks API provides information about the status of AMI storage tasks. You can retrieve details for specific AMIs, or if no AMIs are provided, you will receive a paginated list of all store image tasks that have been completed in the past 31 days. For each AMI task, the response will indicate whether the task is InProgress, Completed, or Failed. For tasks that are InProgress, the response will present an estimated progress percentage. Tasks are displayed in reverse chronological order. Currently, only tasks from the last month are accessible for viewing.

CreateRestoreImageTask

The CreateRestoreImageTask API initiates a process that retrieves an AMI from an S3 object that was previously generated through a CreateStoreImageTask request.

The restoration task can take place in the same Region as the storage task or in a different one.

The S3 bucket from which the AMI object will be restored must reside in the same Region where the restore operation is requested.

The AMI will be retrieved in this specified Region. The restoration includes the AMI's metadata, including its name, description, and block device mappings that correspond to those of the stored AMI. The name must be unique among AMIs in this Region for the given account. If a name is not provided, the new AMI will adopt the same name as the original. At the time of the restoration procedure, the AMI is assigned a new AMI ID.

File paths

You can use file paths when storing and restoring AMIs, in the following way:

  • When storing an AMI in S3, the file path can be added to the bucket name. Internally, the system separates the path from the bucket name, and then adds the path to the object key that is generated to store the AMI. The full object path is shown in the response from the API call.

  • When restoring the AMI, because an object key parameter is available, the path can be added to the beginning of the object key value.

 Conclusion

The methods of storing and restoring AMI are 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