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.

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.

Power in 2024

I spent much of the pandemic, from late 2020 until December 2023, building a new family home. In Australia power efficiency for cooling (and heating) are critical. We minimised the size of north-facing windows, and ensured that thermal insulation was installed in the double-brick exterior walls, as well as sisal insulation under the roof tiles and Colorbond sheets, and then standard insulation above the ceilings. Lighting is almost exclusively LEDs.

Exterior (garden) smart lighting is configured to come on at sunset, then dim to 50% brightness at 10pm, and then further dim to 3% at 11pm, turning off at sunrise.

One key point was using our roof space for solar power, and so we commissioned a 10 KW inverter, and a single Tesla Powerwall 2, which was installed post-handover of the property in mid December 2023.

In January of 2024, we saw around 68% of our power usage was from the installed power system. The air conditioner was the biggest draw, on hot days it would run at a draw of 10 – 11 KW, and despite there being energy in the Powerwall, its limit was 5KW in and out (this is now increased in the PowerWall 3).

Even without the air conditioner, most days the PowerWall would be exhausted by around midnight, leaving just the grid supplying until the sun came up the next day.

Here’s what December 29th looked like for me:

To further reduce power from the grid, I added a second set of panels on an additional 5KW inverter in May 2024.

By October 2024, the days in the southern hemisphere are getting longer, and the two inverters were at 100% load from mid-morning until 5pm or later, and we hit 90% of power coming from solar + battery for the month.

At this time, the Powerwall 2 was being discontinued, and existing PowerWall 2 installs cannot be expanded with PowerWall 3 units, so we divde in one more time and installed a second PowerWall in late October.

Since that second, we have not purchased any power from the grid.

The red is power purchased from the grid; the green is total power consumed.

Of course, we have yet to see the intense heat (and thus air conditioning draw) that February and March shows in my area.

You’ll also note that most of our power usage is in the afternoon and evening, meaning the mornings are great time to charge batteries up:

So what does that look like as a percentage saving per day:

The flatline at 100% is since the 2nd PowerWall went in.

I typically work from home these days (a global role that kicks in and out from9am until 10pm or later depending on the teams I am working with), but in an IT role means my work is mostly having my laptop (and screens) on.

One key question is the break even on this. If I use the last 3 weeks worth of data then it works out at a break even time of 7 years and 2 months. The last 300 days shows a 11 year break-even, but most of those 300 days did not have the 2nd PowerWall, nor the additional 5KW of solar generation. I imagine this will end up around an 8 years break even, within the 10 years warranty period of the battery, solar panels and inverters.

Two other points I get asked about:

  1. we put in a total of 15 KW of inverters as we have three phase power to the property; in our area the power company limits the size of inverter(s) you can installed depending upon 3 phase or single phase supply
  2. Having installed more than 5KW, the buy back for power fed back into the grid is $0.00. Nothing. Hence my system is set to reduce the amount fed to the grid, instead of sending as much as possible. If that was even $0.01 I’d remove that limit.

The cost of power from my provider, Synergy, increased on 1 July 2024 from 30.812c/KWH to 31.5823, or 2.5%. The connection fee (without consumption), went up from $1.1046/day, to $1.1322/day (just shy of 2.5%). This means I am still paying $413 per year (and increasing) to be connected to the grid, in case I run out of juice.

While I am no fan of the Tesla owner (and now government appointee?!), the technology appears to be sound, thus far. I’m pleased to have reduced my use of grid power to zero.

Lets see what the next 12 months of data produces.

My own little server

In 2004, I was living in London, and decided it was time I had my own little virtual private server somewhere online. As a Debian developer since the start of 2000, it had to be Debian, and it still is…

This was before “cloud” as we know it today. Virtual Private Servers (VPS) was a new industry, providing root login to virtual servers that individuals could rent. And so I started being a client of Bytemark, who in turn offered me a discount as a Debian Gnu/Linux developer. With 1 GB of RAM, the initial VPS was very limited, but I ran my own mail server (with multiple domains), several web site s(all with SNI TLS enabled web sites, my own DNS server, and more.

Several years back I took the move to migrate my domains from being self-hosted on a VPS, to using AWS Route53. It was a small incremental cost, but I had long since stopped playing around and experimenting with DNS, and I wanted something that had high availability then a single virtual machine.

I have run a blog on my web site since the mid 1990’s (30+ years now), and WordPress has been my main platform since the late 2000s. This is WordPress now (2024), however a few years back I slotted AWS CloudFront in front of my origin service, to provide some level of global caching.

Several of the websites I run have also moved off to Amazon CloudFront, in particular all my small MTA STS web sites that serve just one small text file: the Mail Transport Agent Strict Transport Security policy document.

I still run my own mail server, with Exim4, PostgresQL, DoveCot Spamd, ClamD, etc. It lets me experiment with low level stuff that I still enjoy.

I have a few other services I want to move out of my VPS and into individual cloud-hosted platforms, but not everything is ready et. However a recent review of my VPC costings, and a forced migration from ByteMark (ioMart) to a new organisation UK Hosting, forced me to reconsider. So I took the inevitable change and migrated the entire VPS to AWS EC2 in Sydney, closer to where I am most of the time.

And so it comes to pass after 20 years, thank you to the team at Bytemark for my UK VPS.

Web Security & Service Standards 2024

Its late in 2024, and its time to recap the transitions in the technology space for Internet and web security. I’ve been reading the Internet Society’s pulse pages, and it gets me thinking…

  1. HTTPS: generally this is well deployed with 97% of top 1000 web sites. But conversely, some 30 web sites don’t think the integrity (let alone the privacy) of data transfer from/to their web site is worth the effort? Here’s looking at you, Australia BOM, still force redirecting clients to unencrypted HTTP, particularly in light of your security incidents and increased funding for cyber security over the last decade.
  2. TLS 1.3: Introduced in 2018, it only started taking off in 2019, and now sites as being available on 80% of the top 1000 sites. That’s some 200 sites that haven’t had the upgrade from older versions, which is almost exclusively TLS 1.2 (even older versions are gone, luckily).
  3. HTTP/3: Based on a UDP transport instead of TCP, its seen a massive DROP in usage in the top 1000 with sites switching back to HTTP/2.
  4. IPv6: Now sitting around 45%. For me, this is a trivial item to enable on Cloud; but some Internet Access Providers (ISPs, Telcos) are sweating their existing installations instead of moving their engineering forward (hello Optus: is IPv6 still not Yes!).

For me, these four technologies are a baseline implementation that do not add significant additional cost for operations, but provide speed, security, and connectivity enhancements.

I always recommend tools like SSLLabs.com, SecurityHeaders.com, Hardenize.com, and SSL.sh to test your services and help improve your delivery. If your web service misses these items, then you may need to consider upskilling your team or service provider, or switching your telco/carrier.