AWS
Balancing Control and Abstraction in AWS Cloud Service
We'll discuss the trade-offs between control and abstraction in AWS cloud services. Here’s a clear breakdown:
Control Level
Maximum control
Moderate control
Moderate control
Moderate control
Minimum control
Very minimum control
Abstraction
Low abstraction
Moderate abstraction
Moderate abstraction
Moderate abstraction
High abstraction
Highest abstraction
Description
Provides raw VMs where you manage everything, including the operating system, middleware, and application software.
An orchestration service that deploys, monitors, and scales applications automatically.
Manages container orchestration but requires you to manage the EC2 instances where containers run.
A serverless compute engine for containers that eliminates the need to manage EC2 instances.
A fully managed service that makes it easy to deploy containerized web applications and APIs at scale.
A serverless compute service that lets you run code without provisioning or managing servers. You upload your code, and Lambda handles everything required to run and scale it.
Pros
Potentially the cheapest in terms of direct AWS costs.
Handles many infrastructure tasks like deployment, capacity provisioning, load balancing, and health monitoring.
AWS handles the scheduling and scaling of containers.
You provide the container image, and AWS handles the rest—provisioning, scaling, and managing the compute resources.
Simplifies the deployment process even further; you don’t need to know anything about containers or servers.
Pay only for the compute time you consume; no charges when your code isn’t running.
Cons
You are responsible for monitoring, updating the OS, scaling, security patches, and handling failures. Indirect costs include time and resources spent on management.
Considered somewhat outdated and may not support the latest features. You still have access to the underlying EC2 instances, which you might need to manage occasionally.
You must manage the EC2 instances, including updates and scaling the underlying infrastructure.
Less visibility and control over the underlying infrastructure.
Less control over configurations and the environment. Specific limitations depend on the service’s design.
Initial invocation after a period of inactivity can have increased latency. Constraints on memory. Functions are stateless; persistent state must be managed externally
AWS App Runner vs AWS Lambda
What They Are
AWS Lambda
Serverless Functions. Runs your code in response to events (like a file upload or an API call).
Event-Driven. Each piece of code (called a function) runs when triggered.
AWS App Runner
Managed Web Applications. Helps you run web apps and APIs without handling servers.
It's an always-on service. Keeps your application running continuously to handle web traffic.
Use Cases
AWS Lambda
You have short, event-driven tasks like processing a file or handling an API request.
Your application doesn’t need to run all the time.
You want to focus just on code without managing servers or containers.
AWS App Runner
You have a web application or API that needs to be up all the time.
Your application needs to run all the time.
You’re comfortable working with containers.
How You Develop
AWS Lambda
You typically write small pieces of code to handle specific tasks. Each function can run for up to 15 minutes.
No docker containers. Just write and upload your code.
Stateless. Doesn’t keep data between runs; use external storage if needed.
There is "cold start", the delay that occurs when an application or service starts up for the first time or after a period of inactivity.
AWS App Runner
You have complete applications packaged in containers. Your app runs as long as you need it to.
You provide a docker container image and code. Deploy and AWS runs it.
Can Maintain State. Since your app runs continuously, it can keep data in memory if needed.
No "cold start".
How You Pay
AWS Lambda
Pay Per Use. Costs are based on how often and how long your code runs.
AWS App Runner
Pay for Resources. When you set up your app, choose the amount of memory and vCPU it needs. If your app isn’t processing requests, you pay only for the memory that keeps it ready to respond. When your app handles requests, you pay for both the vCPU and memory used during that time.
Last updated