Hello, and welcome to this lecture, where I will discuss how to choose between using traditional EC2 instances or serverless services for your cloud-based compute workloads. And in this course I’m going to be focusing on AWS Lambda as my serverless service of choice. Now Lambda allows you to deploy and run custom code functions on demand, without needing to provision or maintain any servers of your own. But you should know that in addition to Lambda, AWS offers around a dozen different serverless services that fall into three different categories, including serverless compute, serverless application integration, and serverless databases, each with their own specific use cases within a given architecture. And to learn much more about all of the different serverless services offered by AWS, I encourage you to check out this course:

A Survey of Serverless: https://cloudacademy.com/course/survey-serverless-2399/ 

So I’m going to begin by discussing the main differences between EC2 and serverless services in general, again with an emphasis on AWS Lambda. After that, I’ll explain when you might want to go serverless, or when sticking with EC2 may be a better option instead. It’s important to remember that there are no hard and fast rules here, and sometimes your decision may come down to personal preference or just your general willingness to maintain and administer servers. As you’ll see, there are scenarios when an EC2 deployment will be more cost-effective than a serverless deployment, but other times when the opposite will be true. So it’s important to understand all of the tradeoffs between EC2 and serverless architectures to know what questions to ask when deciding whether or not to go serverless.

So let’s start by quickly discussing EC2 instances and when it makes sense to use them. EC2 instances are, of course, your tried and true virtual servers running in the AWS Cloud. They’ve been around for a very long time and have significantly reduced the burden that’s typically associated with provisioning servers in an on-premises environment. You can choose from a wide variety of instance types that can be optimized for compute, storage, or memory, going up to dozens or even hundreds of vCPU, hundreds of gigabytes of memory, and gigabit-level network performance. But at the end of the day, these EC2 instances are still servers and bring along with them all of the typical server maintenance and administration tasks you would expect with a legacy on-premises server. And this includes everything from configuring storage and networking, to scaling and load balancing multiple servers for high availability and fault tolerance, to patching and updating the underlying operating system as well as any other installed applications. And all of these things carry an associated cost on top of the amount AWS is billing you to run the instances themselves.

Now speaking of billing, when it comes to your EC2 instances, you’re either going to have some sort of reserved instance, where you’re paying a fixed cost for your instance to be up and running for a predefined amount of time, such as one year or three years, or you’ll be paying an on-demand or spot instance rate for however long your instance is up and running. And knowing if you need to always have an instance up and running is a key factor when deciding whether or not to go serverless. Depending on the nature of your workloads, it may or may not make sense to pay for an EC2 instance that is up and running at all times to respond to any requests. Because keep in mind, you’re always going to be paying for that running instance, even if it’s just sitting idle for extended periods of time.

So one of the big advantages of serverless computing is, just as the name suggests, you aren’t responsible for any servers: from your architecture’s standpoint, it is server-less. Now of course your code is still running on a server somewhere, but AWS is going to be fully responsible for the upkeep, maintenance, and security of that server. You’ll never have any access to it, nor will you ever need to worry about configuring or administering it. And as an added bonus, serverless services are inherently highly available. So unlike EC2 instances, which require you to use Elastic Load Balancing with an Auto Scaling Group to achieve high availability, services like AWS Lambda are highly available without any additional complexity or cost.

Now when it comes to billing for services like Lambda, you’re only ever going to pay for what you use. So if you deploy some code to a running EC2 instance that doesn’t get executed for two months, you’re still going to pay the full amount for that instance just as if it was being fully utilized the entire time. But with Lambda, you won’t pay anything until your code executes again. And even then, you’re only going to pay for exactly how much memory you’ve allocated to your function, as well as any ephemeral storage you need above 512 MB. And this billing is down to the millisecond level of execution time. Now that being said, there are some hard limits within Lambda, like a 15 minute timeout and 10 GB memory limit that can’t be exceeded. And we’ll talk more about this shortly.