# Private cloud tenancy

> A reference deployment in the client's own cloud account: private subnets, managed services over private endpoints and allow-listed egress.

- Web page: https://www.alesanalytics.com/docs/private-cloud-tenancy
- Markdown: https://www.alesanalytics.com/docs/private-cloud-tenancy.md
- Last updated: 2026-11-08
- Publisher: Ales Analytics

Reference deployment. GPU capacity in your own cloud account and region. Published 2026-11-08. Last reviewed 2026-11-08. Reviewed by Ales Analytics engineering.

Reference pattern. This page describes a deployment pattern; it does not describe any client system. Components are named by role, and products are examples.

## Context and constraints

The firm already runs most systems in one public cloud, its security team has approved that account, and it would rather rent GPU capacity than buy hardware. Data residency is satisfied by choosing the region.

## Diagram

![Reference pattern: everything in the client's own cloud account and region, reached over private endpoints.](https://www.alesanalytics.com/diagrams/rd-cloud.svg)

## Components (by role)

| Role             | Notes                                                                                                 |
| ---------------- | ----------------------------------------------------------------------------------------------------- |
| GPU capacity     | A Kubernetes node pool or dedicated GPU instances in the client's account; quota requested in advance |
| Serving engine   | One or more models behind the gateway                                                                 |
| Managed services | Database, object storage and secrets from the same cloud, reached through private endpoints           |
| Network          | Private subnets, no public IPs on workloads, egress through an allow-listed proxy or firewall         |
| Keys             | The client's key management service, with customer-managed keys where policy requires                 |

## Data flow and trust boundaries

All data stays in the client's account and region. Traffic between services uses private endpoints, not the public internet. The cloud provider is a processor under the client's existing agreement with it; no other vendor receives data.

## Identity and permissions

Workloads use the cloud's managed identities rather than stored keys. Users sign in through the existing identity provider. Each service has the narrowest role that works.

## What is logged

Requests through the gateway, with identity, model, sources and cost; infrastructure logs in the client's logging service; traces following the OpenTelemetry generative AI conventions.

## Failure modes

- **GPU availability.** Instances may not be available in the chosen region at short notice. Reserved capacity or a second instance type is planned up front.
- **Cost drift.** GPU nodes left running idle. Autoscaling to zero out of hours where latency allows, and cost reported by team.
- **Egress mistakes.** A misconfigured route to the internet. Egress is denied by default and tested.

## Alternatives

[On-premises](https://www.alesanalytics.com/docs/single-on-premises-gpu-server) when hardware is already owned or load is steady enough that owning is cheaper. [Hybrid with a gateway](https://www.alesanalytics.com/docs/hybrid-with-a-gateway) when some tasks benefit from a hosted model.

## Related decisions

Region, reserved versus on-demand capacity, managed versus self-run Kubernetes, customer-managed keys.

## Contact

solutions@alesanalytics.com, or https://www.alesanalytics.com/contact.

- Every page as Markdown: https://www.alesanalytics.com/llms.txt