Deregistering a Registered Instance - AWS OpsWorks

Deregistering a Registered Instance

Important

The AWS OpsWorks Stacks service reached end of life on May 26, 2024 and has been disabled for both new and existing customers. We strongly recommend customers migrate their workloads to other solutions as soon as possible. If you have questions about migration, reach out to the AWS Support Team on AWS re:Post or through AWS Premium Support.

You can deregister an instance using the AWS OpsWorks console, AWS CLI, or SDK operation.

To deregister an instance using the console

  1. In the navigation pane, choose Instances.

  2. Choose the instance that you want to deregister.

  3. On the Details page for the instance, choose Deregister.

    deregister an instance on the instance's details page

To deregister an instance using the AWS CLI

Run the aws opsworks deregister-instance command to deregister an instance from its stack.

aws opsworks deregister-instance --region region --instance-id instance-id

When you deregister an instance, AWS OpsWorks Stacks does the following:

  • Removes the instance from the stack.

  • Unassigns the instance from any assigned layers.

  • Shuts down and uninstalls the agent.

  • Deregisters any attached resources (Elastic IP addresses and Amazon EBS volumes).

    This procedure includes resources that were attached to the instance prior to registration, and resources that you used AWS OpsWorks Stacks to attach to the instance while it was part of the stack. After deregistration, the resources are no longer part of the stack's resources, but they remain attached to the instance.

  • For on-premises instances, stops the charges.

  • Removes all tags that OpsWorks added to the instance.

The instance remains in the running state, but it is under your direct control and is no longer managed by AWS OpsWorks Stacks.

Note

Both registering and deregistering computers or instances are fully supported only within Linux stacks. For Windows stacks, deregistering instances is allowed, but it doesn’t uninstall the OpsWorks agent from the instance. Deregistration does not remove all changed files, and does not fully revert to backed-up copies of certain files. This list applies to both Chef 11.10 and Chef 12 stacks; differences between the two versions are noted here.

  • /etc/hosts is backed up to /var/lib/aws/opsworks/local-mode-cache/backup/etc/, but is not restored.

  • Entries remain for aws and opsworks in passwd, group, and shadow files, etc.

  • /etc/sudoers contains a reference to an AWS OpsWorks Stacks directory.

  • The following files are safe to leave behind; long-term, consider deleting /var/lib/aws/opsworks.

    • /var/log/aws/opsworks remains on instances in Chef 11.10 stacks.

    • /var/lib/aws/opsworks remains on both Chef 11.10 and Chef 12 stacks.

    • /var/chef remains on instances in Chef 12 stacks.

  • Other files left behind:

    • /etc/logrotate.d/opsworks-agent

    • /etc/cron.d/opsworks-agent-updater

    • /etc/ld.so.conf.d/opsworks-user-space.conf

    • /etc/motd.opsworks-static

    • /etc/aws/opsworks

    • /etc/sudoers.d/opsworks

    • /etc/sudoers.d/opsworks-agent