When to Hire Outside Cloud Help: the Real Questions
Bring in outside cloud help for decisions that are expensive to reverse and that you will live with for years: your account and identity structure, network topology, migration cutover, and the SLOs you commit to publicly. For reversible, well-trodden work, keep it in-house. The test is not "is this hard," it is "how much does it cost us in eighteen months if we get it wrong now."
That is the honest version of the question every engineering leader is really searching. Below are five of those questions, one per area we work in, phrased the way you would actually type them. Each answer gives you concrete steps, the trade-off you are making, and what to check before you change anything.
How do we structure a landing zone so it still works in three years?
The searched question is "what is a landing zone." The real one is how to structure it so you are not rebuilding it after the next reorg. The answer is to separate the things that rarely change (identity, logging, guardrails) from the things that change constantly (workload accounts), and to make new environments cheap to create.
On AWS, a Control Tower landing zone starts you with three shared accounts: management, log archive, and audit. Keep the management account nearly empty. Put workloads in their own accounts under a Workloads organizational unit, one account per workload per environment, so blast radius and billing follow the same boundary. A detail that pays off later: [keep the set of Regions Control Tower governs limited to where you will actually deploy, and use the Region deny control to shut off the rest. Ungoverned Regions are where shadow resources and surprise bills grow.
{
"Effect": "Deny",
"NotAction": ["iam:*", "sts:*", "cloudfront:*", "support:*"],
"Resource": "*",
"Condition": {
"StringNotEquals": { "aws:RequestedRegion": ["eu-west-1", "eu-west-2"] }
}
}On Google Cloud, the equivalent early decision is your resource hierarchy plus network shape. Google recommends separate Shared VPC networks per environment (development, testing, production) for most cases, with host projects owning the subnets and service projects attaching to them. Keep workloads on internal IPs and enable Private Google Access, so they can still reach Google APIs without external addresses, and "make it reachable" never quietly means "make it public." The trade-off, and what it costs later
The real decision is managed versus custom. AWS is direct about it: Control Tower is the recommended starting point, and a custom-built landing zone is for teams that have requirements only a custom solution supports and enough in-house expertise to maintain it.
| Approach | Good fit | What it costs later |
|---|---|---|
| Managed (Control Tower, CAF/ALZ, Google blueprints) | You want prescriptive defaults and central governance fast | You inherit the vendor's opinions; version upgrades change shared accounts |
| Custom (Terraform on Organizations) | Hard constraints the managed path cannot meet | You own every upgrade, guardrail and edge case, forever |
Managed is not free of surprises. When Control Tower moved to landing zone 3.0, it changed how CloudTrail is handled and deleted the account-level trails it had created. Read the upgrade notes before you click update.
Check first: whether you already have an AWS Organization or Google organization in use. Retrofitting governance onto live accounts is a different, riskier job than starting clean, and it is a common reason teams bring in help designing the landing zone and identity model.
Should we build a paved road or let every team pick its own tools?
The question behind "how do we do platform engineering" is whether to standardise. Standardise the boring layer, leave the interesting layer to teams. The boring layer is account and environment provisioning.
Azure calls this pattern subscription vending: a repeatable pipeline that hands an application team a ready subscription with networking, policy and budget already wired. Microsoft frames the platform team as the vending machine operator and the application team as the consumer, which keeps developers out of the connectivity and governance plumbing. AWS gives you Account Factory for Terraform for the same outcome. The point is that a new environment should be a pull request, not a ticket that sits for a week.
module "team_subscription" {
source = "Azure/lz-vending/azurerm"
location = "uksouth"
subscription_alias_enabled = true
subscription_display_name = "payments-prod"
virtual_network_enabled = true
virtual_network_address_space = ["10.40.0.0/22"]
}The trade-off is real. A paved road that is too rigid gets routed around, and shadow infrastructure is worse than no standard. Version your modules, publish them, and let teams pin a version rather than forcing a fleet-wide upgrade on your schedule. If your platform team is spending its week on provisioning tickets instead of the road, that is the signal to get help building the paved road rather than adding headcount to a queue.
Check first: count how a new service gets from empty repo to production today. If nobody can describe it in one diagram, tooling is not your first problem.
What SLO do we actually commit to, and who carries the pager?
"How do we do SRE" hides two harder questions: what number do we promise, and who gets woken up. Start with the number, because the pager follows from it.
An SLO is only useful with an error budget attached. Google's definition is arithmetic, not philosophy: your error budget for a period is (1 − SLO goal) × eligible events, so a 95% goal permits 5% of measured events to fail before you have missed. That single line ends most "should we ship or freeze" arguments, because it makes the cost of the next risky release visible.
Then alert on how fast you are spending the budget, not on raw error rate. A burn-rate alert fires when the budget is being consumed faster than the period allows, which catches a slow degradation and a sharp outage with the same policy and far fewer pages. Fewer, better alarms is the whole game.
One nuance worth stealing: an SLO should reflect when users are actually harmed. If nobody is using a service during a maintenance window, downtime in that window does not need to burn error budget. Do not commit to 99.9% on a batch system whose users are asleep.
Check first: whether you can currently measure one real user journey end to end. If you cannot, an SLO is aspirational. This is usually where an outside SRE review earns its keep: not new dashboards, but agreeing the two or three SLIs that matter and deleting the alerts that do not.
Are our IAM permissions actually least privilege, or just old?
The searched question is "how do we do cloud security." The one that keeps people up is narrower: who can do what, and how would we know if it were too much. Permissions rot the same way code does, by accretion.
On AWS, treat least privilege as a loop, not a launch. Start broad in development with AWS managed policies, then use access activity to reduce permissions before production. IAM Access Analyzer will generate a policy scoped to what a role actually used, based on CloudTrail history, which turns "least privilege" from a whiteboard ideal into a diff you can review.
aws accessanalyzer start-policy-generation \
--policy-generation-details '{"principalArn":"arn:aws:iam::111122223333:role/payments-svc"}' \
--cloud-trail-details file://trail.jsonThe trade-off is tightening too hard and breaking a quarterly job nobody documented. Mitigate it by looking at a long enough activity window to catch periodic workloads, and by rolling out scoped policies to non-production first. The cost of skipping this is not hypothetical: an over-permissioned role is the difference between a contained incident and a company-wide one.
Check first: unused access. Find roles and keys with no activity in the last 90 days and disable them before you rewrite anything. Dead credentials are the cheapest risk to remove and the most common finding when we start a least-privilege and guardrails engagement.
How do we move off-premises without a terrifying cutover?
The question is rarely "should we migrate." It is "how do we cut over on a Tuesday without a war room." The answer is to sort your estate before you touch it, and to prefer boring strategies for the bulk of it.
AWS frames the choices as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor. The most useful move in that list is often retire: an IT landscape assessment surfaces workloads with very low CPU and memory use that are prime retirement candidates. Every server you switch off is one you never have to migrate, secure or pay for again.
For the rest, resist the urge to modernise mid-flight. AWS is blunt that refactor is not recommended for large migrations because it modernises during the move and is the hardest to manage at scale. Rehost or replatform first, prove the cutover, then modernise in place once the pressure is off.
| Strategy | Use it when | Cost you defer |
|---|---|---|
| Retire | Low utilisation, no business value | None, this is the win |
| Rehost | Time pressure, app is stable | Cloud-native gains come later |
| Replatform | Small managed-service wins (e.g. managed database) | Some app changes and testing |
| Refactor | Only when the app blocks the goal | High effort; avoid during a large move |
Check first: dependencies. Map what talks to what before you move anything, because the failure mode is migrating an app and leaving a chatty database on-premises, then paying in latency and egress. A cutover is boring when the plan is dull and the rollback is tested. That planning, sequencing and rehearsal is exactly what our cloud migration service exists to make uneventful.
So when should you actually hire outside cloud help?
Hire it for the irreversible decisions and the first instance of a pattern: the landing zone design, the identity model, the migration wave plan, the SLOs you will be held to. Keep the repeatable, reversible work in-house, because that is where your team builds the muscle. Good outside help should leave you with Terraform, runbooks and decisions you understand, not a dependency. If a proposal cannot tell you what to check before changing anything, that is your answer.
Frequently asked questions
When is it cheaper to hire cloud consultants than to build the skill in-house?
When the work is a one-time, high-stakes design you will not repeat often, such as a landing zone, an identity model or a migration cutover. Building deep in-house expertise for something you do once every three years rarely pays back. For daily operations, patterns your team will run repeatedly, in-house ownership is almost always cheaper and more sustainable.
What should we check before letting anyone change our cloud setup?
Three things: your current account or subscription and identity layout, which regions and resources are actually in use, and the dependencies between workloads. Most expensive migration and security mistakes come from acting before this baseline exists. If a consultant proposes changes before establishing it, treat that as a warning sign.
Is a managed landing zone like AWS Control Tower enough on its own?
It is a strong starting point but not a finished environment. AWS itself describes Control Tower as a starting point where you still decide networking, access management and security for your own requirements. Managed services also change under you, as the Control Tower 3.0 CloudTrail change showed, so you still need to own upgrades and read release notes.
How do we set an SLO without over-promising?
Base it on a real user journey you can measure, then attach an error budget of (1 − SLO goal) × eligible events so the target has teeth. Do not commit to high availability during windows when no users are affected, because that burns budget for no benefit. Start with two or three SLIs that matter and alert on burn rate rather than raw error counts.
Should we modernise applications during a migration or after?
For large migrations, move first and modernise later. AWS advises against refactoring during the move because it is the most complex strategy and hardest to manage at scale. Rehost or replatform to prove a boring cutover, retire what you can, then refactor in place once the migration pressure is gone.
