When you need it
Your teams want to run AI agents and call hosted models, but your cloud was not set up for them. Agents end up in shared environments with long-lived API keys, and nobody can say which models or regions are allowed.
What sets the quote
- One cloud per build: AWS, Microsoft Azure or Google Cloud, added to your existing landing zone.
- Four weeks: up to 3 environments, 2 AI workloads (agent services or AI-enabled apps), 1 model provider and 2 data stores (for example a private database and a cache).
- Six weeks: up to 4 environments, 6 AI workloads, 2 model providers and 6 data stores, plus a connection to your central AI gateway.
- Each environment gets its own AWS account, Azure subscription or Google Cloud project.
- Larger scopes or a second cloud are quoted after the call.
What changes
- AI workloads run in their own part of your cloud and inherit the guardrails you already have.
- Only approved models and regions can be used; the platform blocks the rest.
- Every agent has its own keyless identity, so you can see and limit what each one does.
- New AI workloads start from code on a tested foundation, not from an exception.
What you get
- A dedicated place for AI workloads under your existing guardrails: an OU, a management group or a folder, with one account, subscription or project per environment
- Model and region allow-list as policy: SCPs, Azure Policy or Organization Policy
- Keyless, least-privilege identity for each agent and app
- Private network paths to model endpoints and controlled egress
- Hosting pattern for agent services: containers, a private database and a cache
- Policy tests that show the guardrails block what they should, such as a call to an unapproved model
- Terraform in Git, a keyless CI pipeline and handover documentation
What we cover on each cloud
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Placement | An OU with one account per environment | A management group with one subscription per environment | A folder with one project per environment |
| Models and regions | SCPs that limit Amazon Bedrock models and Regions | Azure Policy that limits regions and which models can be deployed | Organization Policy constraints for resource locations and allowed Vertex AI models |
| Agent identity | IAM roles for ECS tasks or EKS Pod Identity, no access keys | Managed identities with Azure RBAC, no client secrets | Attached service accounts or Workload Identity Federation for GKE, no key files |
| Private model access | VPC interface endpoints for Amazon Bedrock | Private endpoints for model endpoints | Private Service Connect and VPC Service Controls for Vertex AI |
| Hosting pattern | ECS or EKS, RDS for PostgreSQL, ElastiCache | Container Apps or AKS, Azure Database for PostgreSQL, Azure Managed Redis | Cloud Run or GKE, Cloud SQL for PostgreSQL, Memorystore |
| Logging | CloudTrail and Bedrock model invocation logging | Activity log and diagnostic settings | Cloud Audit Logs and log sinks |
Not included
- A new organisation-wide landing zone (quoted as a landing zone sprint if you do not have one)
- Building, training, fine-tuning or hosting models, and GPU capacity
- Building or operating an AI gateway (we connect the platform to yours, or design the pattern with your team)
- Building the agents or the AI features of your apps
- Model evaluations, red-teaming or prompt-injection testing
What we need from you
- AWS: an administrator role in the management account, or your existing landing zone pipeline, to create the OU, accounts and SCPs.
- Azure: Management Group Contributor and Resource Policy Contributor on the target management group, plus a billing role that can create subscriptions.
- Google Cloud: Folder Admin, Project Creator and Organization Policy Administrator at organisation level, plus Billing Account User.
- A list of approved models and regions, or a decision owner who can approve them.
- Your platform owner and one lead per AI workload for workshops and pull request reviews.
How it works
Free 30-minute call, then a written fixed quote based on your environments, AI workloads, model providers and data stores.
Workshop to agree the AI workloads, models, regions and data rules in scope.
Build in short iterations; you review every change as a pull request.
Policy tests against realistic agent scenarios, then handover and templates for the next agent.
At a glance
- Duration
- 4–6 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related work
Rayna Tours
A governed home for an AI agent service
An AI platform strategy for a travel business, and hosting for its new AI agent service on the existing AWS platform, with private data stores and the same guardrails as every other workload.
Related services
AI risk quick scan
In 1–2 weeks, a read-only review of the AI tools, model keys, agents and data flows in your organisation, with the risks ranked and a 30/60/90-day plan to fix them.
Governed AI coding agents
Let your engineers use AI coding agents on real repositories, with written working agreements, grounded answers, read-only cloud access and human consent before every production change.
AI model access and release gates
Give your applications one controlled route to AI models with a keyless fallback, keep model calls in EU regions and hold generative features back until evaluation and data-protection sign-off.