Elastic Beanstalk to EKS: How to Compare Your 5 Real Options (Cost, Complexity, Migration Effort)

AWS has not killed Elastic Beanstalk. That is the first thing to get straight, because most teams who ask me how to move to EKS are solving a problem they have not defined yet. Elastic Beanstalk still has no end-of-life date, and if a handful of stateless web apps deploy fine on it today, the honest answer is often to stay put and stop reading.

The teams who genuinely need to move usually hit a specific wall: service-to-service networking across many services, a demand for a preview environment on every pull request, slow rolling deploys, weak blue/green control, or a platform branch retiring under them. If that is you, the real question is not "EKS or Beanstalk." It is who operates Kubernetes after you leave, and how much that costs in dollars and in people.

Key Points:

• AWS has not deprecated Elastic Beanstalk, so "we must leave" is usually false. Leave only when you hit a named limit: service-to-service networking across many services, per-pull-request environments, slow rolling deploys, weak blue/green control, or a platform branch being retired under you.
• For a team with no Kubernetes experience, the decision is not EKS vs Elastic Beanstalk. It is who operates the cluster: upgrades, node lifecycle, ingress, autoscaling, IRSA, observability, and 2am incidents.
• Five buckets, and only these five: stay on Beanstalk, AWS-native without Kubernetes (ECS on Fargate, App Runner), self-run EKS, a cluster-management layer (Rancher, Platform9, Giant Swarm, Rafay), or a managed Kubernetes internal developer platform (Qovery, Kapstan, Northflank, Porter).
• Platform fees are the small number. EKS costs $0.10 per hour per cluster (about $73/month) on top of nodes (AWS EKS pricing), Elastic Beanstalk charges nothing beyond underlying resources (AWS Elastic Beanstalk pricing), and the dominant cost of self-run EKS is 0.5-2 FTE of platform engineering.
• Migration effort tracks how much Beanstalk you actually used: a Dockerized stateless API moves in days, while .ebextensions, platform hooks, worker tiers, or a Beanstalk-owned RDS push it to weeks. Decouple the database first - terminating a Beanstalk environment can delete a database that environment owns.
• Qovery runs EKS inside your own AWS account with no cluster operations, git-push deploys, preview environments per pull request, environment auto-stop, and per-environment RBAC - and the identical workflow runs on GCP, Azure, Scaleway, or an existing Kubernetes cluster, which is the anti-lock-in answer.

The one-paragraph verdict, if you read nothing else: Fewer than about 5 stateless services and no platform engineer? Stay on Beanstalk or move to ECS on Fargate. Many services, preview environments needed, 0-1 platform engineers? A managed Kubernetes IDP in your own account (Qovery, Kapstan, Northflank, Porter). 2+ platform engineers with time to spend? Run EKS yourself. Cluster fleets across business units or on-prem? Rancher, Platform9, Giant Swarm, or Rafay.

Is Elastic Beanstalk deprecated, and should you actually leave it?

No, Elastic Beanstalk is not deprecated, and AWS has published no shutdown date for the service. If you run a few stateless web apps that deploy fine today, staying is the cheapest correct answer. What AWS actually retires is individual platform branches, not the service, and confusing the two sends teams into migrations they did not need.

Here is what Beanstalk still does well, each worth stating plainly. It adds no service charge beyond the AWS resources you consume (AWS Elastic Beanstalk pricing). It has no control-plane fee. It provisions capacity, monitors health, and applies managed platform updates for you. And it gives you one-command deploys through the EB CLI. For a small team, that is a lot of undifferentiated work you are not doing.

The part that trips people up is platform support. The service is supported, but a platform branch moves from supported to retired when one of its components (OS, language runtime, application server, or web server) is marked end-of-life by its supplier. Once retired, Beanstalk stops shipping maintenance and security updates for that branch and gives existing environments a 90-day grace period (AWS Elastic Beanstalk platform support policy). The Amazon Linux 2 to AL2023 transition is the most common real-world forcing function I see, because AL2 reaching its own end of life pulls the branch out from under you.

So use a checklist, not a vibe. Leave Beanstalk when you hit one of these:

• More than a handful of services that need service-to-service networking
• A per-pull-request preview environment for every code review
• Rolling deploys that are too slow across a large fleet
• Blue/green control that is too coarse for your release process
• Brittle .ebextensions that break more than they configure
• An app stuck on a retired platform branch you cannot upgrade in place

