From Netflix to Your Serverless: A Journey to Secure, Tenant-Isolated Image Upload on AWS

Hooking the Journey to Real-World Constraints

Building on the Netflix case, the challenge is clear: how to let users upload images, process them on-demand, and store metadata without risking cross-user access. The solution starts with a security-first mindset: isolate data by user, grant the smallest possible permissions, and prove that misconfiguration cannot accidentally expose another user’s data. Specifically, you’ll see how per-user prefixes in S3 map to narrow IAM roles, how Lambda participates with minimal access, and how DynamoDB enforces tenant separation at the data layer 1 . 💡 Key takeaway: isolation isn’t a feature toggle; it’s a design constraint baked into every policy and every action.

The Per-User Prefix: Locking Down S3 Access

To prevent cross-user access, S3 access is scoped to a user-specific prefix, such as s3://bucket/${aws:PrincipalTag/UserID}/. This means a user can PutObject and GetObject only within their own folder, not anywhere else in the bucket. The policy highlights the principle of least privilege by tying permissions to the authenticated identity rather than the bucket as a whole. A minimal policy example looks like this: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject"], "Resource": "arn:aws:s3:::your-bucket/${aws:PrincipalTag/UserID}/" } ] } This approach aligns with AWS guidance on bucket access patterns and per-tenant isolation 2 7 .

The Lambda Execution Role: A Minimal, Targeted Boundary

The Lambda function that resizes images should run with just enough power to read the source object, write the two resized variants, and record metadata. The execution role typically includes: s3:GetObject on the source user-prefix s3:PutObject on the destination user-prefix (two resized sizes) dynamodb:PutItem on the metadata table This separation ensures that Lambda cannot access other tenants’ data, even if a misconfiguration slips through elsewhere. See AWS guidance on Lambda permissions for context 4 . { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::your-bucket/${aws:PrincipalTag/UserID}/" }, { "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::your-bucket/${aws:PrincipalTag/UserID}-processed/" }, { "Effect": "Allow", "Action": ["dynamodb:PutItem"], "Resource": "arn:aws:dynamodb:REGION:ACCOUNT_ID:table/your-metadata" } ] } This mirrors best practices for tightly scoped Lambda permissions and aligns with AWS documentation on per-function roles 4 .

DynamoDB: Fine-Grained Access Control for Tenant Isolation

DynamoDB is the truth-teller for who can read or write what. Fine-grained access control uses IAM conditions to ensure that any PutItem or GetItem operation only affects the records belonging to the authenticated user. The approach leverages partition keys that encode user identities and policy conditions that check those keys, effectively preventing cross-tenant data access at the data layer 5 . You can also use IAM condition keys such as aws:PrincipalTag or aws:SourceIdentity to constrain operations at the infrastructure level 6 . Example note: planning a query against a user-specific partition key (e.g., PK = USER# ) with an accompanying condition in the policy ensures isolation without inspecting every row in code.

Testing Cross-User Access: Are Other Doors Locked?

Testing is the instrument that proves the locks work. Use policy simulation to verify that a given user cannot access another user’s data. AWS Policy Simulator lets you model requests against your IAM policies and resource policies to confirm least-privilege behavior before deploying to production 9 . As you design tests, simulate scenarios like: PutObject in a different user’s folder, GetObject from a peer’s metadata entry, and PutItem with a mismatched partition key. This helps catch issues before they become real incidents 6 . The lesson: testing is not a checkbox; it’s part of the security architecture that catches misconfigurations early 2 9 .

Putting It All Together: A Lightweight, Safe, Serverless Pipeline

The architecture binds three layers — storage, compute, and data — with strict boundaries: S3 stores originals under user-specific prefixes; the bucket policy enforces per-user access 2 7 . Lambda functions perform image processing with a narrowly scoped role; the function reads from the source and writes to the processed area, while storing metadata in DynamoDB 4 . DynamoDB holds per-user metadata and prevents cross-tenant reads/writes via fine-grained policies; partition keys encode the owner identity, with IAM conditions enforcing ownership 5 . This separation allows teams to scale on demand (serverless) while maintaining predictable security boundaries. For reference, Netflix’s transition to a serverless, decoupled image pipeline demonstrates the payoff of decoupled stages and on-demand compute to reduce overprovisioning and accelerate iteration 1 . Real-World Case Study Netflix Netflix migrated its image processing pipeline to a serverless-first approach, splitting the workload into two pieces: Dynimo Preprocessor on EC2 for business rules and Dynimo Generator on AWS Lambda for actual image download/processing. They rewrote critical parts in Go and shipped a statically built ImageMagick binary to enable on-demand scaling for artwork assets. Key Takeaway: Serverless on-demand compute can dramatically reduce overprovisioning for bursty workloads; decoupling processing into generator and preprocessor enables targeted scaling and faster iteration; rewriting hot paths in a lower-level language (Go) can significantly cut cold-start overhead.

System Flow

flowchart TD A[User uploads image to S3 at userID prefix] --> B[S3 triggers Lambda via event] B --> C[Lambda resizes to two sizes] C --> D[Stores resized images back to userID prefix] D --> E[DynamoDB PutItem with image metadata] E --> F[Audit/Tracing] Did you know? The term serverless is a bit of misdirection: servers still exist, but developers focus on code and events, not provisioning servers for every load spike. Key Takeaways Isolate data by user using per-user prefixes in S3 Grant Lambda the least-privilege permissions for read/write and metadata storage Use DynamoDB fine-grained access control to enforce tenant boundaries References 1 Netflix documentation 2 IAM Best Practices documentation 3 Example bucket policies documentation 4 Lambda permissions documentation 5 Fine-Grained Access Control in DynamoDB documentation 6 IAM policy elements and conditions documentation 7 S3 Notification How-To documentation 8 PutItem API Reference documentation 9 Policy Simulator documentation 10 Serverless Image Handler documentation 11 Lambda with S3 triggers documentation 12 Serverless Computing documentation 13 AWS SAM: What is SAM? documentation Share This Ever wondered why some image uploads feel instant in the cloud? 🔥 Per-user prefixes enforce tenant isolation in S3 and prevent cross-access.,Lambda runs with least-privilege permissions, limiting what it can read and write.,Policy simulation plays a real role in catching misconfigurations before they bite. Dive into the full story to see the journey from problem to secure, scalable solution. #SoftwareEngineering #SystemDesign #BackendDevelopment #CloudComputing #DevOps #Serverless #AWS #Security undefined function copySnippet(btn) { const snippet = document.getElementById('shareSnippet').innerText; navigator.clipboard.writeText(snippet).then(() => { btn.innerHTML = ' '; setTimeout(() => { btn.innerHTML

System Flow

Wrapping Up

The journey shows that secure, scalable serverless pipelines aren't magical features; they are deliberate designs that combine per-user isolation, narrowly scoped roles, and robust testing. Start by defining tenant boundaries, then layer in event-driven processing, and finally prove that cross-tenant access cannot slip through the cracks. The payoff is a resilient, cost-effective image pipeline you can trust.