[becauseiam]

Every time a new AWS region is made public, it continues to highlight the disparity in services availability across the regions, as well as making information about services available. Many regions are "discovered" because the ip-regions.json file is updated long before the press release, but it will be some weeks to months before key information needed to spin up infrastructure appears in documentation, for example things like the ELB hosted zone identifier, which at time of writing is not documented.

[jeffbarr]

> things like the ELB hosted zone identifier

If you file a ticket on the proper page, I am sure that my colleagues will fix it ASAP. Go to the page and click "Provide feedback."

[becauseiam]

To extend what I'm trying to say is that customers shouldn't have to do this and that updating of this data (which ideally should be in a machine readable format, much like ip-ranges.json) is just another step. I would like to hope that AWS already has playbooks for taking a region out of closed-beta and making it GA. If the listing of af-south-1 is already present on other sections of documentation this may already be the case.

I'll send the feedback through anyhow.

[xchaotic]

Show me that magic unicorn company that spins data centres like that with 0 documentation bugs and I’ll join you criticising them. As it stands with limited resources I am pretty impressed with the speed AWS keeps adding capacity around the world.

[reaperducer]

Provide a service, or don't. It's sad that we've been trained to think that screw-ups are normal and OK.

[marcinzm]

Screw-ups will happen no matter how much wishful thinking and effort is spent preventing them. If you assume perfection in things then you will be sorely disappointed by most everything.

[FigmentEngine]

limited?

[willglynn]

The AWS SDKs I've dissected contain the information needed to talk to each (service, region) tuple as machine-readable data. They seem to converge at boto:

https://github.com/boto/botocore/blob/master/botocore/data/e...

Updates somehow land automatically, e.g. this commit adding the new region a few hours ago:

https://github.com/boto/botocore/commit/f7dc4730ad34c6c3322d...

[becauseiam]

This is incredibly useful, thanks! Whist it has some region information and endpoints, boto's lacking other useful information - availability zone count, hosted zones IDs for services like S3, etc. This data publicly lives in a variety of tables across their documentation, and is painful to scrape.

[willglynn]

Absolutely a fair criticism.

As a followup, I've found that the Terraform AWS provider needs information that boto doesn't – specifically, it needs region-specific details which can only be found in the documentation. They have a checklist for what to do when a new region gets announced:

https://github.com/terraform-providers/terraform-provider-aw...

Volunteers gather this information and push commits like:

https://github.com/terraform-providers/terraform-provider-aw...

I too am disappointed that AWS doesn't publish this information in a convenient way. On the other hand, well… source code _is_ a machine readable data format, and Go ASTs aren't that scary:

https://zupzup.org/go-ast-traversal/

Terraform follows AWS changes better than CloudFormation, so tracking Terraform might be a reasonable solution. One could even build a process to automatically retrieve the Terraform AWS provider source code, extract the necessary identifiers, and update the relevant data file living in an internal repository. Don't ask me how I know :-/

[willglynn]

Terraform now has these identifiers:

https://github.com/terraform-providers/terraform-provider-aw...

Thanks to PatMyron at AWS, who apparently added this information to Terraform after seeing my mention above :-)