If none of those apply, you are done. One to three simple stateless web apps, a happy team, and no multi-cloud requirement means stay on Beanstalk. When AWS itself points somewhere, it points at Amazon ECS (container orchestration without Kubernetes), Amazon EKS (managed Kubernetes), and AWS App Runner (the closest one-service replacement). Migrating badly costs more than staying: I have watched teams dual-run two platforms for six-plus months, maintain two CI pipelines and two on-call surfaces, and end up with no measurable deploy-speed gain.

What are the five real options after Elastic Beanstalk, and who operates Kubernetes in each?

There are five buckets, and only five. The question that sorts them for a team with no Kubernetes expertise is simple: which party owns cluster upgrades, node lifecycle, networking, and incident response? Two of the five keep Kubernetes out of your life entirely, and two keep it underneath while hiding it from your developers.

• Option 1, stay on Elastic Beanstalk. AWS operates everything, you accept the limits, and there is no Kubernetes anywhere.
• Option 2, AWS-native without Kubernetes: ECS on Fargate and AWS App Runner. Lowest learning curve, AWS-only, task definitions instead of manifests. Fargate runs your containers with no servers to patch; App Runner is a step higher, closest to the Beanstalk feel for a single service.
• Option 3, self-run EKS. You assemble the control plane, an autoscaler (EKS Auto Mode or Karpenter), an ingress controller, cert-manager for TLS, ArgoCD or Flux for GitOps, external-secrets, and a logging, metrics, and tracing stack. Then you own a Kubernetes upgrade on a recurring cadence.
• Option 4, a cluster-management or fleet layer on EKS: Rancher (SUSE), Platform9, Giant Swarm, Rafay. They operate or govern the clusters, but your developers still write Kubernetes manifests.
• Option 5, an internal developer platform on EKS: Qovery, Kapstan, Northflank, Porter. They abstract both the cluster and the developer workflow, so a developer deploys with a git push and never opens kubectl.

The distinction between Option 4 and Option 5 is the whole game. A cluster-management layer solves the operations problem. An internal developer platform (IDP) solves the operations problem plus the developer-experience problem that Beanstalk was quietly handing you for free. If your reason for leaving Beanstalk is that developers loved the git-push simplicity, a cluster-management layer alone will disappoint them.

Option 3 is where the cost hides. Count the pieces: control plane, autoscaler, ingress, TLS, GitOps, secrets, logging, metrics, tracing, and policy. That is ten moving parts to pick, wire, secure, and keep current. And the Kubernetes project ships a new minor release on average every four months and supports each one for roughly 14 months (Kubernetes patch releases), so the upgrade treadmill is a permanent line item, not a one-time setup.

This is where Qovery enters the picture, factually. Qovery is an internal developer platform that deploys and operates your apps inside your own cloud account (bring-your-own-cloud) on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster (qovery.com). Because the workloads run in your account, the cloud bill, your Savings Plans, and any Enterprise Discount Program (EDP) commitments stay in your name.

Is EKS more expensive than Elastic Beanstalk? What does each option cost per month?

On the AWS invoice, yes. Amazon EKS adds $0.10 per hour per cluster for the control plane, about $73 per month, while Elastic Beanstalk adds nothing beyond the underlying resources (AWS EKS pricing, AWS Elastic Beanstalk pricing). On the total bill, that $73 is noise next to the 0.5-2 platform engineers it takes to run EKS well, which is where the real EKS vs Elastic Beanstalk cost difference lives.

Split the cost into four buckets so nobody gets surprised.

The platform fee. EKS is $0.10 per cluster-hour in standard support. Let a version age out and it enters extended support at $0.60 per cluster-hour, roughly $438 per month, after 14 months (AWS EKS pricing). That is a 6x jump for the crime of not upgrading, and each EKS version gets 14 months of standard support and 12 of extended, 26 months total, before an automatic upgrade (Amazon EKS version lifecycle). Beanstalk's platform fee is zero. EKS Auto Mode adds a per-instance management fee on top of the EC2 cost (on the order of a few cents per instance-hour) and automates node provisioning, patching, and core add-ons (AWS EKS pricing); it does not build your application platform, CI/CD, or developer workflow.

