← Back to portfolio
AWS Cloud Project · Serverless Architecture
Automating Image Processing With an Event-Driven Workflow
A simple AWS project where a customer uploads a verification photo, Amazon S3 triggers a Python Lambda function, the image is resized automatically, and the processed version is stored in a separate destination bucket.
Amazon S3AWS LambdaPythonIAMCloudWatch
Useruploads photo
→
S3input bucket
→
λPython resize
→
S3output bucket
CloudWatch
metrics & verification
metrics & verification
01 · The Challenge
Process customer verification images automatically.
The scenario was straightforward: a customer uploads a photo as part of a verification process. Instead of requiring a separate manual step, the system should resize the image automatically and store the processed version in a different location.
02 · Architecture
One upload starts the entire workflow.
The architecture uses an S3 event to connect storage directly to serverless compute.
01UploadCustomer photo enters the input S3 bucket.
→
02TriggerS3 ObjectCreated event invokes Lambda.
→
03ResizePython code resizes the image.
→
04StoreProcessed image is written to a second S3 bucket.
→
05VerifyCloudWatch metrics confirm execution.
03 · Implementation
Simple logic, clear responsibilities.
The Lambda function performed one main task: resize the uploaded image. The project intentionally kept the processing logic simple so the focus stayed on the serverless workflow and the interaction between AWS services.
Two S3 buckets
One bucket received the original customer upload. The second stored the resized version.
Lambda + Python
The S3 event invoked a Python Lambda function that resized the image automatically.
IAM policy
I configured the Lambda permissions using an AWS predefined policy so the function could access the required resources.
CloudWatch
I used CloudWatch metrics to verify that the function was being invoked and the workflow was operating.
IAMthe hardest part
→
Key Challenge
Permissions become more important as systems become more complex.
For this project I used a predefined AWS policy, but configuring the permissions was still the area that required the most thought. It reinforced how important access control is when multiple cloud services must work together.
Resource accessService interactionSecurity logicLeast-privilege mindset
04 · Validation
Upload, observe, confirm.
I tested the workflow by uploading an image to the input bucket and confirming that the resized version appeared in the output bucket. CloudWatch metrics were used to verify that Lambda was invoked as expected.
Scope note
This was intentionally a simple AWS Cloud project. The function only resized images; it did not include advanced validation, format conversion, error-handling scenarios, or a production-grade identity-verification workflow.
Cloud architecture is about logic.
The project helped me understand how to think through a workflow: what event starts the process, what service performs the work, where the output goes, and how the result is verified.
Services can react to events.
Instead of running a server continuously, the application reacts only when an image arrives. That changed how I thought about application architecture.
Add stronger validation and error handling.
A production version could validate file types, handle failed processing, use tighter IAM permissions, and add more detailed monitoring and alerts.
Project Sequoia Principle
Good systems begin with clear logic.
Understand the event, define each component's responsibility, give it only the access it needs, and verify that the complete workflow behaves as expected.
Explore More Projects