Scheduled drift detection has a floor: whatever interval you run it on is how long a change can sit unnoticed. Live drift removes that floor by inverting the direction of travel. Instead of a tool polling your account, your account tells the tool — CloudTrail records the API call, an EventBridge rule matches it, and an API destination forwards it. Because the traffic is outbound, the detector needs no additional permission in your account at all.

How the pipeline fits together

Four pieces, all of them in your account except the last:

CloudTrail  ──▶  EventBridge rule  ──▶  API destination  ──▶  drift detector
 (yours)          (yours)               (yours)                (InfraSync)

This is worth dwelling on before you build it, because it determines the security story. A polling design would need standing credentials that can read your account on a timer. A push design needs none: you decide what leaves, and deleting the rule ends the feed immediately without touching anything else.

Nothing in this guide grants a third party access to your account. Every credential created here belongs to you and points outward.

Step 0 — a CloudTrail trail must exist

This is the step almost everyone misses. EventBridge only receives AWS API Call via CloudTrail events when a trail exists in the account. Without one, every step below still succeeds, the console still shows a healthy rule with a valid target, and no event is ever generated. There is no error to find, because nothing failed — the events simply never existed.

A management-events trail in a single region is enough. It does not need to be multi-region and it does not need data events, which are the expensive ones.

InfraSync checks this for you and says so plainly rather than letting you assume the feature is running: it reads cloudtrail:DescribeTrails and cloudtrail:GetTrailStatus, both already covered by the read-only role you connected for scanning, and reports when no trail exists or a trail has stopped logging.

Step 1 — get your ingest token

In InfraSync, open the account's baseline screen and enable live drift. You get a token that is:

  • Shown once. Only a SHA-256 hash of it is stored, so it cannot be recovered — if you lose it, rotate it.
  • Bound to one AWS account. A token issued for account A cannot write drift into account B, whatever the payload claims.
  • Per account, not per region. The same token is used by every regional rule you create.

Step 2 — create the connection

The connection is where the token lives. EventBridge calls this "API key" auth, where the key name is really the header name:

aws events create-connection \
  --name infrasync-live-drift \
  --authorization-type API_KEY \
  --auth-parameters '{
    "ApiKeyAuthParameters": {
      "ApiKeyName": "Authorization",
      "ApiKeyValue": "Bearer PASTE_YOUR_TOKEN_HERE"
    }
  }'

Keep the literal Bearer prefix in the value. The endpoint parses a standard bearer token, and a bare token is rejected as unauthenticated.

Step 3 — create the API destination

aws events create-api-destination \
  --name infrasync-live-drift \
  --connection-arn <CONNECTION_ARN_FROM_STEP_2> \
  --invocation-endpoint https://i.infrasync.app/api/events/aws \
  --http-method POST \
  --invocation-rate-limit-per-second 50

The rate limit is a throttle on your side, and it matters more than it looks. A single large terraform apply can emit hundreds of write events in a few seconds; this bounds how fast EventBridge will fan them out.

Step 4 — let EventBridge invoke it

EventBridge needs its own role to call the destination. This role is yours and can do exactly one thing:

cat > eb-trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "events.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
JSON

aws iam create-role --role-name infrasync-eventbridge-invoke \
  --assume-role-policy-document file://eb-trust.json

aws iam put-role-policy --role-name infrasync-eventbridge-invoke \
  --policy-name invoke-infrasync \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": "events:InvokeApiDestination",
      "Resource": "<API_DESTINATION_ARN_FROM_STEP_3>"
    }]
  }'

Step 5 — create the rule

aws events put-rule \
  --name infrasync-live-drift \
  --event-pattern '{"detail-type":["AWS API Call via CloudTrail"]}'

aws events put-targets \
  --rule infrasync-live-drift \
  --targets '[{
    "Id": "infrasync",
    "Arn": "<API_DESTINATION_ARN_FROM_STEP_3>",
    "RoleArn": "<ROLE_ARN_FROM_STEP_4>"
  }]'

Repeat steps 2 to 5 in every region you want covered. EventBridge rules are regional, and CloudTrail delivers an event to the region where the API call was made — a rule in Mumbai will never see a change made in Ireland. Record the regions you covered in InfraSync so the interface can state your coverage explicitly instead of implying the whole account is watched.

Step 6 — silence your own pipeline

Do this before you turn alerts on, not after.

Your own Terraform pipeline is the single largest source of false positives. Every terraform apply is a write event, and none of it is drift.

Add your automation's role to the ignored principals list in InfraSync — the GitHub Actions OIDC role, Atlantis, Spacelift, whatever applies your code. Matching is done against both userIdentity.arn and sessionContext.sessionIssuer.arn, so an assumed-role session is matched by the role it came from and you do not need to enumerate sessions.

Skip this and your first deploy after enabling live drift reports itself as a wall of drift. The predictable outcome is that someone mutes the channel, and a muted channel detects nothing.

Controlling volume

The pattern in step 5 forwards every management API call, which is the version that reliably works everywhere. If that is more than you want, narrow by eventSource to the services you actually codify:

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com", "rds.amazonaws.com", "s3.amazonaws.com"]
  }
}

Do not try to filter read-only calls in the event pattern to save money. An event that omits the readOnly field will not match a false clause and gets silently dropped — you would lose real changes to save on noise. Read events are discarded on arrival anyway.

Verify it works

  1. Check trail health in InfraSync — no "no trail exists" warning.
  2. Make a harmless real change in a covered region: add a tag to a security group. Tagging is a write, so it passes the read-only filter.
  3. It should appear on your drift page within seconds, attributed to whoever made it.

If nothing arrives, check in this order, because this is roughly the order of likelihood: a trail exists at all → the rule is in the same region as the change → the connection's header value still has its Bearer prefix → the actor is not in your ignored principals.

Arriving events are also filtered on our side, and knowing what gets dropped saves you debugging the wrong thing. Read-only calls are discarded, failed calls are discarded (a denied API call changed nothing, so there is nothing to drift), and any event whose account does not match the account your token was issued for is rejected outright. That last check is the one that makes a shared endpoint safe: the account named in a payload is never trusted, only compared.

FAQ

Does this need write access to my account?

No — and not "no, only a little". Live drift adds no IAM permission whatsoever. Events are pushed out by EventBridge rather than pulled in, and the only related reads, confirming a trail exists and is logging, are already covered by the read-only role you connected for scanning.

My rule looks healthy but nothing arrives.

Almost always no CloudTrail trail. See step 0 — this failure mode is silent by construction, because the events that would have matched were never generated.

Will my Terraform pipeline show up as drift?

Yes, unless you exclude it. See step 6. Treat it as part of setup rather than tuning you will get to later.

Do I need this in every region?

In every region you want covered. Rules are regional and so is event delivery.

How is this different from scheduled drift detection?

Latency and attribution. A scheduled scan compares two states and tells you something differs; live drift carries the CloudTrail record, so it names the actor and the moment. The two complement each other — a scan catches changes that predate your setup or arrive through a path that emits no event, live drift catches everything else immediately. If you want the background on the scheduled half, see Terraform drift detection.

What if I rotate or lose the token?

Rotate it in InfraSync and update the connection from step 2 in each region. Only a hash is stored, so a lost token cannot be recovered — only replaced.