Compute. Fargate in us-east-1 is $0.04048 per vCPU-hour and $0.004446 per GB-hour (AWS Fargate pricing). A 2 vCPU / 4 GB service running 24/7 costs about $72 per month on Fargate, versus about $30 per month for a comparable t3.medium on-demand instance (Amazon EC2 on-demand pricing). That is roughly 2.4x the raw compute price, and it buys you zero servers to patch. App Runner bills provisioned container memory at $0.007 per GB-hour and active compute at $0.064 per vCPU-hour plus $0.007 per GB-hour (AWS App Runner pricing); a small 1 vCPU / 2 GB service lands somewhere around $25 to $65 per month depending on how much of the time it is actively serving requests.

Engineering time. This is the number that decides everything. A DevOps engineer's median total compensation in the US is around $150,000 (levels.fyi). Half to two of those to run EKS well is roughly $75,000 to $300,000 a year, fully loaded. Any IDP or cluster-management subscription is competing against that number, not against the $73 control-plane fee.

Hidden per-environment costs nobody budgets. Each environment tends to want its own NAT Gateway at $0.045 per hour plus $0.045 per GB processed (Amazon VPC pricing) and its own Application Load Balancer at $0.0225 per hour plus $0.008 per LCU-hour (Elastic Load Balancing pricing). That is a floor of about $49 per month per environment before a single byte of traffic or one LCU is counted, and it multiplies by every preview environment you spin up. Add EBS volumes on idle nodes and observability SaaS ingest, and the "small" line items stop being small.

This is where two Qovery decisions change the math. Environment auto-stop puts non-production environments to sleep on a schedule, so dev and staging stop billing nights and weekends. And because Qovery runs in your own AWS account, your existing Savings Plans and EDP discounts still apply to the compute. That matters more than any platform fee, given that respondents to Flexera's 2025 State of the Cloud Report estimate 27% of cloud spend is wasted, most of it idle and overprovisioned resources (Flexera 2025 State of the Cloud Report).

How long does an Elastic Beanstalk to EKS migration actually take?

Days per service if your apps are already Dockerized and stateless, plus a few weeks for the platform itself. The long pole in any Elastic Beanstalk to EKS migration is not the code, it is everything Beanstalk quietly handled: .ebextensions, platform hooks, environment properties, IAM instance profiles, the worker tier, and a database the environment owns.

Start with the database, because it can bite the hardest. A DB instance coupled to a Beanstalk environment follows a deletion policy when the environment is terminated, and if that policy is Delete, the database goes with it. AWS's own guidance is to decouple it into a standalone RDS instance with the Retain policy before you go near compute (AWS Elastic Beanstalk with Amazon RDS). Do this first, on its own, and verify the database survives a test environment teardown.

Two more traps eat unplanned days. Worker environments backed by SQS are not a clone of your web tier; on Kubernetes they become a Deployment plus KEDA or an explicit queue consumer with its own scaling. And IAM instance profiles do not exist in the pod world. They become IRSA or EKS Pod Identity, the documented way to give a pod an IAM role (Amazon EKS Pod Identity). Teams underestimate this one constantly.

A sane sequence looks like this: decouple the database, containerize the app, stand up the target platform, migrate one low-risk service, run old and new in parallel behind Route 53 weighted routing, cut over, then decommission. Here is my rough effort estimate by archetype:

• Plain Dockerized stateless API: 2-5 days per service
• Rails or Django app leaning on .ebextensions: 1-3 weeks per service
• Worker tier plus SQS: 1-2 weeks
• App stuck on a retired platform branch needing a runtime upgrade first: weeks to months
• Assembling raw EKS before any service moves: 2-6 weeks

An IDP compresses the platform half of that. With Qovery you connect a Git repo that has a Dockerfile, and it provisions the EKS cluster, networking, ingress, TLS, and pipeline, so your remaining work is containerization plus config mapping rather than platform assembly. That matters because hand-rolled first clusters get the basics wrong at scale: in Fairwinds' 2024 Kubernetes Benchmark Report, 69% of organizations had 11-50% of workloads missing liveness probes and 66% missing readiness probes (Fairwinds 2024 Kubernetes Benchmark Report). Missing probes and missing resource limits are exactly the defaults a platform should set for you.

Keep this table at mapping depth. It is the concept map, not a tutorial.

