In the in-account shape the scan runs where your data already is. The scanner uses an identity you control, reads through the provider’s own API inside your account, and sends TigerGate a findings document. No object contents, no rows and no credential cross the boundary.

​
1. Mint an enrollment token

In the console, go to Data Security → Scan Configuration, open the account, set How this account is scanned to In-account, and mint an enrollment token. It is shown once. The scanner validates it before enumerating anything, so a wrong or revoked token fails in milliseconds rather than after a full scan you would be billed for.

​
2. Mirror the image

The scanner task pulls from a registry your own account can reach: 
docker pull tigergate/tigergate-dspm-agent:1.0.0
docker tag  tigergate/tigergate-dspm-agent:1.0.0 <your-registry>/tigergate-dspm-agent:1.0.0
docker push <your-registry>/tigergate-dspm-agent:1.0.0
Both linux/amd64 and linux/arm64 are published.

​
3. Deploy

Each module takes the same shape: run once, or run on a schedule.
A Fargate task triggered by EventBridge. For estates too large for Fargate’s ceiling, set compute_mode = "ec2" and the module provisions an autoscaling group that sits at zero when idle.
module "dspm" {
  source = "./aws/terraform"

  organization_id  = "<from the console>"
  enrollment_token = var.enrollment_token
  scanner_image    = "<your-ecr>/tigergate-dspm-agent:1.0.0"

  subnet_ids        = ["subnet-a", "subnet-b"]
  security_group_id = "sg-xxxx"

  scan_regions = ["us-east-1", "ap-south-1"]
  run_mode     = "scheduled"
  schedule     = "rate(24 hours)"
}
The task role is created by the module with read-only permissions. Content reads are gated on content_scan_buckets — an empty list means the role cannot read an object even if the scanner were asked to.
CloudFormation and ARM equivalents ship alongside the Terraform modules if you prefer them.

​
4. Run one and confirm

terraform apply
terraform output run_once_command
The first log line proves the token works: 
[inaccount] enrollment valid: org=… account=…
Then in the console, Scan Configuration shows merged / in flight / parked / last merged for the account. last merged: never means nothing has landed yet.
Set the Expected reporting interval on the account to match the schedule you configured. TigerGate cannot start your scanner, so this is what lets the console tell you it has gone quiet rather than silently showing a stale estate.

​
Where reports go

Nothing to configure for the US region — it is the default. 
tigergate_region = "eu1"

report_endpoint = "https://staging.internal/api/dspm/reports"
An explicit URL wins over the region, and the scanner says so at startup rather than quietly preferring one. http:// is rejected except on localhost: a findings document is not your data, but it names every store you hold and what is wrong with each.

​
Database access

Relational stores need a database user to connect as. Set it in your Terraform — the console cannot reach a scanner running in your account: 
db_user       = "tigergate_dspm"
db_secret_arn = "arn:aws:secretsmanager:..."
Prefer IAM database authentication where the engine supports it. There is then no password to store, rotate or leak.

​
Sizing

Do not guess. Run once and read the verdict — the scanner measures the work and says what it needed: 
[inaccount] compute: 167.0 MiB across 24 store(s); about 1m on the current 1 vCPU
[inaccount] COMPUTE UNDERSIZED (ec2): 40.0 TiB across 500 store(s) needs about
            500 vCPU / 1000 GiB, beyond Fargate's 16 vCPU / 120 GiB ceiling
The same verdict travels in the report’s coverage.compute block, so partial coverage always says why. Most estates never need EC2.

​
Cost

Scans are incremental. A store is re-read only where objects changed since the last run, and a store too large for one budget is covered across runs rather than re-reading the same slice every night. run_mode = "once" costs a single task execution. Start there.