⚠️ Limits & Differences vs Amazon S3

Limits

Limit	Value
Max object size	5 GiB
Max parts per multipart upload	10,000
Request rate	Per-account rate limiting; exceeding it returns 503 SlowDown (retried automatically by AWS SDKs)
Clock skew	Requests dated >15 min from server time are rejected (RequestTimeTooSkewed) — sync your clock via NTP
Keypairs	One active S3 keypair per Lighthouse account

Behavioral differences

• Delete ≠ erase. Deleting removes the key from the API; the content remains on IPFS/Filecoin and stays fetchable by CID. Read S3 and IPFS Semantics — this matters for sensitive data.
• No IAM / bucket policies. Access control is per keypair: your keys see your buckets, nothing else. There are no public buckets — use presigned URLs or share CIDs via IPFS gateways for public access.
• Bucket names are first come, first served across all users. Prefix them with your project name.
• CompleteMultipartUpload latency scales with object size — parts are assembled into one content-addressed object (one CID) at completion. Very large multipart uploads take longer to finalize than on Amazon S3.
• Storage class is always STANDARD in listings; the actual persistence layer is IPFS + Filecoin deals.
• Region is nominal. us-east-1 is advertised for SigV4 compatibility; data lives on the Lighthouse/IPFS/Filecoin network, not in an AWS region.

Billing

Uploads through the S3 API are billed to your Lighthouse account — the same plan and quota as SDK/API uploads. Check your usage on the Lighthouse dashboard or via the quota API if available on your plan.

Errors you might see

Code	Cause	Fix
SignatureDoesNotMatch	Wrong secret key, or a proxy altered the request	Re-check credentials
InvalidAccessKeyId	Unknown or revoked access key	Check your keys
RequestTimeTooSkewed	Local clock off by >15 min	Enable NTP
BucketAlreadyExists	Name taken by another account	Pick a prefixed name
EntityTooLarge	Object over the size cap	Split the data
SlowDown (503)	Rate limit	Back off; SDKs retry automatically