Skip to main content
Hilt never holds credentials in your accounts. You create IAM roles with CloudFormation, Hilt assumes them on demand, and deleting the stack revokes everything immediately. There are only two roles, and one CloudFormation stack usually creates both.

Which stack do I deploy?

I have an AWS Organization

Deploy one stack in your management account. It creates both roles and a StackSet that adds HiltCloudConnectRole to every current and future member account automatically.

I have one or a few accounts

Deploy the per-account stack in each account. No organization, no StackSet, no management-account access needed.
Both paths start from the same place in the dashboard: Settings → Integrations → AWS accounts. Each button opens CloudFormation pre-filled — you sign in as yourself, review, and click Create. Hilt never receives your credentials.
Organizations only, one-time: StackSets need trusted access enabled. The CloudFormation console offers to turn it on while you create the stack, or run aws cloudformation activate-organizations-access once.

What HiltCloudConnectRole can do

Optional: the connectivity permissions

Only present if you use PrivateLink to give agents a path to the collector:
Different regions are fine. Since November 2024 AWS PrivateLink connects across regions: your VPC in one region can reach Hilt’s ingest service in another, and the endpoint’s network interfaces stay local to your VPC. Hilt enables your region on its service automatically the first time you connect from it - nothing for you to do.

What it cannot do

It cannot touch IAM, open interactive SSM sessions, stop or terminate instances, read object storage, or modify any security group you own — quarantine and endpoint groups are tag-scoped, and Hilt creates those itself.

What HiltCloudConnectOrgRole can do

Two read-only actions, and nothing else:
It exists only so Hilt can enumerate your accounts and keep up as you add new ones. It has no access to EC2, SSM, or any member account.

How the trust works

Both roles pin three things at once. All three must match or the assume fails:
  1. Your Hilt deployment’s account — nobody else’s
  2. The exact backend role ARN in that account — not any role
  3. An ExternalId unique to your deployment, shown in the dashboard
Every action Hilt takes arrives in your CloudTrail stamped with the Hilt user who triggered it, so a fleet install or a quarantine is always attributable to a person.

Who needs what to deploy

The per-account stack: permission to create a CloudFormation stack and a named IAM role in that account. The organization stack needs more, because it also creates a StackSet. An organization admin already has all of this; if you scope a role for it, this is the minimum:
The three service-linked-role paths are easy to miss. ActivateOrganizationsAccess checks whether the role exists before creating it, and when it does not yet exist AWS authorizes against the name without the aws-service-role/ path — so granting only the pathed form fails with an iam:GetRole denial that does not explain itself.
This is only what your operator needs to run the stack once. It is not access granted to Hilt. Once the stack exists, the management account is not involved again.

Updating an existing deployment

When Hilt adds a permission — the connectivity grants above, for example — accounts created from an older stack keep working, but the new feature stays greyed out until the stack is refreshed. With an organization, this is one action, not one per account. Update the StackSet and CloudFormation pushes the new template to every member account:
Pass --operation-preferences explicitly. The original rollout sets a failure tolerance in its template, but update-stack-set does not inherit it — it defaults to zero, so a single account that cannot update (one that already had the role from an earlier per-account stack, say) cancels the rollout for every account with Cancelled since failure tolerance has exceeded.
Without an organization, re-run the per-account stack in each account. Updating an existing stack in place is enough; you do not need to delete it first.

Removing access

Delete the CloudFormation stack. The roles go with it and Hilt loses all access immediately — no support ticket, no waiting. For an organization, delete the StackSet’s stack instances first, then the stack that created it.
Last modified on October 8, 2026