AWS vs on-premises hosting for web applications

Our starting point on AWS vs on-premises hosting for web applications is simple: most of the business applications we build need one well-maintained server running Docker containers and Nginx. That server can sit in the cloud or in the client’s own server room. We choose AWS services such as ECS Fargate or Lambda when traffic is uneven or jobs run in the background, and also when we do not want to maintain an operating system.

We decide based on four criteria: cost predictability, data requirements, the skills of the team that will maintain the application, and the systems it has to connect to.

Hosting options for a web application

In practice, the choice comes down to three models:

Option	What you maintain	Suited to	Main risk
Server (VPS or physical) with Docker and Nginx	Operating system, updates, backups, monitoring	Applications with fairly steady traffic, internal systems, applications that must run close to other company systems	Neglected updates and backups that are never test-restored
Containers on AWS (ECS on Fargate)	The application image and service configuration; AWS manages the servers	Applications with growing or variable traffic, several environments (test, production)	Complex network and permission configuration, costs that grow with scale
Serverless functions (AWS Lambda)	The function code and its permissions	Short, event-triggered jobs: webhooks (automatic notifications from other systems), reports, integrations	Time and memory limits, harder debugging

Each option can be run well or badly. What sets them apart is who is responsible for the layer beneath the application, and what you pay for.

Our applications run in Docker containers

The projects in our portfolio, including Service Quotes, Offer Exchange and INVENTA Licenses, run in Docker containers behind Nginx. A container packages the application together with its dependencies, so it behaves the same on a developer’s laptop, on a test server and in production.

For the client, this has a practical consequence: the application is not tied to a single provider. The same image can run on a server in your office, on a virtual machine with any provider or in an AWS container service. If requirements or prices change in a few years, moving the application does not mean rewriting the system.

When is your own server the better choice?

We choose a server, whether with a hosting provider or in the client’s server room, when:

• traffic is predictable (a system for a few dozen staff does not need automatic scaling),
• the application has to connect to systems on the company network, for example software on a local server that cannot be reached from the internet,
• the client has its own infrastructure and a team that maintains it (we then add the application to the existing monitoring and backups),
• the client wants a fixed cost that is easy to plan (a monthly server fee fits a budget more easily than a usage-based bill).

There is one condition: someone has to maintain the server. System updates, certificates, database backups and regular test restores are duties that are easy to forget after launch. Conetso Software is the software development team of Conetso Group, based in Lublin, Poland. The Group’s IT infrastructure team can look after the servers under our applications, so you do not need a separate company for them. Our article on the software maintenance agreement covers what the contract should include.

When do we choose AWS?

We use AWS in our internal tools: CRM integrations, reports and automations. Our AWS projects for clients are described on the AWS application development page. The services we use include AWS Lambda, ECS Fargate, App Runner, S3, DynamoDB, Step Functions and CloudFront. We define the infrastructure in code (AWS CDK and SAM), so environments are built from the repository, without manual changes in the console.

This experience has given us a few rules:

• We use Lambda for short, event-triggered jobs: a webhook from a CRM, a nightly report, processing a file. According to the AWS documentation, a single function invocation can run for up to 15 minutes, and a function can have up to 10,240 MB of memory (AWS Lambda quotas, as of 30 October 2026). We split longer processes into steps and chain them with Step Functions.
• We use ECS on Fargate for applications that run all the time. Fargate runs containers without you managing servers or clusters of EC2 instances. You specify the CPU and memory for a task, and AWS takes care of the layer underneath (AWS Fargate documentation).
• We keep files and static assets in S3 and serve them through CloudFront. It must be possible to delete and restart the application container at any moment, so user files cannot live on its disk.
• We agree the data storage region up front. AWS has regions within the European Union. If the application processes personal data, we decide with the client where it will be stored before launch, rather than leaving it to the default settings.

One change worth knowing about: AWS has closed App Runner to new customers. Existing users can keep using it, but AWS does not plan new features and points to Amazon ECS Express Mode as the migration path (AWS App Runner availability change, as of 30 October 2026). That is why we no longer propose App Runner for new projects, even where it used to be the simplest choice.

How do you compare cloud and server costs?

Comparing the price of an hour of CPU time on its own is misleading. The cost of each option also includes:

1. Administration time. On a server, a person installs system updates, responds to failures and renews certificates. With managed services, the provider takes over part of this work.
2. Backups and their testing. You have to design them for both options, and in the cloud you also pay for storage.
3. Data transfer. In the cloud, outbound traffic is usually charged; on a server, it is often included in the monthly fee.
4. Test environments. In the cloud they are easy to start and stop; on a server they take up resources all the time.
5. The cost of change, meaning how hard it will be to move the application if circumstances change.

For small applications with steady traffic, a server usually wins on simplicity. Managed services can pay off for applications that are expected to grow or only run at certain hours. They do, however, need cost monitoring and budget alarms from the day they go live.

How we choose the option for a project

We settle where the application will run during requirements analysis. We ask about:

• the number of users and whether traffic will be steady or come in spikes,
• the type of data (for example patient data) and any requirements for where it is stored,
• the systems the application has to connect to and where they run,
• who will maintain the application and the server: you, your IT department or us,
• the availability you expect, for example whether a few minutes of downtime at night for an update is acceptable.

Based on this, we propose an option and describe what application maintenance covers. Because the application runs in containers, the decision is not final. If after a year a different model turns out to be better, the application can be moved.

Tell us about your application and we will propose a hosting option, with a quote for deployment and maintenance. This also applies to moving an application that is already live.