Serverless Concepts and AWS Lambda

This is worth correcting immediately, because the name genuinely misleads: servers still run the code in a serverless architecture — they simply aren't servers you provision, patch, or manage yourself. AWS owns and operates the underlying infrastructure, and takes on a large share of the operational burden that Module 3's EC2 instances left with the customer.

AWS Lambda runs your code in response to events, without you provisioning or managing a server. Compare this to Module 3's EC2: with EC2, you choose an instance type, launch it, patch its operating system, and keep it running whether or not it's actively serving traffic. With Lambda, you upload code, and AWS runs it only when something invokes it — handling the underlying compute, scaling the number of concurrent executions up and down automatically as demand changes.

This is the same Shared Responsibility shift Module 3 introduced for EC2 versus a fully managed service, taken further: Lambda sits toward the "AWS manages more" end of that spectrum. What stays the developer's job: writing correct code, configuring appropriate permissions, and reasoning about how the function behaves under real traffic and failure conditions — Lambda manages where your code runs, not whether it's correct.

It would be a mistake to treat serverless as strictly "better" than an EC2-based design. Serverless is not automatically cheaper, faster, or simpler — it depends on the workload. A steady, high, predictable load can sometimes be run more cost-effectively on carefully-sized EC2 capacity; a spiky, unpredictable, or infrequent workload often fits Lambda's pay-per-invocation model well. The right choice depends on the actual traffic pattern and operational trade-offs, not a blanket rule that one approach always wins — exactly the same "choose by actual requirements" discipline Module 6 taught for choosing between VPC networking patterns.