kvrun vs AWS Bedrock in London: AI governance compared

Amazon Bedrock is the obvious choice for teams already on AWS, and it runs in London (eu-west-2). kvrun is an alternative for teams that need open models on dedicated GPUs, processing that stays in the UK, and a KV cache they can prove is isolated and erased. This page compares the two for a UK buyer, and says plainly where Bedrock is the better choice.

This describes Bedrock's publicly documented behaviour at the time of writing. AWS changes model availability and routing options often, so check the current Bedrock documentation and your account team before you decide.

Summary

Model availability in London

Bedrock's catalogue is not the same in every region. A model can be listed in the console in London and still not be served from London, because some models are offered there only through a cross-region inference profile. The regional availability table is the source of truth, and it is worth checking model by model rather than assuming that "available in London" means "processed in London".

kvrun's catalog is smaller and made entirely of open-weight models. Every one of them runs on a dedicated instance in London, because that is where the fleet is. If the model you need is a proprietary one, such as a Claude or Nova model, Bedrock is the answer and kvrun is not.

Cross-region inference and residency

Cross-region inference lets Bedrock send a request to another region when the source region is busy or does not host the model. AWS offers it in two shapes:

• Geographic profiles, such as the EU profile. A request from London can be routed to London or to EU regions such as Frankfurt, Ireland, Paris and Stockholm. The exact list depends on the model.
• Global profiles, which can route to any supported commercial region in the world.

AWS's documentation is clear that prompts and outputs may leave the source region while a cross-region request is processed, even though logs and the configuration stay in the source region. For many teams that is fine: the EU and the UK recognise each other's data protection regimes as adequate, so a transfer to an EU region is lawful. But if a contract says UK-only processing, an EU profile does not meet it, and only in-region invocation of a model actually hosted in eu-west-2 does.

kvrun runs in London by default. There is no cross-region routing to switch off: a deployment's compute, its KV cache tiers and its storage stay in the region its policy names. See UK-based AI inference.

Isolation and the KV cache

Bedrock is a shared service. AWS documents that prompts and completions are not stored, not used to train models, and not shared with model providers, and that model providers have no access to the accounts where their models run. Those are strong commitments. What the documentation does not give you is a per-customer description of how cached attention state is partitioned inside the serving engine, because that is AWS's implementation to manage.

On kvrun, every deployment is a dedicated GPU instance, so no other customer's requests ever share your serving engine. Inside the deployment, each block of the KV cache is sealed with AES-256-GCM under a per-tenant key, and prefix-cache reuse never crosses tenants. Early internal benchmarks show under 3% added time to first token for this. Is prefix caching safe? explains why the partitioning matters.

Erasure and evidence

Because Bedrock does not store your prompts or completions, much of the erasure question falls on what you store yourself: invocation logs you have turned on, Knowledge Base sources, and any application logs. That is a reasonable model, and you should document it in your records of processing.

kvrun holds context in a governed KV cache, and erases it by destroying the session's key, which makes every copy on every tier unreadable at once. Each erasure produces a certificate, and allocation, access and erasure are written to an append-only audit log. If a regulator or customer asks for proof that a specific session's data is gone, that is the artefact you hand over. The GDPR Article 17 guide covers what such a certificate does and does not prove.

Cost

Bedrock bills on-demand inference per token, with batch discounts, and offers Provisioned Throughput for reserved capacity, billed hourly with optional commitment terms. kvrun bills per hour of accelerator time, plus storage and the platform fee shown before you deploy.

• Low or spiky volume: Bedrock on demand is usually cheaper, because you pay nothing when idle.
• Steady, high volume on one open model: a dedicated GPU often wins, because the cost per token falls as utilisation rises.
• Reserved capacity either way: compare Provisioned Throughput's hourly price with a kvrun deployment for the same model and concurrency.

Benchmark both on your own prompts. The cheapest option on a public benchmark is often not the cheapest on your traffic.

Where Bedrock wins

• You live in AWS. IAM, PrivateLink, CloudTrail, KMS and your landing zone already work, and Bedrock slots into them.
• Proprietary models. Bedrock serves models, such as Claude, that kvrun does not.
• Managed extras. Guardrails, Knowledge Bases and Agents save you building them.
• Scale and assurance. AWS's capacity and compliance record are hard for any smaller provider to match.

Where kvrun is the better fit

• You need UK-only processing without auditing every model's routing profile.
• You want open models on a dedicated GPU, with no other tenant in the serving engine.
• You need per-session erasure certificates and an audit log of KV cache access.
• You want to fine-tune an open model and serve the adapter on the same governed stack. See Fine-tune a model with LoRA or QLoRA.