Hosting is often decided late and then lived with for years. Yet the choice sets who patches the servers, who restores the database after a mistake, where your customers' data sits, and whether a traffic spike produces a slow page or an unexpected invoice.

This guide explains the main options for cloud hosting for a business application in plain terms, what differs between them from a business point of view, and how to match an option to your application and team. It quotes no prices, because list prices change and the drivers of your bill matter more than any single number.

Quick answer

• Shared hosting suits brochure websites and small content sites. It is rarely the right home for a custom business application.
• A VPS (virtual private server) gives you a predictable bill and full control, but you, or someone you pay, must patch, secure, monitor and back it up.
• A managed platform (platform as a service) is the sensible default for most small and mid-sized business applications: you deploy code, the provider runs the servers.
• Containers and serverless are ways of running an application that pay off when you have several services, uneven traffic, or a team with the skills to operate them.
• AWS, Microsoft Azure and Google Cloud are not a single option. "We are on AWS" says little about how much work your team has taken on.
• Whatever you choose, you remain responsible for your data, user access and configuration. No provider takes that over.

The hosting options in plain terms

The US National Institute of Standards and Technology published the standard vocabulary for this area in The NIST Definition of Cloud Computing (SP 800-145), which defines three service models: infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). The everyday hosting categories map onto those models as follows.

Shared hosting

Your site sits on a server alongside many other customers' sites. The host runs the server; you get little control over software versions and resources, and performance can depend on your neighbors. It works for a marketing site or a small WordPress install. It is a poor fit for an application with background jobs, custom server software or strict security requirements.

VPS

A VPS is a virtual machine rented for a fixed period, usually with a fixed allocation of CPU, memory and disk. You get administrator access and can install anything. This is IaaS in its simplest form. The fixed allocation makes the bill predictable, and the control is real. So is the workload: operating system updates, firewall rules, database tuning, backups, monitoring and recovery are all yours.

Managed platforms (PaaS)

With a managed platform you hand over your code, or a container image, and the provider runs it. Microsoft's documentation describes PaaS as deploying applications "without managing VMs or operating systems" and lists Azure App Service and Azure SQL Database as examples in its shared responsibility guide. A managed database is often the most valuable part, because database patching and backups otherwise need a specialist. The trade-off is less control and some dependence on that platform's way of doing things.

Containers

A container packages an application with everything it needs to run, so it behaves the same on a laptop and in production. It is a packaging format, not a hosting tier: you can run one on a VPS, on a managed container service, or on an orchestration system such as Kubernetes that coordinates many containers across many machines. Orchestration brings a real operational learning curve; a single application with one database rarely needs it.

Serverless

Serverless services run your code on demand and bill for use rather than for a machine left running. AWS describes Lambda as letting you "run code without provisioning or managing servers" in its Lambda documentation. Google's Cloud Run documentation describes a managed platform that removes the last running instance when there are no incoming requests. This suits uneven workloads better than steady, heavy ones, and it changes how an application has to be designed: AWS documents a limit of up to 15 minutes per Lambda function invocation, for example.

AWS, Azure and Google Cloud

Each of the three large providers offers virtual machines, managed platforms, managed databases, container services and serverless. Choosing one is therefore two decisions: which provider, and, more important day to day, which level of service you use inside it.

What actually differs for a business

On AWS, Azure or Google Cloud, your row depends on the services you pick. Two points deserve emphasis. The operations burden is a cost even when it never appears on an invoice: it is paid in engineer time, or in risk if nobody does the work. And the cost models fail differently: a fixed server gets slow under load, while a usage-based service keeps serving and bills you for it.

The shared responsibility model: what the provider does not do for you

All three large providers publish a model describing where their responsibility ends and yours begins. It is worth reading before signing anything, because the most common misunderstanding in cloud hosting is "the provider handles security."

• AWS states that it "is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud," and that customer responsibility "will be determined by the AWS Cloud services that a customer selects." On a virtual machine service such as EC2, the customer manages the guest operating system "including updates and security patches." See the AWS Shared Responsibility Model.
• Microsoft states that "for all cloud deployment types, you own your data and identities," and lists what you always retain: data, endpoints, accounts and access management. Its matrix shows the operating system as the customer's job on IaaS and Microsoft's on PaaS. See Shared responsibility in the cloud.
• Google says that in IaaS "the bulk of the security responsibilities are yours," that in PaaS it is responsible for more controls, and that even in SaaS "you remain responsible for your access controls and the data that you choose to store." See Shared responsibilities and shared fate on Google Cloud.

The practical reading is consistent across all three. Moving from a virtual machine to a managed platform transfers operating system and infrastructure work to the provider. It never transfers responsibility for your data, who can log in, or how access is configured. With a VPS from a smaller host, assume everything above the virtual machine is yours unless the contract says otherwise.

Where your data lives: UK and US considerations

This section is general information, not legal advice. Confirm your obligations with a qualified adviser.

The large providers organize their infrastructure into regions, and you choose the region when you create resources. AWS states in its Data Privacy FAQ that "you choose the AWS Region(s) in which your content is stored" and that it will not move or replicate content outside your chosen regions without your agreement, except as necessary to provide services you initiate or to comply with the law or a binding governmental order. Microsoft describes each Azure geography as "a fixed data residency boundary" in its regions overview. Check the same point with any smaller host: ask which country the servers and the backups are in.

If you handle personal data about people in the UK

The UK Information Commissioner's Office explains in its guide to international transfers that a "restricted transfer" happens when personal information is sent, or made accessible, to a separate organization outside the UK. Such a transfer needs to be covered by UK adequacy regulations, by appropriate safeguards such as the International Data Transfer Agreement or Addendum, or by a specific exception.

