VMware Cloud on AWS: Auto Remediation and Planned Maintenance Notification Updates

New notifications have been added to the VMware Cloud on AWS Autoscaler Service. Updates will now automatically be sent for Auto Remediation and Planned Maintenance services to give customers more transparency around when and why hosts are swapped out.


In a previous article, I wrote about Auto Remediation with VMware Cloud on AWS and how the Autoscaler Service works to remediate hosts within the SDDC. This is a fantastic feature, exclusive to the service, that helps auto-heal the environment and keeps your SDDC healthy and performant. And it keeps getting better, as we explore below.

We’ve introduced new notifications as part of the service, to help customers with:

  • Auto Remediation: triggered due to a host, component, or disk failure
  • Planned Maintenance: triggered due to an AWS scheduled retirement event

While the Autoscaler Service runs in the background and automatically mitigates failures, it’s not always clear to customers why hosts are added or removed. For billing purposes, customers often watch the number of hosts that are being added or removed from their SDDCs, and they’d like to know when and why these hosts are swapped out. The new notifications bridge this gap.


Customers will now receive notifications when the following events occur:

  1. A non-transient failure occurs on a host in their SDDC
  2. An AWS scheduled maintenance event has been received for a host in their SDDC 
  3. A host has been replaced due to a non-recoverable error
  4. A host has been successfully remediated and is still part of their SDDC


During Planned Maintenance, the customer will see when the task has started, the provisioning of a new ESXi host, the old ESXi host’s removal, and that the task was successful. The host replacement details are shared, too.

Similarly, during the auto-remediation of a host with a non-recoverable error, the customer will see that a host issue was detected, the provisioning of a new ESXi host, the removal of the problematic ESXi host, and a summary that the task was successful. Again, host replacement details are outlined.

In the last scenario, it’s possible that we can remediate the host instead of replacing it. In the Activity Log, we will see similar tasks – a host issue being detected and the addition of an ESXi host. However, if the host is remediated, we will remove the ESXi host that we added, and specify that we were able to remediate the existing host and leave it in the cluster.

Remember, the Autoscaler Service has always performed these actions in the background. The goal of this new notification mechanism is to provide greater insight and transparency into some of the operations that occur within the SDDC.




About the Authors

Jeremiah Megie

Sr. Technical Marketing Architect at VMware

Jeremiah Megie is a Senior Technical Marketing Architect working for VMware. He is responsible for providing education, evangelism, and generating content for VMware Cloud on AWS. Prior to joining VMware, Jeremiah was a Senior Solutions Architect specializing in the design and implementation of vSphere, converged & hyper-converged infrastructure, and disaster recovery with VMware Site Recovery Manager. He has more than 20 years of experience in the IT field where he has held many data center and virtualization based roles ranging from administration and engineering to architecture and leadership; with a background spanning multiple industries including DoD, financial, energy, professional services, and managed services. Jeremiah currently holds numerous certifications including multiple VCPs, VCAPs, and VCIX as well as the VMware vExpert designation. He can be found on Twitter at @vMegie.

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts