PaaS on AWS: services, costs, and how to choose

PaaS on AWS means using managed application platforms so your team can deploy software with less infrastructure administration. Amazon Web Services offers several routes: Elastic Beanstalk for application environments, Amazon ECS Express Mode for containerized web services, AWS Amplify Hosting for supported web frameworks, and AWS Lambda for serverless compute. Databases and storage are separate parts of the application.

The right choice depends on how your code runs, where its state lives, and which operational tasks your team wants to retain. A managed platform can provision resources and automate routine work, but you still own the application, its permissions, and its behavior under load.

This guide reflects AWS documentation checked on October 14, 2026. One significant change affects older comparisons: AWS App Runner is closed to new customers. Existing customers can continue using it, including creating services, but AWS does not plan new features and recommends evaluating ECS Express Mode for migration.

What platform as a service means on AWS

Platform as a service, or PaaS, provides an environment for deploying and operating applications while the cloud provider manages some of the supporting layers. It sits between renting infrastructure and using a finished software product. Our guide to cloud service models explains the broader differences between IaaS, PaaS, SaaS, and serverless.

With infrastructure as a service, such as a conventional Amazon EC2 virtual machine, you choose and manage more of the operating system and application stack. A PaaS offering can manage deployment, health checks, and scaling around your code. Software as a service gives users an already-built application instead of a platform for their own code.

AWS is a cloud provider with services across these categories. Calling the whole of AWS “a PaaS” hides useful distinctions. Likewise, serverless describes an operating approach; it does not identify one universal feature set. Check the exact service and deployment mode rather than assuming the label means no maintenance, no idle charges, or unlimited scaling.

Compare the main AWS PaaS options

Option	Good starting point for	What to examine
Elastic Beanstalk Standard	Web applications on supported platforms, including Windows workloads	Platform version, EC2 resources, environment settings, and update policy
Elastic Beanstalk Cluster	Applications deployed through Beanstalk onto an EKS foundation	Container or source build, shared capacity, and underlying EKS charges
Amazon ECS Express Mode	Stateless HTTP applications and APIs packaged as containers	Image, IAM roles, networking, health checks, and scaling limits
AWS Amplify Hosting	Supported frontend and full-stack web frameworks	Framework compatibility, build workflow, server rendering, and backend resources
AWS Lambda	Serverless application components and supported compute patterns	Function type, execution model, quotas, integrations, and billing
AWS App Runner	Existing customers operating App Runner applications	Current support position and a tested migration path
Amazon RDS and DynamoDB	Managed persistent data alongside an application platform	Data model, access patterns, recovery, availability, and capacity

These services are not interchangeable. A database does not deploy your web application, and container compute alone does not define the application's release process. Select the application runtime first, then choose the data and integration services it needs.

AWS Elastic Beanstalk

Elastic Beanstalk provisions an application environment and coordinates resources such as compute, load balancing, health monitoring, and scaling. Its current documentation distinguishes Standard mode, which runs applications directly on EC2, from Cluster mode, which uses Amazon EKS.

Standard supports established platform families such as Java, .NET, Node.js, Python, PHP, Ruby, Go, and Docker. Check the supported version for your specific environment rather than treating a language name as a compatibility guarantee. Cluster mode accepts a container image or source that Beanstalk builds into one.

Beanstalk is useful when you want an application-focused deployment process while retaining visibility into underlying AWS resources. Before selecting a mode, identify who will manage platform updates, application dependencies, environment configuration, and recovery. A successful initial deployment does not answer those ongoing questions.

Amazon ECS Express Mode and Fargate

ECS Express Mode creates a Fargate-based ECS service with supporting networking, load balancing, monitoring, and scaling configuration. For the basic image-based route, you provide a container image, a task execution role, and an infrastructure role.

It suits stateless HTTP services and APIs. Your image needs to start reliably, listen on the configured port, and expose a useful health check. Keep durable application data outside replaceable containers. Our VM or container comparison helps clarify that packaging choice.

Fargate supplies managed container compute; ECS coordinates tasks and services. Express Mode adds an opinionated deployment route around those components. You still choose appropriate resource sizes, access settings, and capacity limits, and you need to understand the resources created in your account.

AWS Amplify Hosting

Amplify Hosting provides a Git-based workflow with continuous deployment for supported web applications. It supports static sites, single-page applications, and supported server-side rendering frameworks, with features such as preview deployments and custom domains.

