When more events happen, the system automatically grows to handle them without you having to do anything.
This change in thinking is what really makes serverless technology powerful, whether you're using Lambda functions or containers in a serverless setup.
Pizza, anyone? Explaining serverless with food
Make it yourself vs order pizza
To make it easier to understand, the speaker used a pizza example. Let’s imagine two choices for dinner:
Option 1: Make it yourself
Option 2: Just order pizza
You specify what you want
Someone else handles the kitchen, oven, and cooking
You pay for the pizza, not for owning a restaurant
Traditional servers, like EC2, are like cooking at home. You take care of the kitchen (server), keep the oven running (patching, updates), and you pay for it all the time, even when you’re not cooking. You have full control, but you also have to take care of everything yourself.
Serverless is like ordering pizza. You just give your order (code), say what you want (toppings, size, base), and AWS handles the rest. You only pay for what you eat, not for keeping the kitchen open all day.
Ordering your serverless pizza
The session continued by using the analogy to explain how to build a serverless application.
Base (Runtime/Language)
Choose Python, Node.js, Java, Go, .NET, Ruby, etc.
Or "bring your own base" using containers when you need something custom.
Toppings (Resources)
Size (Code Complexity)
When should it run?
This helped the students in the room better relate their daily experiences to the decisions made in cloud computing.
Lambda in action (and where it struggles)
A simple Lambda example: image resizer
To make it more clear, there was a slide that showed a Lambda function used to resize images that were uploaded to S3. The code used was:
boto3 to talk to S3
PIL (Python Imaging Library) to open and resize the image
A lambda_handler function that:
Reads the file details from the S3 event
Downloads the image to /tmp
Creates a thumbnail
Saves the processed image back and returns a success status
This kind of situation is exactly where Lambda works best: for small, trigger-based, short-running tasks like image resizing, making thumbnails, simple API support, and light data processing.
When Lambda hits the wall
But Lambda isn’t without its limits, and the speaker was very open about that. There was a slide called "When Lambda hits the wall" that listed situations like:
Uploading a video → Lambda works great
Generating a thumbnail → Lambda is perfect
Transcoding a full video → Lambda fails
Why does it fail here? Because:
Video processing might take 45 minutes
Lambda has a hard timeout limit (15 minutes in the slides)
You may need more control over the environment
Larger dependencies or special tools may be required
So even though serverless technology is strong, you still need to choose the right tool within that serverless environment. That’s where AWS Fargate comes in.
Lambda vs Fargate: same pizza shop, different options
Comparing Lambda and Fargate
One slide showed a table comparing Lambda with Fargate using the same restaurant analogy:
What it is
Lambda: standard menu
Fargate: custom recipe
Base options
Customization
Execution time
Code size
Use case
Lambda: quick, short functions
Fargate: long processes, heavy workloads
Cold starts
The bottom line? Lambda is like quickly ordering from a standard menu, while Fargate lets you bring your own recipe and ingredients but still avoids managing the kitchen yourself.
Fargate – bring your own recipe and enjoy the freedom
Another slide described Fargate as "Bring Your Own Recipe":
Then came "Fargate – The Freedom" with three angles:
More control
More capacity
More use cases
Long-running processes
Legacy applications that expect a traditional environment
Microservices with specific runtime needs
Batch jobs and background processing
This made it clear that Fargate is still "serverless" in the sense that you don’t manage servers, but you get container-level flexibility.
Architecture patterns you can try
Practical patterns from the slides
One of the most helpful slides showed different architecture patterns that students could try at home. Some examples included:
Event-driven API
Scheduled jobs
EventBridge (cron) → Lambda → process data
Perfect for nightly reports, cleanup jobs, or scheduled notifications.
Microservices
API Gateway → Lambda or Fargate → backend services
Useful when building modular, independently deployable services.
Data pipeline
Webhook handler
These patterns link what students learn in class to actual projects they might work on, like building apps for school, starting their own business, or doing internships.
When NOT to use serverless
Being honest about trade-offs
One slide caught my attention because it said: "Be honest – serverless isn’t always the best choice." That’s a key point, especially for newbies who are excited about a fresh new idea. The slide listed some situations where serverless might not be the right fit:
When you have steady and high traffic that could be handled more affordably with always-on infrastructure
When you need a lot of control over the environment at a lower level
When tasks run for a long time and go beyond what a serverless function can handle
When you aren’t sure about your needs yet and might complicate things by using too many managed services too early
In the end, serverless is just another tool. The real skill is knowing when to use it and when something else, like containers or even basic EC2 instances, would work better.
Lambda vs Fargate: a simple decision tree
A mental model for choosing
There was also a clear decision tree to help choose between Lambda and Fargate. The simplified way of thinking about it went like this:
Do you need to run code at all?
Will it finish in under 15 minutes?
- If no → consider Fargate for long-running processes with a custom environment.
- If yes, is it a standard runtime (like Python, Node.js, etc.) with manageable dependencies?
If yes → Lambda is usually the fastest and cheapest option.
If no → again, Fargate or another container-based approach likely fits better.
This kind of straightforward flow is really useful when you're building your first few architectures and aren't sure which service to use.
Key takeaways from the session
The slide summary and my own reflections
The final "Key Takeaways" slide put everything together with points like:
Serverless is like ordering pizza instead of running your own restaurant
Understand Lambda vs Fargate instead of blindly choosing one
Focus on code, not servers
Pay for value, not idle time
For me personally, the biggest takeaway was that "serverless" isn’t just for Lambda. You can think serverless even when using containers, as long as AWS takes care of setting up and scaling your resources, and you focus mainly on your application.
Conclusion
This session at AWS Student Community Day in Tirupati was really helpful because it reminded me that good tech talks don't just list features, they change the way you understand things. The pizza example, the open talk about the limits of Lambda, and the introduction to Fargate as a strong "serverless containers" option made the topics easier to grasp, especially for students who are just starting to learn about these services.
As an AWS Community Builder, events like this keep me motivated because they show how quickly curiosity can turn into actual projects when you get the right examples and ways of thinking. If this topic interests you, try picking a small use case from your own life, like processing images from your app or running a scheduled cleanup, and try building it using Lambda or Fargate. Getting your hands on these tools will teach you more than any presentation ever could.
About the Author
As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀
🔗 Connect with me on LinkedIn
References
Event: AWS Student Community Day Tirupati
Topic: How AWS Lambda and Fargate Change the Way We Build Apps
Date: November 01, 2025
Also Published On
AWS Builder Center
Hashnode