Originally, we decided to independently map Availability Zones to codes in each AWS account. This ensures that resources are distributed across the Availability Zones for these Regions, even if most customers chose the first Availability Zone in the Region. For example, the us-east-1a for your AWS account might not be the same physical location as the us-east-1a for another AWS account. As AWS learned more about customer usage patterns, and as AWS evolved, we determined that it was not necessary to continue to independently map Availability Zones to codes. All Regions introduced after November 2012 use a uniform mapping of Availability Zones to codes.
I was still under the impression that AZ IDs were mapped differently per AWS Account but this hasn't been the case for AZs in regions introduced after November 2012. The documentation also provides a sample command to run to find your specific account mapping for in-use AZs, I taked on the --region parameter at the end to specify a different region than your default.
aws ec2 describe-availability-zones --query "AvailabilityZones[].{Name:ZoneName,ID:ZoneId}" --output table --region eu-west-1
While on the topic, this page in the documentation lists out every AZ ID in each region with some more other example describe-availability-zone commands. This is also where I encountered the definition of a "constrained AZ":
Read from linkAs Availability Zones grow over time, our ability to expand them can become constrained. If this happens, we might restrict you from creating zonal resources in a constrained Availability Zone, unless you already have resources in that Availability Zone. Eventually, we might also remove the constrained Availability Zone from the list of Availability Zones for new accounts. Therefore, your account might have a different number of available Availability Zones in a Region than another account does.