Large file upload on s3

-how pre-signed url works?

When a client wants to upload a large file, I don’t want it going through my backend server — that wastes bandwidth and makes my server a bottleneck. Instead, my backend generates a presigned URL: using AWS credentials it already holds, it locally signs a URL that grants time-limited, scoped permission to upload directly to a specific S3 object path — no network call to AWS needed to create it, it’s pure local cryptographic signing. The client never sees my AWS credentials, which is important for security. I return that URL to the client, and they upload the file directly to S3, bypassing my server entirely. S3 verifies the signature itself when the upload request comes in, and rejects it if it’s expired or tampered with

-chunks - how to control chunk data so that user does not change it (padhna h)

-s3 notification delivered via SQS or directly invoking a Lambda (note also send the key/path generated)

“How to stop the user from tampering with a chunk”

Each uploaded part returns an ETag that S3 itself computes (an MD5-style hash of that part’s bytes) — the client doesn’t get to set this

• On CompleteMultipartUpload, you submit the list of (partNumber, ETag) pairs — S3 checks each against what it actually stored. A corrupted or swapped part fails completion, not silently accepted
• For stronger guarantees, S3 supports client-supplied checksums (SHA-256, CRC32C) verified server-side — catches silent bit-rot in transit, not just accidental mismatches
• Worth separating two different protections here: the presigned URL’s signature stops someone from redirecting the upload to a different object or using an expired grant; the ETag/checksum stops the content itself from being tampered with or corrupted mid-transit. Different attack surface, different mechanism