# Cross-region shard epidemic

Erasure shards use **regional S3 keys** and **fleet gossip** so seeders prefer same-region peers before cross-region recovery.

## S3 object layout

- Key: `shards/{token}/{region}/{index}-{shard_hash}.bin`
- Metadata: `region`, `shard-index`, `token`, `shard-hash`, `shard-advert` (`region:shard_index`)

## Gossip

`have_shard` records include `region` and `shard_advert` (`us-east-1:2`). Agents rank peers: LAN → same region → other regions → CloudFront → C2.

## CRR (operator-applied)

1. Set in `data/config.json` under `server`:
   - `aws_s3_shard_bucket`, `aws_s3_shard_region`
   - `aws_s3_crr_dest_bucket`, `aws_s3_crr_dest_region`
   - `aws_s3_replication_role_arn` (optional)
   - `aws_cloudfront_domain` (edge fetch before C2)
2. Fetch generated rule: `GET /api/v1/spread/aws-s3-crr-template`
3. Apply the JSON to the **source** bucket replication configuration (AWS console or CLI).
4. Standalone template reference: `templates/spread/aws/s3-crr-rule.json`

No server-side AWS API calls are made; the operator owns IAM and replication setup.

## Agent region

Agents resolve region from EC2 IMDS (`placement/region`), falling back to `aws_s3_shard_region` in `spread_policy` at auth.