It is a practical candidate when the frontend framework and build process determine most hosting requirements. Check the exact framework version and required features before choosing it. Hosting support does not mean every plugin, server feature, or backend dependency is covered.

Amplify Hosting and an application's backend are related but distinct. Authentication, APIs, databases, and background processing can create additional resources and responsibilities. Include them in the architecture and cost estimate rather than treating the frontend deployment as the whole system.

AWS Lambda

Lambda provides serverless compute, but its current product family covers more than the familiar event-triggered function. The Lambda pricing documentation distinguishes Event Functions, Web Functions, and MicroVMs, with different charging models. This guide uses event-driven processing as one common example rather than treating every Lambda option identically.

An upload-processing function or queue consumer can run independently of the web application. Design handlers for the retry and delivery behavior of their event source, including how repeated events affect stored data. A function that successfully processes one test request may still fail when many requests arrive together.

Review the current Lambda quotas for the chosen execution type and invocation mode. Timeout, memory, concurrency, and integration limits matter. Avoid blanket claims that every function starts instantly or that every serverless architecture has zero cost while idle.

Managed databases and object storage

Amazon RDS manages common administration tasks for relational databases. You still choose the engine and configuration and remain responsible for schema design, queries, access controls, and recovery requirements. Read replicas, failover, and backups serve different purposes; one does not substitute for the others.

DynamoDB is a managed serverless NoSQL database. Its suitability depends on access patterns and data modeling, not simply whether the application is “modern.” Plan keys, queries, and capacity behavior around the workload.

Amazon S3 provides object storage for items such as uploaded files and static assets. It is neither a relational database nor a general application runtime. Choose where each kind of state belongs before scaling the application layer.

How much does PaaS on AWS cost?

There is no single AWS PaaS subscription price. Your bill follows the resources, requests, storage, and optional features you use. Start with an architecture and workload estimate, then use current regional rates. A generic monthly range for a “small application” is unreliable without its traffic, database, availability, and network assumptions.

Beanstalk has no separate service fee in either mode, but its underlying resources are billable. Cluster mode adds EKS control-plane and Auto Mode management charges to the relevant compute and other services. ECS Express Mode also has no additional service charge; its supporting infrastructure still costs money.

Cost area	Include in the estimate	Question to ask
Application compute	Running capacity, execution duration, requests, and paid capacity features	What remains provisioned when traffic falls?
Database and storage	Capacity, operations, backups, replicas, and retained data	What is needed for the recovery target?
Networking	Load balancing, transfer, and network services used by the design	Where does data move, and how often?
Builds and monitoring	Build activity, image storage, logs, metrics, and retention	How much diagnostic data will be retained?
Operations	Support, maintenance work, migration effort, and incident response	Who owns the work the platform does not perform?

Estimate quiet, expected, and peak periods separately. Scaling the web layer cannot fix an overloaded database, and minimum capacity can create a baseline charge. Commitments and discounts need their own utilization assumptions; they do not make every part of the bill cheaper.

AWS Budgets can notify you about actual or forecast spending, but alerts can arrive after costs have accrued. Treat a budget notification as monitoring, not a guaranteed spending cap. Define who responds and what resources can safely be stopped.

Check the current AWS Free Tier terms for the account and services involved. Do not assume every configuration qualifies or remains free after an introductory period. Our cloud cost comparison guide explains how to include operational effort when comparing alternatives.

Security and operations remain shared responsibilities

The AWS shared responsibility model changes with the service you use. Managed infrastructure reduces some administration, while application code, customer data, permissions, and configuration still require customer decisions. A platform choice alone does not establish that an application meets its security or compliance requirements.

Give deployment automation and running application code separate, appropriately limited permissions. Keep credentials out of source repositories and container images. Review public exposure deliberately, and document how secrets, dependencies, and access rights are updated.

Define recovery in measurable terms: how much data loss is acceptable and how long restoration can take. Test a restore, an application rollback, and the loss of a running instance or task. Health monitoring tells you something is wrong; it does not prove that the team can recover the service.

Continuous integration and delivery tools, including AWS CodePipeline where appropriate, can automate releases. They still need tests, versioned configuration, and a rollback plan. Keep production changes reviewable and make it possible to identify exactly which application version is running.

Run a small deployment pilot before committing

Use one representative application path to test your choice. For example, a stateless containerized API with a separate database can be a useful ECS Express Mode pilot. This is an illustrative evaluation process, not a benchmark or a guarantee that this architecture fits every application.

1. Write down the acceptance criteria

