AWS App Runner vs ECS for Simple Web Services

The AWS App Runner vs ECS choice for simple web services now has a clear answer. App Runner closed to new customers in April 2026, so ECS is now the AWS-native way forward. Express Mode simplifies setup, but it does not replace App Runner’s whole workflow. Small teams that want control over their infrastructure without a DevOps function should look at Porter before building that workflow themselves.

Why the App Runner vs. ECS debate no longer exists as a product choice

AWS announced App Runner’s move to maintenance mode on March 31, 2026, and stopped accepting new customers on April 30, 2026. That changes the decision for both new teams and existing users. New customers cannot choose App Runner, and existing customers need a plan for moving off it. AWS has not published a final sunset date, so the cutoff for new customers should not be mistaken for a shutdown deadline.

Teams therefore need to ask what ECS requires of them when they previously expected AWS to handle the entire route from code to running service. Express Mode and standard ECS Fargate answer that question differently. The distinction matters because a short setup process is not the same thing as a complete deployment workflow.

What App Runner actually did, and what disappears when it goes

App Runner accepted either a GitHub repo or a container image. AWS then handled building, deploying, scaling, load balancing, TLS termination, and a custom domain. The team did not have to configure a cluster, task definition, ALB, security group, or IAM role. Those were not simply hidden settings that teams could ignore until later.

That abstraction also covered the everyday release process. A team could link a branch and have App Runner rebuild automatically on push, without a manual trigger. Source code was enough to start the process, rather than a finished container image produced somewhere else. ECS Express Mode has no direct counterpart to that build-from-repo workflow. Without that workflow, the team has to handle the steps between a code change and an image ready to deploy.

Observability was part of the package too. CloudWatch logs and HTTP metrics were on by default, with 2xx/4xx/5xx counts and response times included. AWS X-Ray tracing was available, but teams had to enable it explicitly. A migration therefore involves more than finding somewhere else to run a container. It also means accounting for the build process, release trigger, network entry point, and visibility that arrived together in App Runner.

What ECS Express Mode actually is, and where its simplification stops

ECS Express Mode is AWS’s designated successor, built on ECS and Fargate. It automates cluster creation, ALB provisioning, HTTPS through ACM, security group configuration, and CloudWatch setup. It also shares a single ALB across several services, where teams using standard ECS previously had to use an ALB for each service. That changes how startups work out the cost of running several services.

Express Mode takes only pre-built container images and has no source builds, managed runtimes, or build-from-repo option. It also does not scale to zero, so a minimum instance always runs. Teams must have a Docker build-and-push pipeline before Express Mode can deploy what they wrote. AWS recommends GitHub Actions to ECR with OIDC authentication.

This is a new category of work for a team coming from App Runner. Express Mode sets up infrastructure, but the team still has to handle the build process, CI/CD pipeline, and updates to the infrastructure over time. By treating builds, deployments, and cluster management as one system, Porter addresses that broader lifecycle gap. Its underlying platform is Kubernetes, so it offers an alternative operational approach to ECS Express Mode.

Networking sets another limit on the shortcut. Express Mode creates its cluster in the default VPC unless configured otherwise, which falls below AWS’s own security baseline for production workloads. Configuring a custom VPC addresses that issue, but also takes back some of the setup work Express Mode was meant to remove. Once a team is making those networking decisions, the step to standard ECS Fargate is shorter than it first looks. Express Mode remains a legitimate starting point for prototypes and low-stakes services, but it is not a full production equivalent to App Runner’s abstraction.

What standard ECS Fargate gives you that Express Mode does not

Standard ECS Fargate exposes the controls that Express Mode leaves out. Teams can configure task definitions, blue-green deployments, multi-container tasks, sidecar containers, and fine-grained IAM. They also gain private subnets, NACLs, VPC flow logs, and control over NLB behavior, including transport-level routing and static IPs. These are specific tools for shaping how a service runs and how traffic reaches it.

That control is especially useful when the same service runs in several environments. Terraform or CloudFormation can describe staging and production with the same infrastructure definition. These tools record the setup so it can be repeated, rather than requiring someone to reproduce it by hand. App Runner’s abstraction made that parity harder to achieve.

In ECS, X-Ray tracing requires a sidecar running the X-Ray daemon or an OpenTelemetry collector. Standard ECS can run those extra containers, so teams have more choice in how they set up tracing. Fargate also qualifies for AWS Compute Savings Plans, a cost lever App Runner did not offer. The comparison therefore includes both the effort to configure a service and the options available after it is running.

Compute choice extends beyond Fargate itself. Standard ECS supports Fargate, EC2, and ECS Anywhere, but Fargate does not support GPUs. EC2 and ECS Managed Instances provide paths to GPU instances for ML inference workloads. That is a separate decision from choosing how much web-service setup to automate. A team can choose ECS while still needing a different compute path from Fargate.