Rancher vs Platform9 vs Giant Swarm vs Rafay vs Qovery: which fits a team with no Kubernetes experience?

Rancher, Platform9, Giant Swarm, and Rafay are built to operate and govern clusters, and every one of them still expects your developers to write Kubernetes manifests. Qovery, Kapstan, Northflank, and Porter target the other half of the problem, giving developers a Beanstalk-like git-push workflow on top of Kubernetes, which is exactly what a team leaving Beanstalk is missing. Pick the category that matches your actual pain before you compare products.

Here is each one described from its own positioning, and where it genuinely beats a developer-first IDP:

• Rancher (SUSE) is open-source multi-cluster management and governance, free to self-host with paid support tiers. It wins when you run many clusters across environments, including on-prem, and want one governance plane.
• Platform9 offers a managed Kubernetes control plane with SRE support and a strong private-cloud, on-prem, and edge story. It wins for regulated or air-gapped infrastructure you must run yourself.
• Giant Swarm provides fully managed clusters with a dedicated SRE team and 24/7 support at enterprise pricing. It wins when you want a contractual SRE team on call for your clusters, cluster-first rather than developer-first.
• Rafay delivers Kubernetes operations, fleet governance, and environment-manager capabilities aimed at platform teams standardizing across business units. It wins when policy governance across dozens of clusters is the core requirement.
• Kapstan, Northflank, and Porter are IDPs explicitly aimed at teams leaving Beanstalk or Heroku. The meaningful difference to check is whether workloads run in your own cloud account or the vendor's.
• Qovery is a BYOC internal developer platform with git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services, on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster (qovery.com).

Be honest about the limits of any IDP, including Qovery: it is an opinionated abstraction, and a team living in custom CRDs and bespoke operators will fight it rather than benefit from it. If that is you, a cluster-management layer plus your own workflow is the better fit. This is not a rare concern. In the CNCF 2024 Annual Survey, lack of training (36%) and complexity (34%) rank among the top challenges to running containers in production (CNCF Annual Survey 2024), which is precisely why hiding Kubernetes appeals to teams that do not have those skills yet.

Can you move off Elastic Beanstalk without learning Kubernetes?

Yes, on two different paths, and both are legitimate. You can skip Kubernetes entirely with ECS on Fargate or App Runner, or you can keep Kubernetes underneath and put a managed internal developer platform in front of it so your developers keep a git-push workflow and never open kubectl. The right path depends on whether portability off AWS matters to you.

Path A, skip Kubernetes. ECS on Fargate gives you container orchestration with task definitions instead of manifests, and App Runner is the closest one-service Beanstalk replacement. The trade-off is deeper AWS coupling and a thinner ecosystem for preview environments and portability. I will say this plainly, because it keeps me honest: for a large share of Beanstalk teams (fewer than about five stateless services, no multi-cloud requirement, no platform headcount) Path A is the right answer, and Kubernetes would be overhead you do not need.

Path B, keep Kubernetes but hide it. An IDP provisions and upgrades EKS while your developers deploy from Git. The trade-off is an opinionated abstraction and a vendor in the deploy path. What you still own on Path B, and should ask any vendor about directly: your cloud account and IAM boundaries, VPC design, database backups, and exactly what your setup looks like the day you cancel.

That last question is the reason portability matters. Standard Kubernetes manifests running in your own account are reversible; ECS task definitions are not, because they only run on AWS. With Qovery on Path B you get cluster provisioning, managed upgrades, ingress and TLS, a preview environment per pull request, environment auto-stop, and per-environment RBAC, and the same workflow runs on GCP, Azure, Scaleway, or an existing cluster (qovery.com). If you ever leave, you are left holding standard Kubernetes in an account you already control. For a longer list of options in this category, I keep a running comparison of EKS alternatives and internal developer platforms.

What decision framework picks the right option in one afternoon?

Three inputs decide it: how many services you run, whether you need portability off AWS, and how many engineers you can dedicate to platform work. Answer those three honestly and most of the list eliminates itself in about ten minutes. A 30/60/90 pilot on one non-critical service settles the rest with data instead of opinions.

Run it like this:

