Multi-cloud — AWS and Google Cloud
Azure-first does not mean Azure-only — but multi-cloud should be a decision, not an accident.
- Practice area
- Cloud and licensing
- Primary platform
- Azure
- Usually sponsored by
- CIOs
- Delivered from
- Accra, Ghana
A complete, owned inventory of cloud accounts with consistent identity and guardrails across platforms.
Deliberate use of AWS and Google Cloud alongside Azure, with governance that prevents operational fragmentation.
Why organisations ask for this work
These are the situations that lead to this conversation. If more than one is familiar, there is usually a case worth examining before anything is bought.
Accounts outside IT's visibility
A proof of concept, a marketing subscription, and an acquired platform nobody has inventoried.
Inconsistent identity and monitoring
Each platform has its own access model, so nothing can be reported on together.
Orphaned resources accruing cost
Unattached storage and idle compute continue to bill with no owner attached.
What this service covers
Most multi-cloud estates were not designed. They accumulated: a developer opened an AWS account for a proof of concept, a marketing team adopted a Google service, an acquired business arrived with its own platform. The result is several clouds with inconsistent identity, uneven monitoring, and no single person able to describe what is running where.
Deliberate multi-cloud is different, and occasionally the right answer — a specific managed service, a data residency requirement, a resilience objective, or genuine commercial leverage. Accidental multi-cloud simply multiplies your operational surface without adding capability.
Our work here is mostly rationalisation and governance: establishing what exists, deciding what belongs where, applying consistent identity and guardrails, and creating one operational view. Where a second cloud earns its place, we make it properly supportable rather than tolerated.
Estate discovery and rationalisation
Finding every account, subscription, and project — including the ones outside IT's visibility — and deciding what stays.
Landing zones and guardrails
Account structure, policy baselines, and budget controls so new workloads start compliant.
Workload placement analysis
Deciding platform per workload on capability, cost, data gravity, and operational fit.
Identity alignment
Consistent authentication and access patterns across clouds, usually anchored on Entra ID.
Hybrid and inter-cloud networking
Secure, monitored connectivity between on-premises sites and multiple cloud platforms.
Unified operations and cost control
One monitoring and reporting view, with tagging and budgets applied consistently.
What you receive, and what changes
Every engagement produces written artefacts. They are listed here so the scope is agreed before work starts rather than interpreted afterwards.
Artefacts you receive
- Multi-cloud estate inventory with ownership per account
- Workload placement recommendations and rationale
- Landing zone design and guardrail policy set
- Cross-cloud identity and access model
- Consolidated cost and monitoring reporting
Outcomes to expect
- A complete, owned inventory of cloud accounts
- Fewer orphaned resources quietly accruing cost
- Consistent identity and guardrails across platforms
- Platform choices you can justify to an auditor or a board
How delivery runs
Each phase has a defined entry and exit point, so you always know what is being decided, by whom, and what happens next.
Discover
Identify every cloud account, its owner, its spend, and what it actually runs.
Decide
Agree which platform hosts which workload, and what gets consolidated or retired.
Establish guardrails
Landing zones, identity integration, tagging, and budget alerts implemented.
Operate
Single operational view with clear ownership and regular cost and posture review.
The technology this service touches
Platform choice follows the workload. These are the products most often involved in this practice area, and the vendor relationships behind them.
- Azure
- AWS
- Google Cloud
- Entra ID
Accredited means AAG Cloud Connect holds that vendor’s partner mark. Capability means we design, deliver, and support the platform without holding a formal partner designation for it. Both are stated plainly so nothing is implied by a logo.
Microsoft
Accredited partnerCloud platforms
The centre of our practice. We hold the Cloud Solution Provider relationship, so subscriptions, licensing advice, and first-line escalation sit with us.
Google Cloud
Accredited partnerCloud platforms
Used most often for data and analytics work, and for organisations with an established Workspace footprint.
Amazon Web Services
Accredited partnerCloud platforms
Where a workload is better served by AWS, we design and operate it properly rather than leaving it unsupported at the edge of the estate.
Who this service is for
Work of this kind is normally sponsored by one of a small number of roles, each of whom is measured on something different.
- CIOs
- Cloud and platform engineers
- CFOs
CIOs and IT managers
You need architecture that your team can actually run, vendors consolidated, and a partner who escalates instead of deflecting.
CFOs and finance leaders
You need licence spend that reconciles, renewals without surprises, and a cost model you can defend in a budget review.
Deliberate
not accidental
Most multi-cloud estates were never designed
The work is usually rationalisation: establishing every account and its owner, deciding what belongs where on capability and cost, applying landing zones and guardrails so new workloads start compliant, and producing one operational view. Where a second platform genuinely earns its place, it becomes properly supportable rather than tolerated.
This describes an engagement pattern typical of this service. It is not an account of a named client, and no figures here are drawn from a specific organisation.
Frequently asked
The questions organisations genuinely ask before committing budget to this work.
No. Multi-cloud adds real operational cost — more skills, more tooling, more governance. It is worth it when there is a specific capability, resilience, residency, or commercial reason. Otherwise consolidation is usually the better decision.
Yes. Azure is our deepest bench, and we are direct about that, but we design, deliver, and support workloads on AWS and Google Cloud including landing zones, migrations, and ongoing operations.
Tagging enforced at creation, budgets with alerts per account, regular review of unattached and idle resources, and commitment-based discounts only once usage patterns are stable enough to justify them.
Running both long-term is usually more expensive and more confusing than it looks. Where both exist we will map the overlap and recommend a primary platform, with a migration path if consolidation makes sense.
Related services
These practice areas are commonly delivered alongside this one, because the gaps between them are where problems tend to appear.
Cloud consulting and architecture
A target architecture and cost model your engineers agree is buildable and your board can approve.
View serviceInfrastructure and hardware
Platforms sized against measured workload, procured through authorised channels, with a refresh plan agreed up front.
View serviceManaged services and support
A named owner for your environment, with published severity-based response targets and a monthly review that drives change.
View service
Talk to us about Multi-cloud
Send a short brief on where you are now with Multi-cloud. You will get a considered response setting out what we would need to establish next, rather than a generic brochure.
Your enquiry will be tagged Multi-cloud so it reaches the right specialist first time.