Goodbye AWS Ambassador Program

Shortly after I joined my current employer as a cloud engineer, I was invited to participate in the AWS Cloud Warrior program, circa 2016. This was introduced as the AWS program for the best engineers in the AWS partner community, and its inception in Australia meant that it was filled with many significant people in the ecosystem that I knew from my time as one of the first Solution Architects for AWS in Australia & New Zealand.

This program aimed to have these senior engineers collaborate on cloud improvements, as well as engaging those engineers who sought to educate the wider (public) cloud community on how to achieve best practice. It encouraged this collaboration by routinely holding gatherings for the engineers in face-to-face meetings. AWS would fund domestic travel and accommodation, and bring service team members for various AWS Cloud Services to these gatherings. This was the partner community’s chance to provide direct feedback in a workshop-like environment on the improvements and limitations that were being experienced in the real-world, delivering and managing solutions for clients.

Key observations included long-term operations and supportability, continual security uplift, and removing the undifferentiated heavy lifting our form the client responsibility, and behind the dividing line of the Cloud services. This in turn reduced the cost to the end clients, across the board.

The benefits to AWS were huge. The service improvements were significant in the way that cloud was being shaped.

I was fortunate enough that my employer would fund my time to participate.

As a result, many ways to implement, scale and operate digital solutions in Cloud were championed by the Warrior community, who took to blogging, running user groups, and other activities to share this best practice and set the bar high for delivery across the entire global cloud engineering community.

This program got rolled over into the Ambassador program, and expanded to include the rest of the world. The ‘contributions‘ that the participants made were then tracked though a portal for the Ambassadors to submit to, with a simple gamification to encourage participation even further. The reward for this was an annual Ambassador Summit event, held face to face in Seattle, with flights and accommodation covered by Amazon.

I attended this several times, based on the body of blog submissions and community contributions I had made, and was racked #2 Ambassador in Australia and New Zealand for several years.

Again my time was gratefully funded by my employer to participate. These learnings were obviously shared deeply within the technical community within my employer, and over time, several of my colleagues also then joined me in this program, having met the eligibility requires. It was a point of differentiation to claim that my employer had multiple individuals in the AWS Ambassador program.

Then came the change. It wasn’t heralded, but felt. The Australian-domestic Ambassador meetings ceased. The funding for the Global Summit reduced to no longer covering flights to Seattle, but my employer was good enough to cover this for a year.

The following year, no funding at all was available for flights or accommodation, which made this impossible to participate from Australia.

Access to re:Invent, the global cloud conference in Las Vegas, continued as a complementary ticket to attend – but never with flights or accommodation cover.

Despite all of the benefits drying up, remaining in the program required the continuous investment in community support and education activities by the participants.

I looked to the AWS Ambassador program as being the equivalent of a Distinguished Engineer, or Most Valuable Professional as seen with other vendor ecosystems, but AWS had disengaged this demographic that had helped shape their platform.

Questions were asked regularly of the AWS team assigned (which turned over several times) about what was happening to the program. No answers that instilled confidence were shared.

I found I was explaining the existence and value of the program far more than AWS would; none of my global clients knew there was such a group of senior engineers that we were a part of, and so the entire value evaporated.

When the consulting services partner has to introduce and explain the vendors’ recognition program to the client, something is wrong. This was further highlighted multiple times with the lack of mention of ambassadors at the AWS Summits, replaced with the wide Community Heroes program.

I continued to participate in the program, but there was no interaction, no feedback, and no events across A/NZ since around 2023. Then at the end of 2024, I stopped submitting the cloud blog posts I authored into the portal. I wanted to see if would happen, what contact would be initiated.

The answer: Nothing.

Last week I found that I was no longer listed in the Ambassador portal. With no contact, no emails, no notice.

10 years: 2016 – 2025.

Will it change my blogging? Well, I’m much less at the coal-face these days, running a global practice in 14 countries. My focus for a long time has not been on my own delivery and training, but that of 1,800 other AWS cloud capable staff that I work with, for them to be at a level of capability that reduces risk and improves value to clients. This is how I scale myself.

I shared a lot of my perspectives with the other Ambassadors and AWS Service teams, and they shared with me. Rowan, Arjen, Ian, Cristian, Elliot and many more in this group across A/NZ: thank you for your insights and perspectives.

As an ex-AWS employee (one of the first few AWS Solution Architects in Australia, see my CV), I am disappointed and somewhat embarrassed at the way this program has been handled for the last few years as it was defunded and provided less value to the participants.

For interest, this is what this community looked like in 2022 at the Ambassador Summit in Seattle, with the size of the text reflecting the number of Ambassadors:

Some names have changed, some have gone away, and there are likely some new ones now.

A ton of IPv6 innovations in AWS

The last three months have seen a large number of IPv6 announcements from AWS. I’ll recount some of them here:

  • Organisations support IPv6 (link)
  • IPv6 for EC2 public DNS names (link)
  • Transfer family supports IPv6 (link)
  • Managed Service for Apache Fink adds IPv6 (link)
  • Resource Groups adds IPv6 support (link)
  • EFS supports IPv6 (link)
  • EFS supports IPv6 (link)
  • Private CA supports IPv6 (link)
  • Site-to-Site VPN supports IPv6 on outter tunnel endpoints (link)
  • DataSync supports IPv6 (link)
  • SNS expands IPv6 support to include VPC endpoints (link)
  • SQS expands IPv6 support to include VPC endpoints (link)
  • CloudWatch adds IPv6 support (link)
  • EventBridge supports IPv6 (link)

