How to choose hosting for your business: shared hosting, VPS, cloud platforms or managed services

Sooner or later, every company website or internal system raises the question of where it should be hosted. The options look endless: low-cost shared hosting, fixed-price VPS plans, cloud platforms such as AWS and Google Cloud, and managed services that take over deployment entirely. Most people either pick the cheapest or pick whatever "the big companies use" — and end up with too little performance, or a bill nobody understands and settings nobody looks after. Only two questions really matter: what are you putting on the server, and who will run it once it is live? Here are the trade-offs and the usual traps, organised around those two questions.

Start with what you are actually hosting

• A brochure or static site: if the content rarely changes and there are no member accounts or database, you may not need a server at all. Static hosting behind a CDN is fast and dependable, there is no operating system to maintain, and far less is exposed to attack.
• A WordPress or similar CMS site, or a small online shop: shared hosting or managed WordPress is usually enough. What matters is not the spec sheet but whether you can download your own backups and whether someone handles updates and certificates.
• Your own system — a back office, an API, member accounts and orders: once you need control over the runtime and background jobs, you need a VPS or a cloud server. Manage the database separately from the application, or use a managed database service, and backups and restores become much simpler.
• Sharply fluctuating traffic: elastic scaling earns its keep when there are clear peaks, such as campaigns or flash sales. If traffic is steady, a fixed-size VPS is often cheaper and far easier to budget for.
• Industries with data-residency rules: finance, healthcare and public-sector work may come with requirements on where data is stored and how outsourcing is handled, and client contracts can add their own. Confirm those before choosing a data centre — it is far easier than moving after launch.

The four options and what each one trades away

• Shared hosting: the cheapest and least effort, with the host managing the operating system and web server. The catch is that many sites share the same machine, so a neighbour’s traffic spike or problem becomes yours too, and what you can install or configure is limited. Fine for a modest CMS site; not suited to your own system.
• VPS (virtual private server): you get a virtual machine with dedicated resources and full freedom to install and configure it. Most plans have a fixed monthly price with a traffic allowance included, so the bill is predictable. The catch is that operating-system updates, the firewall, certificates and monitoring are all on you — an unmaintained VPS is more dangerous than shared hosting.
• Cloud platforms (AWS, Google Cloud, Azure and the like): the widest range of services — servers, databases, storage, queues — rented by usage and scaled with the most flexibility. The catch is a long list of billing items and a steep configuration curve; the same need can be assembled several ways, and assembling it wrong shows up in performance or on the bill. Best for teams with engineers, or systems whose architecture genuinely needs those components.
• Managed platforms (PaaS and managed services): the platform takes care of the operating system, deployment and scaling, leaving you only the code and the data. It saves the most operations effort; in exchange the unit price is higher, what you can do is bounded by the platform’s rules, and the more you lean on its proprietary features, the harder it becomes to move later.

Before the spec sheet, answer one question honestly: is there anyone in the company who can apply updates every month, watch the monitoring, and look after certificates and backups? Cloud providers sell parts, not a system someone is looking after. If the answer is no, choose the option that manages the most for you, or hand the operations work to someone dedicated, rather than the most powerful platform — the best hardware still fails when nobody maintains it. Conversely, if the team can run it, a fixed-size VPS with reliable backups can carry many small-business systems without a cloud platform on day one.

What else shows up on the bill besides the monthly fee

• Outbound data transfer: cloud platforms usually bill separately for traffic leaving their network, and for a site heavy on images, video or downloads this can cost more than the server itself. Serving static files from a CDN improves both speed and cost.
• Disks, snapshots and backup storage: billed by capacity, and they accumulate. Old snapshots that nobody prunes turn, a few months on, into a recurring charge nobody can explain.
• Add-ons: static IPs, load balancers, managed databases, NAT gateways and the rest are each priced separately. The more complete the architecture diagram, the longer the bill — every component deserves the question, "do we actually need this now?"
• Support plans: entry-level tiers often offer only documentation and community forums; a human response within a guaranteed time usually costs extra. Being unable to reach anyone during an outage tends to cost more than the plan would have.
• Promotional pricing and currency: first-year discounts typically revert to the full rate on renewal, so compare renewal prices. Overseas providers bill in foreign currency, so what you pay moves with exchange rates, and invoicing and tax treatment differ from a local supplier — check with your accountant before booking it.

Sizing the server and choosing a region

You do not have to buy the full size up front. Start with a spec that comfortably handles today’s load, watch CPU, memory and disk usage for a while, and upgrade when the numbers show you need to — most VPS and cloud servers can be resized with a short restart. When the application and the database share one small server, memory tends to run short before the CPU does. For the region, pick a data centre close to your users: if your customers are mainly in Taiwan, a Taiwan or nearby region gives noticeably lower latency than one in Europe or the Americas; if they are spread across countries, putting static assets on a CDN does more than moving the server around. Multi-region deployment and container orchestration can wait until availability or scale genuinely calls for them.

The mistakes people make most often

• Accounts held in an employee’s or contractor’s personal name: when the sign-up email and the credit card are personal, the account is hard to recover once that person leaves — and a lapsed card can get the service suspended for non-payment. Always open accounts with a company email address and a company payment method, with at least two administrators.
• No billing alerts: a misconfiguration, a runaway job, or a leaked key used to spin up mining machines can all go unnoticed until the invoice arrives. Set budget alerts on the day you open the account, and put two-factor authentication on every administrative login.
• Assuming the cloud brings backups and high availability automatically: a single cloud server still goes down when it fails, and snapshots have to be scheduled by you, stored somewhere else, and actually restored at least once before they count.
• Building a complex architecture on day one: container clusters, microservices and multi-region deployment mostly add operational burden and cost for a company without much traffic, and make the system harder to debug.
• Leaning on proprietary services with no exit plan: every cloud has services unique to it, convenient right up until you move and find whole sections need rewriting. Using them is fine — just know where you are locked in and roughly what leaving would take.
• Cutting over in one go when migrating: not lowering the DNS TTL in advance, switching before the new server has been fully tested, shutting the old host down too soon. Verify on the new environment first, keep the old server running for a while after the switch, and cancel it only once everything checks out.

There is no single right host, but the order of reasoning is always the same: first what you are hosting, then who will run it, and only then the specs and the price. If static hosting will do, you do not need a server; if a fixed-size VPS will do, you do not need to assemble a cloud architecture on day one — add layers when the need actually appears. If you are not sure where your website or system should live, which items on your current cloud bill could go, or you need someone to take over updates, monitoring and backups, Floatstone Digital can assess the architecture, plan the migration and handle the ongoing operations.