As the hosting operator, guide your customer through Reboot only after agreeing the interruption and application fallback with the application owner. PD AWS ElastiCache’s normal offering has one primary node; a reboot is not an automatic failover to another node.

Prepare the application

Open the active service and confirm its cache and AWS region. Review what the application stores there and how it will behave if cached values disappear. AWS documents that the reboot operation loses the contents of the affected cache nodes. Arrange any required recovery point and application fallback before continuing; keep an independent recovery source for important data rather than relying on cache contents surviving reboot.

Customer steps: request one reboot

1. Open the service’s Overview.
2. Choose Reboot where your hosting business makes it available.
3. Read the confirmation and proceed only when the application is prepared.
4. Follow the request under Activity.
5. Check the resulting cache state and application behaviour before making another change.

The module can queue work while AWS completes an operation. A Done entry can mean the provider accepted the reboot rather than that the cache has returned to service. Check readiness and application results separately.

Understand what reboot does

The module asks AWS to reboot the member cache node or nodes. ElastiCache does not offer Start and Stop through this module, and reboot does not cancel the billing service or stop provider charges. If a control is unavailable, your hosting team should check the original service configuration and actual cache/member-node state; a direct endpoint is not a substitute for its offered control.

If the outcome is uncertain, compare the original Activity request with the affected member node in your AWS account. Follow a reboot still processing rather than repeating it to refresh its status.

See the PD AWS ElastiCache WHMCS guide for related tasks, or explore PD AWS ElastiCache.