When you need it
Your cloud started as one account or subscription and grew team by team. Access is hard to review, environments drift apart, and every new project asks for an exception.
What sets the quote
- One cloud per sprint: AWS, Microsoft Azure or Google Cloud.
- New estate, about 3 weeks: up to 10 new AWS accounts, Azure subscriptions or Google Cloud projects for 3 environments in 1 region, with 1 network hub and no hybrid links.
- Existing estate, about 6 weeks: the same foundation, built next to what you run, with your current workloads then brought under it, sized from a free read-only inventory query (AWS Resource Explorer, Azure Resource Graph or Google Cloud Asset Inventory).
- An existing estate typically means up to 1,500 resources, 20 workloads, 2 regions with a network hub each, and 2 hybrid links (site-to-site VPN, Direct Connect, ExpressRoute or Cloud Interconnect).
- Single sign-on from one identity provider, such as Entra ID, Google Workspace or Okta.
- More clouds, regions or hybrid links are quoted after sizing.
What changes
- New teams get a compliant account, subscription or project from code, not from a ticket queue.
- Security rules are enforced by the platform, so review time goes to design instead of checklists.
- Production, test and development are separated, with a clear path to add the next environment.
- People sign in through single sign-on, and pipelines deploy without stored cloud keys.
What you get
- Organisation structure as code: OUs and accounts on AWS, management groups and subscriptions on Azure, or folders and projects on Google Cloud
- Account, subscription or project vending, so a new one arrives through a pull request
- Single sign-on and role-based access through your identity provider
- Guardrails as code (SCPs and RCPs, Azure Policy or Organization Policy) with documented exceptions
- Hub network with private connectivity, central DNS and controlled egress
- Central logging and security posture monitoring
- Terraform in Git with a keyless pipeline and approval gates
- Handover documentation, runbooks and a walkthrough for your team
What we build on each cloud
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Organisation | AWS Organizations with Control Tower, or Terraform account vending | Management groups with subscription vending | Folders with a project factory |
| Single sign-on | IAM Identity Center | Entra ID with PIM | Cloud Identity or workforce identity federation |
| Guardrails | SCPs and RCPs | Azure Policy | Organization Policy |
| Hub network | Transit Gateway with shared egress | Virtual WAN or hub VNet | Shared VPC or Network Connectivity Center |
| Central logging and posture | CloudTrail for the whole organisation, Security Hub, GuardDuty and Config | Activity log and diagnostic settings, Defender for Cloud | Cloud Audit Logs with aggregated sinks, Security Command Center |
| Keyless pipeline | OIDC to IAM roles | Entra ID workload identity federation | Google Cloud Workload Identity Federation |
We run the same approach for the AWS platform of Rayna Tours.
Not included
- Moving application workloads to another region or cloud (see migration and resilience)
- Firewall inspection and private app access (see the Zero Trust network build)
- Cloud, firewall and identity licence running costs
- Running the platform after the support window (available as a care plan)
What we need from you
- AWS: AdministratorAccess in the management account for the build, removed at handover.
- Azure: Owner at the root management group, plus Privileged Role Administrator in Entra ID for the PIM set-up, both removed at handover.
- Google Cloud: Organization Administrator, Folder Admin, Organization Policy Administrator and Billing Account User for the build, removed at handover.
- An identity admin who can add the single sign-on app and groups in your identity provider.
- A platform owner who reviews pull requests and makes decisions, about 3 hours a week.
How it works
Free 30-minute call, then a written fixed quote (after the sizing query for an existing estate).
Kick-off workshop to agree structure, naming, environments, regions and IP ranges.
Build in short iterations; you review every change as a pull request.
Test the guardrails against realistic non-compliant changes before handover.
Handover session, runbooks and a support window for the first changes.
At a glance
- Duration
- 3–6 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related work
Rayna Tours
Moving production out of an impaired cloud region
When the AWS region running a travel booking platform was disrupted, production ran on a recovery stack within about a day, and the whole platform moved to a new region within about a month.
- ~1 day
- to run production on a recovery stack
- ~36 h
- to rebuild the shared services as code
Rayna Tours and TechnoHeaven
From one legacy account to a governed multi-account AWS platform
A multi-account AWS foundation for a travel group's twenty or so services, with guardrails, keyless pipelines and a temporary environment for every pull request, all defined in Terraform.
- 8
- AWS accounts in one organisation
- 40+
- Terraform repositories
Related services
Cloud foundation check
In 1–2 weeks, we review your AWS, Azure or Google Cloud foundation against the CIS benchmark and tie every finding to evidence, the affected resources and a fix.
Zero Trust network review
A one-week review of how traffic enters, leaves and crosses your AWS, Azure or Google Cloud networks, with evidence for every finding, a target Zero Trust design and a prioritised roadmap.
Migration check
In 1–2 weeks, we assess what you run on-premises or in another cloud, with a migration approach per application, a wave plan and a cost estimate for AWS, Azure or Google Cloud.