Category: Rants

After nearly 12 years, my journey with Akkodis (formerly Ajilon) has come to an end

When I joined the organisation in 2014, I was the only team member holding an AWS certification. My first assignment was supporting the delivery of the Landgate Land Registry as a Service (LRaaS) project—a pioneering cloud-native platform that transformed land registry services through transaction automation and cloud migration.

I couldn’t have imagined where that opportunity would lead.

At the time, AWS offered just a single certification. As a former AWS Solutions Architect, I was fortunate to be part of the first cohort at AWS to achieve that certification. More than thirteen years later, I have maintained continuous AWS certification and remain one of the world’s longest continuously AWS-certified professionals.

Over the following decade, I had the privilege of helping build Akkodis’ AWS capability from a single cloud specialist into a globally recognised AWS practice spanning more than 10 countries and supporting over 1,600 cloud professionals.

Alongside leading the global AWS practice, I also served as the Global AWS Alliance Lead, managing the AWS partnership for a business with more than €3.7 billion (US$4 billion, AU$6 billion) in annual revenue. More recently, I had the opportunity to mentor global practice leaders across our AWS, Cybersecurity, Infrastructure Support and Microsoft Cloud businesses, supporting a professional community of more than 5,000 specialists.

Looking back, one aspect I’m especially proud of is that much of this was achieved while working remotely from Australia, with a remarkably lean operating budget. It reinforced my belief that great leadership is measured by influence, collaboration and outcomes—not geography or organisational size.

Throughout my career, I have believed that leadership is about enabling others to succeed.

Whether it was developing global enablement programs, promoting certification, creating technical content, mentoring practice leaders, strengthening partnerships, or helping shape strategy across multiple regions, my focus was always the same: creating opportunities for others to grow.

There was never a large global AWS office behind these initiatives. From building practice collateral and case studies to certification programs, knowledge sharing, community engagement, partnership management and external practice development, these responsibilities were part of a role I was proud to build and continuously evolve.

Serving as the Global AWS Alliance Lead also provided a front-row seat to the evolution of the AWS Partner Network. I’ve seen partner programs introduced, refined and retired, but one principle remained constant: partnerships are most valuable when they create opportunities for people.

The AWS partnership was not simply about competencies, designations or rankings. It was about recognising the incredible engineers, architects, developers, analysts, testers and consultants whose expertise delivered outstanding outcomes for our clients every day.

To every client who trusted me and our teams—thank you.

To the practice leaders around the world who collaborated so generously—thank you.

To our marketing teams who helped showcase our capabilities—thank you.

And to every engineer, architect, developer, analyst, tester and consultant I had the privilege of working alongside, thank you. Your commitment to learning, innovation and technical excellence helped position Akkodis among the Top 100 AWS Partners worldwide by count of concurrent AWS certifications. That achievement belongs to you.

As many people know, I’ve always believed in leading by example. Only a few weeks ago I completed another round of AWS recertifications, with more planned later this year. Continuous learning has always been central to my career, and I hope it’s something I’ve encouraged in others as well. I remain with 9 active AWS certifications.

So, what’s next?

For now, I’m taking some time to reflect, recharge and consider the next chapter.

I’ll continue to be based primarily in Perth while remaining available for AWS advisory, consulting and professional services engagements.

Over the past two decades I’ve helped organisations across enterprise, government and highly regulated industries develop cloud strategies, modernise platforms, strengthen security, build partnerships and deliver complex transformations. I’m looking forward to continuing that work through Nephology, providing independent, client-first AWS consulting.

If you’re looking for strategic cloud leadership, executive advisory services or deep AWS expertise, I’d be delighted to connect.

? https://www.nephology.net.au

I’ve also always encouraged the people I’ve mentored to continuously invest in themselves. One initiative I’ve championed is the Cloud Resume Challenge. Rather than simply recommending it, I completed it myself because I believe leaders should demonstrate the behaviours they encourage in others.

You can view my Cloud Resume Challenge CV here:

? https://cv.jamesbromberger.com

Finally, many people have asked whether I’m hiring.

Not just yet…

On va voir.

DNS is everywhere. Your laptop uses it. Your phone uses it. Your production servers use it. Its everywhere, but for many people, once its working, they forget about it. And yet, DNS can be used for data transfer (several bytes at a time), it can be used to lookup malicious domains, it can be used for remote command and control for botnets.

So why aren’t you securing it in your production data center and cloud deployments? If you don’t have a strong handle on DNS, and just blindly rely on DNS resolution and nothing else, then you are overlooking a gaping hole in your security posture.

In this post I am looking at production “server” deployments: virtual machines, EC2 instances, running in your network or VPC or equivalent.

Use a specific DNS Resolver

You should clearly have a set DNS resolver, and ensure it is working. I’ve seen one government organisation that had 3 DNS resolver IP addresses handed out in DHCP, but only two servers were in use, randomly causing DNS timeouts and unexpected delays for their entire network. If you have a DNS server, monitor it to ensure it is working, and how much it is being used. Look for anomalies. increases in queries, unusual query types . These suspicious activities could be an indicator of compromise (IoC)

Block server traffic initiating outbound connections

Block new outbound traffic from your servers, except the items that you do need your servers to establish connections for (eg, API integration). even then, you may want to have a specific proxy handle those connections, so you can validate the outbound connections are going to where you want them to.

Only permit your DNS resolvers to make outbound TCP/UDP port 53.

There’s no reason that your hosts in your network should be making direct DNS queries to the outside world. Not only block it, but report on this very suspicious behaviour: its another indicator of compromise.

Configure DNS Blocking

There’s a load of lists online that are constantly updating that contain malicious domains, those used for botnet command and control, that would be ideal for not doing DNS resolution for (and alerting on if a query comes from your severs).

Continuously update these lists as they are updated, and monitor them – ensure they are not truncated to zero, or oversized. Perhaps configure some rules to ignore blocklist entries if they were to contain known good domains in case the blocklist itself gets compromised.

Doing this in AWS VPC

• Always use the VPC DNS Resolver.
• Configure your EC2 instances to use the link local resolver address.
• Never create a Security group that allows OUTBOUND ALLOW ALL. It is a default, but it should be removed. The only thing a security group show allow is specific outbound patterns, such as to the database host, or specificly permitted outbound ports. For example:
• Outbound TCP 5432 (Postgres), to address range 10.0.3.0/24 – it doesn’t need to make Postgres requests anywhere else
• Outbound TCP 443 (HTTPS), to address range 0.0.0.0/0 (everywhere?) – unless using a specific proxy
• Enable Guard Duty.
• Enable Route53 DNS firewall.
• Monitor your alert channels: if using SNS to an email destination, test the alert mechanism gets actioned. You may want to log the alert going off so you can see it in a dashboard.

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.

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.

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:

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.