Updating Your Quick Start Stack

Runless is expanding beyond ECS to other AWS resource types (RDS, EC2, Auto Scaling Groups, EKS, and more). Each resource type is opt-in and requires updating the Quick Start stack in the linked AWS account.

Why an update is needed

The customer-side Quick Start stack grants the Runless cross-account role only the IAM permissions it needs. As new resource types become available, the stack adds a new Enable<ResourceType> parameter (for example EnableEcs, EnableRds) for each one. Permissions for a resource type are only granted when its parameter is set to true.

This means:

  • Existing permissions never change silently - you control what Runless can access.
  • New capabilities are invisible to your account until you update the stack and opt in.
  • You can disable a resource type at any time by setting its parameter back to false and updating the stack.

Checking your stack version

Your linked connection's card in the dashboard shows the Quick Start stack version it last reported, plus a Stack update available badge when a newer stack template exists. The dashboard compares the version reported at linking time against the version Runless currently ships.

How to update

Updating the stack does not affect resources Runless is already managing - in-flight schedules keep running.

  1. Open the AWS CloudFormation console for the account shown on the connection card.
  2. Select the Runless onboarding stack and choose Update.
  3. Use the latest Quick Start template (same source you used to originally launch it).
  4. Review the parameters: existing Enable* parameters keep their current values by default, so nothing you didn't opt into gets enabled by accident. Set any new Enable* parameter to true if you want to use that resource type.
  5. Deploy the update and wait for UPDATE_COMPLETE.
  6. Return to the Runless dashboard - the connection's stack version status updates the next time it verifies or refreshes inventory.

What each Enable* parameter grants

ParameterResource typeGrants
EnableEcsECS servicesList/describe clusters and services, update service desired count, read Application Auto Scaling targets, forward ECS state-change events
EnableEc2EC2 instancesDescribe instances and instance status; start/stop instances tagged runless:managed=true; forward EC2 instance state-change events so the dashboard reflects console-initiated and settled (stopped/running) transitions

Additional Enable* parameters (EnableRds, EnableAsg, EnableEks, ...) are added as each resource type ships - see the Application Manual for what's currently supported.

Next Steps

  1. Application Manual - Configure schedules and runtime controls
  2. Rules - Review how cost-saving rules apply per resource