So as you’ve probably figured out, there are plenty of situations where running your workloads on EC2 instances will be your only option, or at the very least, a clearly preferable option to using a serverless service such as Lambda. And these situations include the following:

When your workload is long-running, memory intensive, has steady and predictable levels of demand, or if it requires more processing power, memory, storage, concurrent executions, or execution time than Lambda is capable of providing.

Now, this situation is probably the most obvious, as it won’t be technically possible to execute your code any other way than with EC2 instances. And as I mentioned earlier, these instances can scale up to hundreds of vCPU and hundreds of gigabytes of memory. So if your workloads require resources at this scale, or they require a runtime that isn’t currently supported by Lambda, you’re going to want to stick with a traditional EC2 implementation and right-size your instances to ensure you have the appropriate level of compute resources available at all times to meet demand.

The next situation would be if your workload has a lot of external dependencies, or otherwise requires access to the underlying operating system of the server where it is running.

Because services like Lambda abstract away the underlying server and operating system, you won’t be able to install any other software on the server where your code is running. Now Lambda does allow you to upload what are called deployment packages, which can take the form of a zip file or a container image that contains your code along with all of its dependencies. But there are some important limitations with these deployment packages: if you’re using a zip file, you’re limited to a file size of 50 MB, which includes any dependencies or custom runtimes you may need. 

And in the case of container images, your image is limited to 10 GB in size and generally speaking, if you aren’t already using a containerized architecture, you probably aren’t going to switch to one just to take advantage of these Lambda deployment packages. But if you are already leveraging containers, you may want to take advantage of AWS Fargate instead, which is a serverless service that allows you to deploy containerized applications without having to manage servers or provision infrastructure.

And finally, if you’re migrating an existing workload from an on-premises environment and you don’t have the resources or budget to refactor it into a serverless architecture, you’ll probably want to use EC2 instances as part of a “lift and shift” migration approach. 

And this one’s pretty self-explanatory. If you’re doing a lift and shift migration from an on-premises server, you’re going to need a server in the cloud. But it’s important to remember that this wouldn’t prevent you from still going serverless at some point in the future.

So we’ve seen some examples of when it makes sense to use EC2 instances. Now let’s talk about when a serverless implementation might make more sense. So obviously if you aren’t subject to any of the constraints I mentioned earlier, such as needing an extreme amount of processing power or memory, and you don’t otherwise need access to an underlying server, you probably have a good candidate for a serverless architecture. Using a serverless architecture allows you to focus on solving your business problems without having to spend any time provisioning or managing infrastructure. Some other situations where you may want to consider adopting a serverless approach include:

When you’re developing a brand-new, greenfield application and you want to adopt the most modern approach possible.

Cloud-native applications often have event-driven architectures that leverage microservices, and both of these lend themselves to the use of serverless technologies that include not only Lambda, but services like the Amazon Simple Notification Service and Simple Queue Service, or SNS and SQS as well. It’s even possible to create what are called Function URLs that allow you to expose HTTPS endpoints for your Lambda functions without needing to leverage additional services like API Gateway to deploy secure, highly available microservices. And you can also leverage the AWS Serverless Application Model, or SAM, to define your serverless application’s resources using CloudFormation and create more robust, repeatable deployments.

The next situation is if demand levels for your workloads are unpredictable, but you know they’re still within the limits supported by Lambda.

In these cases, a serverless architecture makes sense because you never have to pay for any idle EC2 instances. If you’re unable to accurately forecast demand, it becomes difficult to determine the best EC2 instance family to choose for your workloads. And choosing too large of an instance could prove to be a very expensive mistake if it just ends up sitting idle most of the time.

And finally, Lambda makes it easy to maintain multiple concurrent versions of your functions.

It even allows you to direct a subset of traffic to two different function versions at the same time to support testing, making it easy to quickly iterate, update, and roll back changes to your applications in a way that would require significantly more effort with an EC2 instance.

Now we’ve spent a lot of time talking about Lambda so far in this course, and that’s because as one of the flagship serverless services, it’s such an integral part of so many serverless solution architectures. So if you’re interested in learning more about AWS Lambda and how to leverage it within your own serverless architectures, I encourage you to check out this course.