1. Home
  2. Training Library
  3. Serverless, Component Decoupling, and Solution Architectures (SAP-C02)

Choosing Between EC2 and Serverless


Course Introduction
Utilizing Managed Services and Serverless Architectures to Minimize Cost
Decoupled Architecture
Amazon API Gateway
Advanced API Gateway
PREVIEW11m 29s
Amazon Elastic Map Reduce
Introduction to EMR
Amazon EventBridge
Design considerations

The course is part of this learning path

Start course
4h 43m

This section of the AWS Certified Solutions Architect - Professional learning path introduces common AWS solution architectures relevant to the AWS Certified Solutions Architect - Professional exam and the services that support them. These services form a core component of running resilient and performant architectures. 

Want more? Try a Lab Playground or do a Lab Challenge!

Learning Objectives

  • Learn how to utilize managed services and serverless architectures to minimize cost
  • Understand how to use AWS services to process streaming data
  • Discover AWS services that support mobile app development
  • Understand when to utilize serverless services within your AWS solutions
  • Learn which AWS services to use when building a decoupled architecture

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.

About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.