image
Example Cost Comparisons
Start course
Difficulty
Beginner
Duration
3h 46m
Students
3191
Ratings
4.6/5
Description

Domain One of The AWS Solution Architect Associate exam guide SAA-C03 requires us to be able to Design a multi-tier architecture solution so that is our topic for this section.
We cover the need to know aspects of how to design Multi-Tier solutions using AWS services. 

Want more? Try a lab playground or do a Lab Challenge!

Learning Objectives

  • Learn some of the essential services for creating multi-tier architect on AWS, including the Simple Queue Service (SQS) and the Simple Notification Service (SNS)
  • Understand data streaming and how Amazon Kinesis can be used to stream data
  • Learn how to design a multi-tier solution on AWS, and the important aspects to take into consideration when doing so
  • Learn how to design cost-optimized AWS architectures
  • Understand how to leverage AWS services to migrate applications and databases to the AWS Cloud
Transcript

Now before I wrap things up, I want to illustrate by way of example just how much your costs can vary between an EC2 and a serverless architecture depending on your application’s performance requirements. And the idea here is just to show that you can’t necessarily assume a serverless architecture will always be less expensive than one that leverages EC2 instances, or vice versa. Now of course, costs alone shouldn’t dictate whether or not a serverless implementation is more appropriate for your use case. Just know that one option may be more expensive than another, and it’s always worth running the numbers to see just how much these costs may differ. So for these examples I’m going to be using the AWS Pricing Calculator to estimate my costs, which is available at https://calculator.aws. And I would encourage you to do the same for your use cases as well. Now obviously, AWS pricing does change over time, but the prices I’m showing you here were current at the time of this recording.

So let’s start by comparing a workload we want to deploy as a Lambda function with unpredictable access patterns, but we know it gets executed a total of 1 million times per month. And let’s say this function requires 1 gigabyte of memory and 1 gigabyte of ephemeral storage. And let’s say it takes a total of 500 milliseconds to execute each time. So using the AWS pricing calculator, we can see that when operating outside of the free tier, this function will cost us $8.54 per month.

Now let’s say we want to deploy this workload on an EC2 instance instead. And let’s assume we can use a relatively modest t4g.small instance with a single 20 gigabyte EBS volume. With just the one instance, and using an EC2 Instance Savings Plan, this architecture will cost us $9.67 per month, which is pretty close to what we’d be paying to use Lambda.

Of course, if we want to achieve high availability, we would need to add a second EC2 instance, which doubles our total cost to just over $19 per month. And keep in mind this still doesn’t include any kind of load balancing, or any additional costs you might incur during prolonged spikes in demand since we are using a burstable instance type here.

So that was an example where a serverless approach saves a little money. But what if we massively scale up the demand? Let’s say instead of 1 million requests per month, we now have 100 million requests per month. Well since our Lambda function is billed based on usage, and we’ve increased our usage by a factor of 100, you’ll see the cost for this function has also increased by a factor of 100, putting us now at just over $854 per month.

But let’s say we can better predict the demand for these 100 million requests, and maybe we’ve determined that we can meet this demand by always running 4 t4g.xlarge EC2 instances. So by right-sizing our instances, even factoring in the cost of frequent snapshots for our EBS volumes, this implementation will only cost us about $282 per month, and that’s a huge savings.

So again, the idea here isn’t to show that a particular architecture will always be the most cost-effective option, but you do see how the costs of serverless and EC2 architectures can scale very differently. And if you are able to accurately forecast demand and right-size your instances, then an EC2 instance-based architecture may be your best option in terms of both cost and performance. EC2 instances also enable you to take advantage of savings plans and reserved instances that can further reduce your costs. But keep in mind that you will be responsible for managing and administering these servers, as well as configuring things like elastic load balancing and auto scaling. So it’s important to keep those costs in mind, as well as the additional time and labor required for server administration.

So to wrap things up here, there are no hard and fast rules when it comes to choosing a serverless architecture versus a more traditional EC2 instance-based approach. But if you’re looking to avoid the time and energy associated with provisioning and maintaining infrastructure, then a serverless architecture is probably best for you. This is especially true if you’re building a new architecture from scratch. Serverless architectures are also ideal for:

  • rapid prototyping,
  • event-driven applications,
  • applications with low levels of demand that are not frequently accessed, as well as
  • cron jobs that only need to be run on a fixed schedule and don’t need to be available at any other time.

On the other hand, you’ll want to go with an EC2 instance-based architecture if you need to have root-level access to the underlying server operating system and complete control over your infrastructure. Keep in mind, however, that you’ll always need to have at least one instance up and running, even if that instance is just sitting idle most of the time. And if you want your application to be highly available, you’ll need at least two instances running across different availability zones.

Serverless services are inherently highly available and don’t require you to pay for idle or unused resources. But there will always be cases where memory and performance requirements may exceed the capabilities of services like Lambda. In these cases, you’ll have no choice but to leverage EC2 and accept the associated costs of updating, patching, and securing your instances.

About the Author
Students
184864
Courses
72
Learning Paths
188

Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built  70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+  years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.