For many years, organizations embracing the public cloud knew there were two main types of compute services - customer-managed (i.e., IaaS) and fully managed or Serverless compute (i.e., PaaS).

The main difference is who is responsible for maintenance of the underlying compute nodes in terms of OS maintenance (such as patch management, hardening, monitoring, etc.) and the scale (adding or removing compute nodes according to customer or application load).

In an ideal world, we would prefer a fully managed (or perhaps a Serverless) solution, but there are use cases where we would like to have the ability to manage a VM (such as the need to connect to a VM via SSH to make configuration changes at the OS level).

In this blog post, I will review several examples of managed instance services and compare their capabilities with the fully managed alternative.

Function as a Service

The only alternative I managed to find is the AWS Lambda Managed Instances.

AWS Lambda has been in the market for many years, and it is the most common Serverless compute service in the public cloud (though not the only alternative).

Below is a comparison between AWS Lambda and the AWS Lambda Managed Instances:

When to Use Which Alternative

Use AWS Lambda (Standard) If:

• Traffic is Bursty or Unpredictable: You need the ability to scale from zero to thousands of concurrent executions in seconds to handle sudden spikes.
• Low or Intermittent Volume: You have idle periods were paying for running instances would be wasteful. "Scale to zero" is a priority.
• Strict Isolation is Required: Your security model relies on the strong isolation of Firecracker microVMs for every single request.
• Simplicity is Key: You want zero infrastructure decisions—just upload code and run.

Use AWS Lambda Managed Instances If:

• Traffic is High & Predictable: You have steady-state workloads were paying for always-on EC2 instances (with Savings Plans) is cheaper than per-request billing.
• Workloads are Compute/Memory Intensive: You need specific hardware ratios (e.g., high CPU but low RAM) or specialized instruction sets not available in standard Lambda.
• Latency Sensitivity: You cannot afford any cold start latency and need environments that are always initialized.
• High I/O Concurrency: Your application performs many I/O bound tasks (like calling external APIs) and can efficiently process multiple requests on a single vCPU without blocking.

Container Service

Amazon ECS is a highly scalable container orchestration service that automates the deployment and management of containers across AWS infrastructure.

Below is a comparison between Amazon ECS (self-managed EC2) and the Amazon ECS Managed Instances:

When to Use Which Alternative

Use Amazon ECS (Self-Managed EC2) If:

• You Need Custom AMIs: Your compliance or legacy software requires a specific, hardened OS image or custom kernel modules.
• You Require Host Access: You need SSH access to the underlying node for deep debugging, forensic auditing, or installing host-level daemon agents that ECS doesn’t support.
• Cost is the Sole Priority: You want to avoid the additional management fee and have a dedicated team that can manually optimize bin-packing and Spot instance usage for free.
• Legacy / Hybrid Constraints: You are extending a specific on-premise network configuration or storage driver setup that requires manual OS configuration.

Use Amazon ECS Managed Instances If:

• You Need GPUs or High Memory: You require specific hardware (like GPU instances for AI/ML) that AWS Fargate does not support, but you don’t want to manage the OS.
• You Want "Fargate-like" Operations with EC2 Pricing: You want to offload patching and ASG management (like Fargate) but need to use Reserved Instances or Savings Plans to lower costs.
• Security Compliance: You need guaranteed, automated rotation of nodes for security patching (e.g., every 14 days) without building the automation pipelines yourself.
• Steady-State Workloads: Your traffic is predictable, making always-on EC2 instances more cost-effective than Fargate’s per-second billing.

Kubernetes Service

Amazon EKS is a fully managed service that simplifies running, scaling, and securing containerized applications by automating the management of the Kubernetes control plane on AWS.

Below is a comparison between Amazon EKS (self-managed nodes) and the Amazon EKS Managed Node Groups:

When to Use Which Alternative

Use Amazon EKS Managed Node Groups If:

• Standard Kubernetes Workloads: You are running standard applications and want to minimize the time spent on infrastructure maintenance.
• Simplified Scaling: You want EKS to automatically handle the creation of Auto Scaling Groups that are natively aware of the cluster state.
• Automated Security: You want a streamlined way to apply security patches and OS updates to your cluster nodes without downtime.
• Operational Efficiency: You have a small team and need to focus on application code rather than Kubernetes "plumbing."

Use Amazon EKS Self-Managed Nodes If:

• Custom Operating Systems: You must use a specific, hardened OS image (e.g., a highly customized Ubuntu or RHEL) that is not supported by Managed Node Groups.
• Complex Bootstrap Scripts: You need to run intricate "User Data" scripts during node startup that require fine-grained control over the initialization sequence.
• Unique Networking Requirements: You are using specialized networking plugins or non-standard VPC configurations that require manual node configuration.
• Legacy Compliance: You have strict regulatory requirements that mandate manual oversight and "manual sign-off" for every single OS-level change.

Summary

In this blog post, I have reviewed several compute services (from FaaS, containers, and managed Kubernetes), each with its alternatives for either customer managing the compute nodes, or having AWS manage the compute nodes for the customers.

By leveraging AWS Lambda Managed Instances, Amazon ECS Managed Instances, and Amazon EKS Managed Node Groups, organizations can achieve high hardware performance without the burden of operational complexity. The primary advantage of this managed tier is the ability to decouple hardware selection from operating system maintenance. Developers can handpick specific EC2 families, such as GPU-optimized instances for AI or Graviton for cost efficiency, while AWS manages the heavy lifting of security patching and instance lifecycle updates.

Disclaimer: AI tools were used to research and edit this article. Graphics are created using AI.

About the author

Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work. Connect with Eyal on social media: https://linktr.ee/eyalestrin. The opinions expressed here are his own and do not reflect those of his employer.