4 ms·

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 a

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 6y ago
> 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 6y ago
  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 6y ago
    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.
    - deleted 6y ago
      [deleted]
    - FigmentEngine 6y ago
      limited?
    - reaperducer 6y ago
      Provide a service, or don't. It's sad that we've been trained to think that screw-ups are normal and OK.
      - marcinzm 6y ago
        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.
willglynn 6y ago
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/endpoints.json 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/f7dc4730ad34c6c3322da7d43ba64452bb3ae0d8 https://github.com/boto/botocore/commit/f7dc4730ad34c6c3322d...
- becauseiam 6y ago
  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 6y ago
    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-aws/blob/master/.github/CONTRIBUTING.md#new-region https://github.com/terraform-providers/terraform-provider-aw... Volunteers gather this information and push commits like: https://github.com/terraform-providers/terraform-provider-aws/commit/7243aa22e930f790a44119a1003e0e2f246a7aeb 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/ 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 :-/

jeffbarr 6y ago

> 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 6y ago
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 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - FigmentEngine 6y ago
    limited?
  - reaperducer 6y ago
    Provide a service, or don't. It's sad that we've been trained to think that screw-ups are normal and OK.
    - marcinzm 6y ago
      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.

willglynn 6y ago

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/endpoints.json 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/f7dc4730ad34c6c3322da7d43ba64452bb3ae0d8 https://github.com/boto/botocore/commit/f7dc4730ad34c6c3322d...

becauseiam 6y ago
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 6y ago
  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-aws/blob/master/.github/CONTRIBUTING.md#new-region https://github.com/terraform-providers/terraform-provider-aw... Volunteers gather this information and push commits like: https://github.com/terraform-providers/terraform-provider-aws/commit/7243aa22e930f790a44119a1003e0e2f246a7aeb 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/ 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 :-/