Two points are easy to miss. Access counts as well as storage, so a support or development team in another country that can open production data may itself amount to a restricted transfer. And for the United States, the UK's adequacy arrangement is partial. The ICO's guidance on the UK Extension to the EU-US Data Privacy Framework says it allows transfers to "certain self-certified businesses in the US," and advises checking that the recipient has an active status on the Data Privacy Framework list, has signed up to the UK Extension, and is certified for the type of data involved. The regulations, which the UK government calls the UK-US data bridge, came into force on 12 October 2023.

If you are a US business

For US companies, location requirements often arrive through sector regulation, state privacy law and customer contracts. If you work in healthcare, financial services or with government bodies, or if enterprise customers send you security questionnaires, establish those requirements with your advisers before choosing a region or provider. A US company holding personal data about people in the UK should also consider the UK rules above.

Backups and disaster recovery

Two terms make this conversation concrete. AWS defines the recovery time objective (RTO) as "the maximum acceptable delay between the interruption of service and restoration of service" and the recovery point objective (RPO) as "the maximum acceptable amount of time since the last data recovery point" in its disaster recovery whitepaper. In plain terms: how long can you be down, and how much recent data can you afford to lose? These are business decisions, and they should be made before the technical design.

The same whitepaper describes four strategies in rising order of cost and complexity: backup and restore, pilot light, warm standby, and multi-site active/active. Most small and mid-sized business applications are well served by the first, done properly. Done properly means:

• Backups are stored away from the thing they protect. A backup on the same server, or deletable with the same login, fails in the same incident.
• Point-in-time recovery, not just replication. AWS notes that continuous replication "may not protect against disaster events such as data corruption or malicious attack" as well as point-in-time backups do. A replica faithfully copies an accidental deletion.
• Restores are tested. The whitepaper is blunt: "Your backup strategy must include testing your backups."

On a VPS, you design all of this. On a managed database, automated backups are typically a setting, though you should still confirm retention, location and how a restore works.

Decision table: application type and team size

An illustrative scenario, not a client case study: a 40-person logistics firm commissions a customer portal and has one part-time IT contractor. A self-managed VPS looks cheapest on paper, but nobody is available to apply security updates or test restores. A managed platform with a managed database is the safer choice, because the missing operations work is being bought rather than skipped.

The provider question is usually less decisive than it feels. Pick based on the skills your team or development partner already has, the regions you need and your existing vendor relationships. If you are still choosing a partner, hosting ownership and handover belong in that conversation; our guide on how to outsource software development from the US or UK covers what to ask.

How to avoid a surprise bill

With usage-based billing, the most important fact to know is that a budget alert is not a spending limit.

• Microsoft's documentation says that when budget thresholds are exceeded, "Resources aren't affected, and your consumption isn't stopped." See Create and manage budgets.
• Google states that setting an alerts-only budget "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." See Create, edit, or delete budgets. Its spend cap budgets, which pause new usage for a short list of services, are labeled Preview at the time of writing.
• AWS warns that "you might incur additional costs or usage that exceed your budget notification threshold before AWS Budgets can notify you," because billing data lags behind usage. See Managing your costs with AWS Budgets. Its budget actions can apply a restrictive policy at a threshold, but only if you configure them.

Practical habits that prevent most unpleasant invoices:

1. Set budgets and forecast alerts on day one, sent to a person who will act.
2. Put hard ceilings where the service allows them: maximum instance counts on autoscaling, concurrency limits on serverless functions, rate limits on public APIs.
3. Understand each meter before launch. Compute is only one line. Storage, logs, database size and backups are metered too, and AWS, for example, prices data transfer as its own item.
4. Separate environments and switch off what you are not using. Forgotten test environments are a common source of waste.
5. Protect the account itself with multi-factor authentication and narrowly scoped access keys; a compromised account can run resources at your expense.

For technical readers

• Start with one region and multiple zones. AWS describes Availability Zones as discrete data centers with separate power and networking, designed not to fail together (AWS fault isolation boundaries). Multi-region is a separate, costlier decision driven by RTO and RPO.
• Keep the application portable. A containerized, stateless application tier with a standard relational database moves between a VPS, a PaaS and a container service with modest effort. A framework such as Laravel runs on any of them.

Frequently asked questions

Is AWS, Azure or Google Cloud always better than a VPS?

No. A VPS is a sound choice for a steady-traffic application when someone competent is responsible for patching, security, monitoring and backups. The large clouds earn their place when you need managed services, automatic scaling, specific regions, or the access controls and audit features that enterprise customers ask about.

Does hosting with a large cloud provider make my application secure and compliant?

No. The provider secures its infrastructure. AWS, Microsoft and Google all state that the customer remains responsible for its data, identities and access configuration, and for the operating system when using virtual machines. Compliance is something your organization achieves, using the provider's services as one part of it.

Can I change hosting later?

Yes. Moving is easiest when the application runs in containers, uses a standard database, and keeps provider-specific services to a minimum. The data migration and the cutover, not the code, are usually the hard part, so plan a rehearsal.

Do I need to keep UK customer data in the UK?

The ICO's guidance is framed around the conditions for sending personal data outside the UK, not a blanket rule on storage location. Transfers must be covered by adequacy regulations, appropriate safeguards or an exception, and remote access from another country can count as a transfer. Some contracts and sectors impose stricter location terms. Take advice for your situation.

Conclusion

Choosing cloud hosting for a business application is mostly a decision about who does the operational work and how costs behave under load. If nobody will own patching and restores, buy a managed platform. Inside the large clouds, pick managed services before raw servers.

A useful next step is to write down four things: who will operate the application, how long it can be down, how much data it can lose, and where its data must be kept. Entrant Technologies builds websites, web applications, mobile apps and custom software; if you would like a second opinion on a hosting plan, you can share your requirements here.