Category: Cloud

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.

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.

AWS Cloud Certifications in the Partner Community, 2024

I track the capability of the consulting services partners by a number of attributes. Here is what the top 9 look like, by count of AWS Certifications, for the last two years until November 2024:

A bit of a gap on Accenture data, but still interesting

It appears that Accenture is ín danger of losing its dominant position as the worlds largest AWS Cloud consulting services partner, perhaps sometime in the next three to six months; TCS is accelerating up from what was 6th position in 2022, currently in 2nd position.

It appears that DXC was lagging the others, but has now caught back up.

Now lets look at an aggregate total of the top 20 partners’ certifications, excluding Accenture (due to missing data), and see what the ecosystem growth is like:

This looks like there is continuing growth of the number of certs held, growing 57.3% over two years.

Looking at the AWS Partner Competencies achieved for those top 9 (by certifications held) :

Accenture continues to lead

I find it interesting to derive the focus and attention these organisations are placing on their AWS Cloud skills validation in their workforce.

For many of these, the long trail is the set of individuals who only hold the one certification, which often is the Cloud Practitioner – Foundational cert. This level of validation is aimed at being non-technical, often achieved by sales, marketing, and management folk who do not have the delivery capability to competently deploy a Lambda function or set a security group! However, its beyond my visibility to be able to remove this cert from the totals I can see. This means that the true delivery capability may be very different for these organisations.

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.

Australia to get Top Secret rated AWS Cloud Region

In 2013 I was presenting to representatives of the South Australian government on the benefits of AWS Cloud. Security was obviously a prime consideration, and my role as the (only) AWS Security Solution Architect for Australia and New Zealand meant that this was a long discussion.

Clearly the shared responsibility model for cloud was a key driver, and continues to be so.

But the question came up: “We’re government, we need our own Region“. At that time, the US had just made its first US GovCloud in August of 2011. I knew then that the cost for a private region then was around US$600M, before you spun up your first (billed) workload.

The best thing about public cloud is, with the safeguards in place around tenant isolation, there are a whole bunch of costs that get shared amongst all users. The more users, the less cost impact per individual. At scale, many things considered costly for one individual, become almost free.

Private AWS Regions are another story: there is not a huge client base to share these costs across. With a single tenant, that tenant pays 100% of the cost. But then that tenant can demand stricter controls, encryption and security protocols, etc.

This difference will perhaps be reflected in the individual unit costs (eg, per EC2 instance per hour, etc).

Numerous secret regions have been created since 2013, such as the Mercury Veil Project for the CIA’s secret AWS Cloud Region.

Today we have two more interesting private regions currently being commissioned: the previously announced European Sovereign Region, and today, the Australian Secret Region at an initial AUD$2B cost.

After 11 years, the cost of a private (dedicated) Region has seemingly increased 333%.

If you thought cloud skills were getting passe, then there’s a top secret world that’s about to take off.