Why we deliver AWS through a partner
Walk through any mid-market cloud consultancy's website and the same claim appears: "Multi-cloud architecture across AWS, Azure, and GCP." Sometimes Oracle Cloud is in there too. The implication is that the firm has equal depth in each — that whichever cloud the prospect already runs on, the consultancy has a senior team ready to engage.
It is almost never true.
What "we do every cloud" usually means
Behind the multi-cloud claim, three patterns are common:
| Pattern | Effect on the engagement |
|---|---|
| One cloud has the senior bench; the others have a single specialist or a junior team. | Engagements on the secondary cloud get fewer experienced hands, longer ramp-up, and more rework — but the prospect is rarely told this at sales. |
| Senior engineers are stretched thin across clouds they do not deeply know. | Architecture decisions get made with confidence that does not match the underlying expertise, and the cracks show up six months later when something needs to scale or recover. |
| Specialist subcontractors are brought in opaquely. | The prospect sees the consultancy's brand on every email; the work itself is delivered by a third party they were never told about. |
Each of these is a worse deal than a buyer would knowingly accept. They persist because admitting "we are deep in one cloud, not the others" feels like a sales liability.
A different position
Cloudwalker IT runs Azure as the primary practice. That is where the senior credentials sit — Microsoft Certified: Azure DevOps Engineer Expert and Azure Solutions Architect Expert — where the deepest project history lives, and where new work concentrates by design.
For AWS engagements, the practice partners with 010 Consulting. Both names appear on the work. The prospect knows from the first conversation that AWS delivery is joint, who is doing what, and why.
This is the inverse of the multi-cloud claim. Rather than asserting depth that is not there, the practice names exactly where its capability lives and where another firm carries it. Three things follow from that:
| Outcome | What it means |
|---|---|
| Capability is not stretched | AWS engagements are delivered by senior engineers who do AWS as their core practice — at 010 Consulting — rather than by Azure specialists trying to keep up. The work product reflects the difference. |
| Two firms' depth, not one firm's breadth | Combined, the engagement carries Azure capability from Cloudwalker IT and AWS capability from 010 Consulting. That is more depth than any single mid-sized practice can credibly claim. |
| Accountability is unified | Cloudwalker IT remains the primary point of contact. Joint delivery does not mean joint confusion — there is one engagement owner, one set of project decisions, and one place the buck stops. The partnership shapes who does the work, not who answers the phone. |
What the partnership actually looks like
In practice, joint engagements with 010 Consulting follow a consistent shape:
| Stage | Who leads, and how |
|---|---|
| 1. Initial scoping | Led by Cloudwalker IT. The practice surfaces the problem, evaluates whether AWS is the right fit, and decides how the engagement should be structured. |
| 2. Architecture and design | Joint. Cloudwalker IT brings the cross-cloud platform engineering practice — Terraform, Kubernetes, CI/CD patterns that travel across both clouds. 010 Consulting brings AWS-specific depth on the services involved. |
| 3. Implementation | Led by whichever party owns the relevant component. AWS-native services are implemented by 010's engineers; cross-cloud platform work, IaC, and operations remain with Cloudwalker IT. |
| 4. Operations and handover | Documented jointly, so the client team can run the result themselves or contract continued support from either firm. |
The model is not new. Joint delivery between specialist firms has been a fixture of professional services for decades. What is unusual in cloud consulting is the willingness to name the partnership openly, rather than paper over it with the primary consultancy's logo.
When this model is the wrong answer
The partnership model is not universal. There are engagements it does not serve:
| Engagement type | Why this model does not fit |
|---|---|
| Workloads that are AWS-only and entirely AWS-native | If the work has no Azure component, no cross-cloud platform layer, and no need for a primary engagement owner outside AWS, then 010 Consulting alone is the better answer. We say so when that is the case. |
| Engagements that need a single firm of record at enterprise scale | Some procurement processes require one vendor on the master agreement. The partnership model does not fit that shape. |
| Reciprocal claims about AWS | The model works in one direction because Azure is where Cloudwalker IT's depth genuinely sits. A symmetrical claim — that we could lead AWS engagements and partner for Azure — would be the same overreach this post is arguing against. |
Recognizing where a model breaks is part of using it well. When a project does not match, we say so and refer.
The thesis, briefly
A cloud consulting practice serves its clients best when it is honest about where its depth ends. Claiming breadth that does not exist is the most common form of consulting overreach, and it is paid for in the work product. Choosing a partner over claiming in-house capability turns the same engagement into something stronger — one firm at full depth on the primary cloud, a second at full depth on the secondary, and one engagement owner accountable for the whole.
That is what AWS through 010 Consulting means at Cloudwalker IT. It is not a sales handicap to be worked around. It is the position.