Which ECS path fits which team: Express Mode versus standard Fargate

If a team has one or two engineers, no compliance requirement, and a prototype, internal tool, or low-traffic service, Express Mode is the right starting point. Its strength is the shortest route from an existing image to a running service. That recommendation fits work where a streamlined setup matters more than detailed infrastructure control. It does not remove the need to build the image or arrange future deployments.

If a service will still be in production a year from now, choose standard ECS Fargate. The same advice holds if it needs private networking, must pass a compliance audit, or runs in more than one environment. Starting there avoids setting up Express Mode only to migrate again when those requirements arrive. These requirements already reach beyond the simplified path.

If the team is too small to own that setup, choose an operating model before committing to the infrastructure work. App Runner was a one-engineer platform, while standard ECS Fargate is sized for roughly two to five engineers. Porter offers an account-owned platform approach for teams that want control without assembling a DevOps function. A managed PaaS outside AWS is another option for teams below that threshold that would rather not build the pipeline themselves.

If the workload needs GPUs, branch away from Fargate toward ECS on EC2 or ECS Managed Instances. For small teams without a multi-cloud requirement, ECS remains the simpler direction on cost and speed to first deployment, with a free control plane. If Kubernetes portability or GPU-native tooling matters, EKS is the right direction instead. It brings portability and Karpenter-driven scaling for large inference clusters, but also a per-cluster-hour control-plane charge and a longer first-deployment timeline.

What compliance and security look like on ECS Fargate after App Runner

App Runner’s abstraction hid networking decisions, but it also limited the controls customers could use to meet audit expectations. App Runner’s restrictions on customer control over private subnets, security groups, NACLs, and VPC flow logs made it harder to run under HIPAA or SOC 2 expectations than standard ECS Fargate. When a team moves to ECS, it takes on the work of managing those controls. It also makes them available to configure and demonstrate.

AWS Fargate meets the standards for PCI DSS, SOC, FIPS 140-2, FedRAMP, and HIPAA. That does not mean an application running on it inherits compliance automatically. AWS’s certification covers the cloud, and the team is still responsible for the application layer. Fargate does remove the host from the customer’s compliance scope. There is no EC2 patching, host hardening, or SSH access control to evidence, and running platform version LATEST and redeploying keeps the Fargate runtime current.

AWS Security Hub identifies concrete ECS controls that belong in the audit checklist. ECS.4 covers non-privileged containers, and ECS.5 covers a read-only root filesystem. ECS.8 checks for no secrets in environment variables, while ECS.9 covers logging configuration. ECS.20 requires the use of a non-root user, and ECS.2 checks that there is no public IP assignment.

Standard ECS Fargate provides the former, while task definitions and networking choices establish the latter. Teams should therefore handle security configuration when they first set up the infrastructure, without leaving it for a separate audit exercise. The work is more visible than it was in App Runner, but visibility is also what makes the controls usable.

How to close the operational gap ECS leaves for teams without a DevOps function

For a small team whose main constraint is operational capacity, Porter is the stronger fit than assembling the full AWS workflow by hand. It provisions production-ready Kubernetes environments in the team’s own AWS, GCP, or Azure account, including deployment into a customer-controlled VPC. It handles cluster management, CI/CD wiring, autoscaling, upgrades, and CVE patching automatically. That makes the first deployment easier and addresses the lifecycle work Express Mode leaves behind. Choosing Porter also means using a managed Kubernetes platform in place of standard ECS underneath.

The platform runs in their cloud account while handling the work they would otherwise need a DevOps function to perform. Porter also offers one-click SOC 2 and HIPAA compliance features, GPU workload support, and transparent resource-based pricing. Teams still have to take care of the application layer when using those compliance features. They make Porter a relevant option for teams that need both infrastructure control and help operating it.

Teams that want to stay entirely on AWS primitives have a concrete route as well. A minimum production ECS Fargate setup includes a custom VPC with private subnets, an ECR repository, and a task definition with the Security Hub controls applied. It also needs an ALB with an ACM certificate, an OIDC-authenticated GitHub Actions or equivalent pipeline, and a CloudWatch log group. Each is a discrete initial setup step. The load balancer deserves particular attention because ECS routes through an ALB configured in the EC2 console, a separate surface from the ECS console, rather than App Runner’s ready URL and one-click domain attachment.

AWS published a GitHub Actions workflow for ECS Express Mode in March 2026 that covers the basic build-push-deploy loop with OIDC authentication. It assumes GitHub as the git host, leaving teams on GitLab, Bitbucket, or self-hosted git to build an equivalent. After setup, the ongoing burden is smaller than the initial inventory suggests. Fargate platform version LATEST handles runtime patching with redeployment, Compute Savings Plans provide cost optimization through a predictable commitment, and infrastructure as code makes environment parity repeatable. The durable choice is therefore not simply the fastest service to launch, but the path the team can keep operating without giving up the controls production needs.