Much of the public (Internet) facing endpoints for these services are now dual-stack, supporting both IPv4 and IPv6 (for now).

But have a think about the VPC endpoints that are now either dual stack, or IPv6 only: this increases the direct integrations for potential IPv6 only subnets, or massive sizes, to integration endpoints such as SQS and SNS. These scale-out VM farms can now have these loosely coupled integrations that can support the sale of millions of virtual machines; the rest of the VPC may be on traditional IPv4 only allocations, but having that layer of messaging is now highly valuable.

We’re at a point now where it is almost commonplace for dual-stack endpoints for most AWS cloud services; and it should be the same for endpoints that customers make on the AWS cloud. There’s very little holding you back – certainly not cost, and in some cases, cost is (or will likely be) the driving factor for the rapid uptake of IPv6, for those that are ready.

Amazon SQS adds IPv6 support

At first glance, this seems like a strange thing to be even mildly excited about.

AWS has been added “dual stack” (having both IPv4 and IPv6 addresses) for their services for some time, and I have blogged about this many times over.

First, lets just go read the brief release, from April 21 of 2025 https://aws.amazon.com/about-aws/whats-new/2025/04/amazon-sqs-internet-protocol-version-6/.

OK, you’re back. First up, how is this working?

Well, the existing API endpoints, such as service.region.amazonaws.com have been extended with a new TLD. While amazonaws.com still exists in documentation, I discovered that dual-stack endpoints are on a different domain (docs), “api.aws”:

{protocol}://{service-code}.{region-code}.api.aws

While most services do not respond to ping, its a handy way of doing a DNS resolution:

> ping -6 sqs.ap-southeast-2.api.aws

Pinging sqs.ap-southeast-2.api.aws [2406:da70:c000:40:e3db:e3b2:7e93:ef41]

Your library (eg, boto) may not be up to date with this change, and even then, this new endpoint may not be in use.

Pro Tip: always update your boto library.

So why is this useful?

Let’s say you have a workload that uses SQS, running from your existing data centre, on a traditional IPv4-only network. Your application uses SQS as a fan out mechanism to despatch jobs to a fleet of worker nodes. Historically, this set of worker nodes, when listening to SQS for messages, would have had to all used IPv4; now they can exist on IPv6 only networks, and still receive their messages.

In effect, SQS as a control mechanism can now also be a bridge between hosts on either IPv4 or IPv6.

I’ve been championing the use of IPv6 with, in and on AWS since 2012; this year (2025) has continued to see additional services – like this – step up to include seamless dual-stack capability. At some stage, this will become table-stakes, required on service launch, and not a future service innovation.

Goodbye Optus

In 2010 my family returned to Australia to raise our child (now children) from the UK. I needed a local mobile phone service, and I selected Optus, as their pricing and offering (included data) was about right.

After a few years, I settled in to a $39/month, 30 GB plan. Around 2024, Optus advised me that the $39/month plan was becoming $49/month, with the same inclusions.

This week, another update from Optus advised this was now going to be $55/month, but the included data would increase to 70GB/month.

These days, I barely use more than 2 GB /month when I am not either at home or in one of my company’s offices… on the WiFi.

Enough.

There’s been very little visible improvement to the Optus network in the 21 years I have been on it. It’s over a decade since their competitor, Telstra, introduced IPv6 for their subscribers, and Optus has done… nothing.

The porting process took less than 30 minutes, and to be fair, the provider I have swapped to doesn’t do IPv6. But they are $25/month for 20 GB of traffic.

So I have just saved $360/year for what is approximately the same service. From complacent customer to ported away in four days end-to-end.

TCS is now the world’s largest AWS Consulting Services Partner, by count of AWS Certifications

It’s taken a long time, but the top of the chart of AWS Cloud consulting services partners has had a shake up on the leader board.

It’s not scientific, and could mean nothing, but I have been tracking the reported number of AWS Cloud certifications across the AWS Partner Community for a while now. It is a limited view into the commitment of these organisations to get their staff knowledge validated, at some level. That level could be Foundational (and thus non-technical), or it could be through to specialist. And for the last few years, the worlds largest partner by this metric has been Accenture.

But not today.

Today, Tata Consulting (TCS) overtook Accenture. Here’s the plot per day since the start of 2025, and the orange line (TCS) has just poked through the green line (Accenture):

TCS now stands in 1st spot with 29, 947, compared to 29,845 for Accenture, a gap of 102 AWS Cloud certifications.

Yesterday, Accenture was still in front on 29,983, and TCS was just 113 behind.

At it’s peak, Accenture could talk of more than 36,000 AWS Certifications. But in the recent past, this number has been steadily declining, while TCS and the rest of the providers have generally been ascending.

I have not seen any indication why Accenture’s total attributed AWS Certifications have been dropping. Perhaps a policy on paying the charges for their staff for re-certifications, perhaps staff attrition, mergers and de-merges. Perhaps a bunch of people who achieved the Cloud Practitioner (non-technical) 3 years ago as some initiative changed focus and let them expire.

Either way, it seems that the focus and drive that Accenture had shown, is not matched by the focus of TCS.

Does this matter in the AWS Cloud partner ecosystem? Perhaps not. But I find it interesting to consider.