How Should a UK Business Host Its Application? Decide by Architecture

A real UK marketplace inherited too much AWS

Appycodes took over Decofetch, a UK luxury-furniture marketplace, while the build was already in flight. The public project record describes an over-provisioned AWS setup left by a previous developer: expensive, difficult to reason about and attached to a product that still needed a reliable storefront, API and operational admin.

The difficult decision was not “AWS or another cloud”. The application already had three materially different surfaces: a server-rendered Next.js storefront, a Laravel commerce API and a bespoke catalogue admin. It also had image-heavy product media. Appycodes separated the web, API and admin into clean AWS ECS services behind a load balancer, added deployment pipelines, and kept media in Amazon S3 in London with Cloudinary transforms. The verified case study records an infrastructure-cost reduction of roughly 40% after the re-architecture.

The lesson is not that every retailer needs containers. It is that the deployable boundaries must reflect the product. ECS services can place tasks behind an Application Load Balancer, which supports path-based routing and multiple services; availability-zone rebalancing must still be configured and tested rather than assumed. AWS: ECS service load balancing · AWS: availability-zone rebalancing

The Appycodes Hosting Control Index

Score five pressure areas from 0 to 3. The total estimates how much infrastructure control the architecture needs; it does not measure prestige, scale or engineering maturity. Apply one hard gate afterward: if the team cannot patch, observe and restore the recommended tier, buy a managed version or simplify the design.

For example, a content-led Next.js site with one contact handler may score 3/15. A SaaS product with a relational database, scheduled imports and a four-hour recovery target may score 7/15. A marketplace with separate web/API/admin services, heavy workers, private networking and a 15-minute recovery objective may score 12/15. The score narrows the operating model; provider evaluation happens afterward.

Architecture first: a practical hosting table

This is not a ladder every product should climb. A managed frontend is often the more resilient design because the provider carries patching and capacity work. Containers are valuable when they isolate real workloads; a single container wrapping one simple web process can reproduce a platform’s features while transferring its operations back to you.

Host by execution boundary, not repository

A monorepo can deploy to several hosting boundaries, and several repositories can still form one fragile runtime. Draw the data and execution flow that users depend on. In most products, public delivery, web requests, background jobs and durable data need different scaling and recovery behaviour.

Keep compute close to the primary database. Vercel’s current guidance states that physical distance between a function and its data source affects latency, and its new projects default functions to Washington, D.C. unless the region is changed. A UK-facing CDN can therefore serve static assets locally while every uncached request crosses the Atlantic to a database or function. Configure location deliberately and verify it in the deployed environment. Vercel: configuring function regions

Recovery begins with business language. Recovery time objective (RTO) is how long the service may be unavailable; recovery point objective (RPO) is how much data loss the business can tolerate. AWS’s Well-Architected guidance makes both business decisions that technical teams use to select and test a recovery strategy. A provider’s availability promise is not your restore test. AWS Well-Architected: define RTO and RPO

Turn the discussion into a repeatable decision

The TypeScript below implements the Hosting Control Index as a transparent first pass. It deliberately returns a warning rather than silently recommending complex infrastructure to a team with no operations capability. In a real assessment, attach evidence to every input: job duration traces, data-flow diagrams, contract clauses, restore timings and an on-call rota.

type WorkloadFacts = {
  staticShare: number; // 0..1
  longRunningWorkers: boolean;
  customNetworkBoundary: boolean;
  specialisedRuntime: boolean;
  recoveryMinutes: number; // RTO
  maximumDataLossMinutes: number; // RPO
  operationsCapability: 'none' | 'shared' | 'dedicated';
};

export function recommendHosting(f: WorkloadFacts) {
  const stateAndRuntime = Number(f.longRunningWorkers)
    + Number(f.specialisedRuntime) * 2;
  const networkBoundary = Number(f.customNetworkBoundary) * 3;
  const recoveryControl = f.recoveryMinutes <= 15 ? 3
    : f.recoveryMinutes <= 240 ? 2 : 1;
  const dataRecovery = f.maximumDataLossMinutes <= 5 ? 3
    : f.maximumDataLossMinutes <= 60 ? 2 : 1;
  const dynamicSurface = f.staticShare >= 0.9 ? 0
    : f.staticShare >= 0.5 ? 1 : 3;

  const controlIndex = stateAndRuntime + networkBoundary
    + recoveryControl + dataRecovery + dynamicSurface;

  const route = controlIndex <= 4 ? 'MANAGED_FRONTEND'
    : controlIndex <= 8 ? 'MANAGED_APP'
    : controlIndex <= 12 ? 'MANAGED_CONTAINERS'
    : 'DEDICATED_CLOUD_ACCOUNT';

  const warning = controlIndex >= 9 && f.operationsCapability === 'none'
    ? 'Buy managed operations or simplify before release.'
    : undefined;

  return { controlIndex, route, warning };
}

Use the output to run a short proof rather than to purchase immediately:

1. Inventory execution. Measure cached pages, dynamic routes, peak concurrency, job duration, memory, CPU, local-disk assumptions, sockets and scheduled work.
2. Map data gravity. Name the system of record, storage region, processors, replicas, analytics exports, logs, support access and deletion path.
3. Set recovery objectives. Let the business choose RTO and RPO, then record the dependencies that make those targets possible or impossible.
4. Price the operating model. Include support tier, observability, backups, egress, environments, database, human operations and the cost of a failed restore—not only compute.
5. Build one representative path. Deploy the slowest request, longest job, busiest query and largest file; test cancellation, retry and duplicate delivery.
6. Exercise failure. Roll back a deployment, restore data to a clean environment, rotate a secret and remove an engineer’s access.
7. Document exit. Export data, DNS, certificates, secrets, infrastructure definition and runbooks into accounts owned by the business.

What “hosted in the UK” does—and does not—decide

For a UK business, location belongs in the decision, but it is not a substitute for mapping the legal entities and access paths. The ICO’s current cloud-transfer guidance says the geographic server location alone does not determine whether there is a restricted transfer: who owns or operates the servers, which provider entity is contracted, and whether another organisation outside the UK receives access all matter. ICO: are we making a restricted transfer?

The NCSC asks organisations to know where data is stored, processed and managed, which jurisdictions and supplier access apply, and what evidence supports the provider’s security claims. Its cloud principles cover resilience, separation between customers, operational security, identity, administration and audit as well as location. NCSC: the cloud security principles · NCSC: asset protection and resilience

Location can conflict with resilience. NCSC guidance notes that strictly limiting storage and processing to UK data centres can increase the impact of a localised disruption. That does not mean “send data anywhere”; it means decide the approved jurisdictions, contractual transfer route, encryption, privileged access and recovery locations together. NCSC: using SaaS securely

Common hosting decisions that fail in production

What Appycodes recommends for UK teams

After real implementations, our rule is simple: choose the least infrastructure that can meet the product’s measured boundaries and the business’s tested recovery target. Decofetch needed clean ECS services because its storefront, commerce API and admin were distinct operational surfaces. A brochure site does not. Appycodes handles this work through our UK product engineering service, from architecture assessment through deployment, observability and handover.

Primary sources

• ICO: restricted transfers and cloud services
• NCSC: the cloud security principles
• NCSC: asset protection and resilience
• NCSC: using SaaS securely
• AWS Well-Architected: define RTO and RPO
• AWS: ECS service load balancing
• Vercel: configuring function regions

Technical and operational guidance, not legal, regulatory, security or compliance advice. Provider features, plans and contractual terms change; re-check current documentation and obtain qualified advice for your workload.