Ivan CernjaDeploy to AWS Without Kubernetes
Production deployment options that skip container orchestration
AWS has several container deployment options that don't involve running a Kubernetes cluster. ECS with Fargate, Lambda, App Runner, and various PaaS platforms all handle production workloads without the operational overhead of managing nodes, networking plugins, and YAML manifests. There's also the infrastructure-from-code approach with tools like Encore, which removes container configuration from the equation entirely.
Each option puts a different amount of work on your team. This guide walks through what you actually manage with each one.
AWS-native options
ECS with Fargate: managed containers without the cluster
ECS (Elastic Container Service) with Fargate is the closest thing AWS offers to "just run my container." Fargate handles the underlying compute, so there are no EC2 instances to provision or patch. You define a task (your container image, CPU, memory, environment variables) and a service (how many copies, which load balancer), and Fargate runs it.
What you still manage: task definitions, VPC and subnet configuration, security groups, Application Load Balancer setup, IAM roles, ECR image repositories, CloudWatch log groups, and auto-scaling policies. For a single service with a database, that's roughly 200-300 lines of CloudFormation or Terraform before your app starts accepting traffic.
ECS Fargate is a solid choice when your team already knows AWS networking and wants full control over the configuration. The learning curve is significantly smaller than Kubernetes, but it's not zero.
Lambda: serverless functions
AWS Lambda runs your code without any container or server management. You upload a function, configure a trigger (API Gateway, SQS, S3 events), and AWS handles scaling from zero to thousands of concurrent executions.
The model works well for event-driven workloads and APIs with variable traffic. Cold starts have improved significantly over the past few years, and provisioned concurrency can eliminate them for latency-sensitive endpoints.
What you still manage: API Gateway configuration, IAM permissions, Lambda layers for dependencies, memory and timeout tuning, and the packaging/deployment pipeline. If your application uses a relational database, you'll also need to deal with connection pooling through RDS Proxy, since Lambda's execution model doesn't maintain persistent connections.
Lambda's constraints start to show with larger applications. When you have 20+ functions sharing business logic, the deployment and local development story gets complicated. Frameworks like SST and Serverless Framework help, but they add their own abstraction layers.
App Runner: the simplest container option
AWS App Runner is AWS's answer to "I have a container, just run it." Point it at an ECR image or a source repository, and it builds, deploys, and scales your application with minimal configuration.
What you still manage: not much compared to the other options. App Runner handles load balancing, TLS, scaling, and deployments. The trade-off is limited control. Connecting to resources in a VPC (like an RDS database) requires a VPC connector, and you can't fine-tune networking, instance placement, or scaling behavior to the same degree as ECS.
App Runner works for straightforward web services and APIs. It starts to feel limiting once you need background workers, cron jobs, or more than basic request-response patterns.
PaaS platforms that deploy to AWS
Several platforms sit on top of AWS and handle infrastructure provisioning in your account or theirs. Render, Railway, and Fly.io offer managed hosting with simpler deployment workflows than raw AWS. Some, like SST, deploy directly into your AWS account using CloudFormation under the hood.
The advantage is a faster path from code to running service. The downside varies by platform: some deploy into their own accounts (so you don't control the underlying infrastructure), some have limited database options, and most charge a premium over raw AWS pricing. If you need the resources to live in your own AWS account for compliance or cost reasons, the options narrow.
Infrastructure-from-code: skip the configuration entirely
There's a different approach that eliminates infrastructure configuration altogether. Instead of writing task definitions, VPC configs, or even clicking through a PaaS dashboard, you declare what your application needs in your application code. The platform figures out what AWS resources to create.
Encore Cloud works this way. You write your backend in TypeScript (or Go) using Encore's open-source framework, and infrastructure requirements are expressed as part of your application code. When you deploy, Encore analyzes your code, determines the required infrastructure, and provisions it in your AWS account.
Here's what that looks like in practice:
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
const db = new SQLDatabase("orders", { migrations: "./migrations" });
export const getOrder = api(
{ method: "GET", path: "/orders/:id", expose: true },
async ({ id }: { id: number }): Promise<Order> => {
return await db.queryRow<Order>`SELECT * FROM orders WHERE id = ${id}`;
}
);
That code declares both an API endpoint and a PostgreSQL database. When deployed to AWS through Encore Cloud, it provisions an RDS instance, VPC with public and private subnets, security groups, an ECS Fargate service, Application Load Balancer with TLS, and CloudWatch logging. All in your AWS account, using standard AWS resources you can inspect in the console.
What you manage: your application code and database migrations. Encore handles the rest, including the pieces that usually consume the most time (networking, IAM policies, secrets management, environment isolation).
Adding more infrastructure follows the same pattern. Declare a Pub/Sub topic and it becomes SQS. Declare an object storage bucket and it becomes S3. Declare a cron job and it becomes an EventBridge rule. You don't write YAML, HCL, or click through the console.
Which approach fits
The right choice depends on your team's AWS expertise and how much infrastructure management you want to take on.
ECS Fargate makes sense when you have AWS experience on the team and need fine-grained control over networking and scaling. Expect to invest time in infrastructure configuration upfront.
Lambda fits event-driven architectures and APIs with spiky traffic patterns, especially when you're already comfortable with the serverless ecosystem and its constraints around cold starts and connection management.
App Runner works for simple container deployments where you don't need background processing or complex networking.
PaaS platforms offer the fastest time-to-deploy when you don't need resources in your own AWS account or want a managed experience without learning AWS internals.
Infrastructure-from-code with Encore Cloud is worth looking at if you want production-grade AWS infrastructure in your own account without writing or maintaining any infrastructure configuration. The resources are standard AWS (ECS, RDS, S3, SQS), but the provisioning and configuration happen automatically based on your application code.