Record the application runtime, traffic pattern, maximum acceptable response time, background jobs, and data requirements. Include access restrictions, region needs, recovery targets, and an operating budget. Decide what result would rule out the platform before spending time integrating it.

Identify any dependency on local disk, in-memory sessions, a GPU, privileged operating-system access, or a long-running process. These constraints can change the service choice more than the programming language does.

2. Make the release reproducible

Build a versioned artifact with pinned dependencies and documented configuration. For containers, check that the image architecture matches the target compute. Keep test data separate from production and confirm that replacing an instance or task will not remove the only copy of important data.

Use a meaningful health endpoint and test startup failures locally. A process being alive is weaker evidence than the application being ready to handle its intended requests.

3. Configure the chosen service explicitly

For the container example, follow AWS's ECS Express Mode console guide. Select the image and required roles, then review the container port, health path, CPU and memory, minimum and maximum tasks, networking, and logging before creation. Prefer an immutable image digest when identifying the tested release.

The service API reference distinguishes the execution role used for task operations from the task role used by application code to call AWS services. Do not solve a permission error by granting the application unrestricted account access.

4. Test the complete request path

Exercise authentication, database reads and writes, uploads, and any queue or notification dependency. Measure response times and errors under representative traffic. Include repeated requests, invalid input, unavailable dependencies, and a deployment while traffic is active.

Check both application and database behavior as capacity changes. More application instances can exhaust database connections or increase duplicate background work if coordination is missing. Record the failure and recovery behavior, not just the highest throughput reached.

5. Verify releases, recovery, and billing

Deploy a new application version, then return to the previous version. Check whether database changes remain compatible with that rollback. Practice restoring needed data into a separate environment so recovery is more than an untested setting.

Review the resources created and compare observed usage with the estimate. Include supporting load balancers, logs, images, storage, and network components. Use enough observation time to understand the baseline and billable work beyond a single successful request.

6. Record the decision and clean up

Keep the configuration, test inputs, results, known limitations, and named operational owner. If the pilot succeeds, plan production access, deployment approvals, monitoring, and recovery before moving live traffic.

If it ends, identify which resources and retained data are disposable, then remove them through the relevant service workflow. Confirm that required records or backups are preserved and check for remaining billable resources. Stopping application traffic alone does not stop every charge.

Migrating an existing App Runner application

Existing App Runner customers do not need to interpret the new-customer restriction as an immediate shutdown notice. Use the current support position to plan a migration deliberately. Inventory the image or source build, environment configuration, domain, secrets, network connections, and operational checks first.

ECS Express Mode requires a container image, so a source-based App Runner deployment needs a build step that produces one. Validate the replacement service before moving traffic. AWS's migration guidance uses gradual DNS routing where a shared custom domain is available; a default service URL requires a different client or endpoint transition.

Retain a tested rollback route during validation. Application traffic migration and database migration are separate concerns, and a healthy new endpoint does not prove that all state and background tasks have moved correctly.

Where Compute with Hivenet fits

Compute with Hivenet provides CPU and GPU compute resources. Evaluate it when those resources match the workload, while separately identifying how you will deploy, operate, and connect the application. Do not assume that renting an instance replaces a managed application platform, relational database, or every AWS integration.

A useful comparison lists the same responsibilities on both sides: runtime management, storage, deployment, monitoring, recovery, support, and total cost. Moving an application can change who performs those tasks. Compare a tested configuration and the work it requires rather than relying on an unsupported migration success story or a universal savings percentage.

Frequently asked questions

Is Amazon EC2 PaaS or IaaS?

EC2 is generally classified as infrastructure as a service. You rent compute capacity and manage more of the guest operating system and software stack. A platform such as Beanstalk can coordinate EC2 resources without making every EC2 deployment a PaaS application.

Is AWS Lambda considered PaaS?

Lambda is serverless compute. Event-triggered functions are commonly described as function as a service, a narrower model within the broader managed-platform discussion. Select the actual Lambda execution type and limits instead of relying on the PaaS label.

Is Amazon S3 PaaS or SaaS?

S3 is managed object storage. It can support an application, but it is not a complete application-hosting platform or a finished business application. “Object storage” is the more useful description when deciding what to use it for.

Is DynamoDB PaaS or IaaS?

DynamoDB is a managed serverless database, often discussed as database as a service. You work with its data model and APIs instead of maintaining database servers. Application logic, permissions, and appropriate data access patterns remain your responsibility.