• Under about 5 simple stateless services, no multi-cloud requirement, zero platform headcount: stay on Beanstalk, or move to ECS on Fargate or App Runner. Kubernetes is overhead you do not need yet.
• Many services, you need preview environments, 0-1 platform engineers: a managed Kubernetes IDP in your own cloud account (Qovery, Kapstan, Northflank, Porter).
• 2+ platform engineers with strong opinions and the time to keep them: self-run EKS with Auto Mode or Karpenter, ArgoCD, and your own observability stack.
• Many clusters across business units, on-prem, regulated, or air-gapped: Rancher, Platform9, Giant Swarm, or Rafay.

For the pilot, migrate one non-critical service and measure four numbers before you commit anything else: deploy lead time, change failure rate, time to restore service, and monthly cost delta. Set your targets against the 2024 DORA performance bands, where elite teams deploy on demand, keep lead time under a day, hold change failure rate near 5%, and recover from a failed deployment in under an hour (2024 DORA State of DevOps Report). Then run the reversibility test on every vendor: ask what your setup looks like the day you cancel. Standard Kubernetes manifests running in your own cloud account is the good answer.

Is AWS Elastic Beanstalk deprecated or being shut down in 2026?

No. AWS has not deprecated Elastic Beanstalk and has published no end-of-life date for the service. What retires is individual platform branches, which lose maintenance and security updates when a component is marked end-of-life, with a 90-day grace period for existing environments (AWS Elastic Beanstalk platform support policy). Being stuck on a retired branch, not a service shutdown, is what forces most teams to move.

Is Amazon EKS more expensive than Elastic Beanstalk?

On the AWS invoice, yes: EKS adds $0.10 per hour per cluster (about $73 per month) for the control plane, and Elastic Beanstalk adds nothing beyond the underlying resources (AWS EKS pricing, AWS Elastic Beanstalk pricing). On the total cost of ownership, the bigger difference is the 0.5-2 platform engineers EKS needs, roughly $75,000 to $300,000 a year at a US DevOps median around $150,000 (levels.fyi).

How long does it take to migrate from Elastic Beanstalk to EKS?

For Dockerized stateless services, budget 2-5 days per service plus 2-6 weeks to assemble the EKS platform. Apps leaning on .ebextensions run 1-3 weeks each, worker tiers with SQS 1-2 weeks, and an app stuck on a retired platform branch can take months if it needs a runtime upgrade first. A managed IDP removes the platform-assembly weeks, leaving containerization and config mapping.

Can we move off Elastic Beanstalk without learning Kubernetes?

Yes, two ways. Skip Kubernetes with ECS on Fargate or AWS App Runner, or keep Kubernetes underneath and use an internal developer platform (Qovery, Kapstan, Northflank, Porter) that gives developers a git-push workflow with no kubectl. The AWS-native path couples you tighter to AWS; the IDP path keeps standard Kubernetes and portability off AWS.

What happens to my Beanstalk-managed RDS database when I migrate or terminate the environment?

It depends on the deletion policy, and the default risk is real: a database coupled to a Beanstalk environment follows a deletion policy when the environment is terminated, and if that policy is Delete, the database is terminated with it (AWS Elastic Beanstalk with Amazon RDS). AWS recommends decoupling the database into a standalone RDS instance with the Retain policy before production, and you should do that first, before touching compute.

Should we pick ECS on Fargate instead of EKS if our team has no Kubernetes experience?

Often yes, if you are staying on AWS and do not need portability. ECS on Fargate gives container orchestration with task definitions and no cluster to patch, at a compute premium of roughly 2.4x raw EC2 for the same vCPU and memory (AWS Fargate pricing). Choose an IDP on EKS instead when you want preview environments per pull request and the ability to move off AWS later without a rewrite.

What is the difference between a Kubernetes management platform like Rancher and an internal developer platform like Qovery?

A management platform like Rancher operates and governs clusters, but your developers still write Kubernetes manifests. An internal developer platform like Qovery abstracts both the cluster and the developer workflow, so developers deploy with a git push and get preview environments and per-environment RBAC without touching Kubernetes directly. If your reason for leaving Beanstalk is the developer experience, the IDP category is the closer replacement.

The trap in every Beanstalk migration is treating it as a Kubernetes decision when it is really a who-operates-it decision. Get that right and the cost, complexity, and migration-effort numbers fall into place. If you want the EKS operating model without the cluster operations, and the freedom to run the same workflow on AWS, GCP, Azure, Scaleway, or a cluster you already have, try Qovery free and move one service this week.