Originally reported by CRN Australia. This article summarises and contextualises those reports for a DevOps engineering audience.
AWS Told Partners Not to Say ‘Multi-Cloud’
In August 2019, Amazon Web Services released two partner-facing documents — an updated Co-Branding Guide and an APN Messaging and Branding Guide — that contained notably restrictive language about how AWS Partner Network (APN) members could describe cloud infrastructure in co-branded and general marketing materials.
The language in both documents was explicit:
“AWS does not allow or approve use of the terms ‘multi-cloud,’ ‘cross cloud,’ ‘any cloud,’ ‘every cloud’ or any other language that implies designing or supporting more than one cloud provider.”
AWS Co-Branding Guide (August 2019)
The APN Messaging and Branding Guide went further, extending the restriction to general marketing materials and adding that architecture diagrams or graphics depicting multiple cloud providers — whether identified by name, logo, or described generically — would also not receive AWS approval.
What Partners Were and Were Not Allowed to Say
The guidance created a detailed set of approved and prohibited terms. Key restrictions included:
- Banned terms: “multi-cloud”, “cross cloud”, “any cloud”, “every cloud”, “AWS hybrid”, “AWS hybrid cloud”, “AWS Partner”, “integrated” or “integrates” (when describing how a solution works with AWS services), and “runs in AWS”.
- Approved alternatives: “the cloud”, “your cloud”, “hybrid”, “hybrid architecture”, “hybrid cloud” (when not used to describe AWS itself), “runs on AWS”, “APN Partner”, and “member of the APN”.
The guide also prescribed how partners should frame hybrid architectures. Rather than positioning a solution as spanning multiple environments generically, partners were instructed to describe their offering as “extending or connecting an on-premises environment to AWS.”
Even the word “integrated” was flagged. The guide stated that using it implied a closer technical relationship with AWS than was appropriate, and partners were told to avoid it when describing how their solutions interact with AWS services.
One particularly granular rule concerned the preposition used with AWS: partners were told that something runs on AWS, not in AWS — because “in” implies deeper integration than “actually is.”
Google Cloud Responded Publicly — and Pointed to Anthos
Robert Enslin, who had become Google Cloud’s President of Global Customer Operations in April 2019, responded to CRN Australia’s coverage with a pointed tweet:
“Multi-cloud is a reality for many customers, and we embrace openness and choice. #Anthos”
Robert Enslin, Google Cloud (via Twitter, August 2019)
The hashtag was a deliberate reference. Google had unveiled Anthos at Google Cloud Next in April 2019 — the same month Enslin joined the company. Anthos is a hybrid and multi-cloud application management platform built on Kubernetes and Istio. Its core proposition is the ability to deploy and manage containerised workloads consistently across on-premises infrastructure, Google Cloud, and third-party clouds — explicitly including AWS and Microsoft Azure.
For Google Cloud, multi-cloud was not just a marketing term to be argued over — it was a product category that Anthos was built to serve. Enslin’s tweet framed AWS’s branding restrictions as being out of step with how enterprise customers were actually operating their infrastructure.
Why These Branding Rules Matter to Engineers and Architects
From a purely technical standpoint, it might be tempting to dismiss partner branding guidelines as a marketing concern. But the restrictions carried practical implications for DevOps teams and solutions architects working inside the AWS partner ecosystem:
- Architecture diagrams submitted for AWS co-marketing approval could not depict multi-cloud topologies — even for solutions that genuinely operated across clouds.
- ISVs and managed service providers building legitimately cross-cloud tooling faced a choice: sanitise their messaging to qualify for AWS joint marketing, or accurately represent their capabilities and forgo that channel.
- The “hybrid” carve-out had a catch. While the word “hybrid” was permitted in some contexts, it could not be used to characterise AWS itself — limiting how partners could describe AWS’s role in hybrid architectures that also included on-premises environments.
AWS’s Position and Its Silence
AWS did not respond to requests for comment reported by CRN Australia at the time. The company has historically emphasised the depth and breadth of its own platform rather than positioning around interoperability with competitors — a stance broadly consistent with these branding guidelines.
The restrictions did not prevent AWS partners from building multi-cloud solutions. They governed what could appear in co-branded and APN-approved marketing materials — a meaningful distinction, but one that still shaped how partners communicated their value propositions when working alongside AWS’s brand.
The Broader Context: Multi-Cloud as a Fault Line
The 2019 exchange was a visible moment in an ongoing strategic tension between the major cloud providers over how the industry defines and promotes multi-cloud adoption. Google Cloud and Microsoft Azure have both publicly embraced multi-cloud and hybrid messaging as differentiators — in part because AWS held a commanding market-share lead and had less commercial incentive to encourage workloads to spread across competitors.
For engineering teams evaluating platform strategy, the episode was a useful reminder that vendor marketing guidelines, partner programme terms, and product positioning can all reflect underlying competitive dynamics — and that the term “multi-cloud” itself had become contested commercial territory, not just a neutral infrastructure descriptor.
Original reporting: CRN Australia, August 2019.