docs: restructure Service Availability section

docs/layers/network/design-decisions/decide-on-primary-aws-region.mdx

@@ -9,13 +9,16 @@ tags:
 
 import Intro from "@site/src/components/Intro";
 import KeyPoints from "@site/src/components/KeyPoints";
+import Steps from "@site/src/components/Steps";
 
 While the company might operate in multiple regions, one region should be selected as the primary region. There are
 certain resources that will not be geographically distributed and these should be provisioned in this default region.
 
 When starting from scratch with a new AWS account, it's a good time to revisit decisions that might have been made
 decades ago. There are many new AWS regions that might be better suited for the business.
 
+## Considerations
+
 ### Customer Proximity
 
 One good option is picking a default region that is closest to the where the majority of end-users reside.
@@ -34,47 +37,53 @@ over `us-east-1` and the latencies between these regions is very minimal.
 
 ### High Availability / Availability Zones
 
-Not all AWS regions support the same number of availability zones.
-[Many regions only offer (2) availability zones](https://howto.lintel.in/list-of-aws-regions-and-availability-zones/)
-when a minimum of (3) is recommended when operating kubernetes to avoid "split-brain" problems.
+Not all AWS regions support the same number of availability zones. A minimum of 3 AZs is recommended when operating
+Kubernetes to avoid "split-brain" problems. Most AWS regions now have at least 3 AZs, but there are exceptions:
 
-### Cost
+- `us-west-1` (US West, N. California) — newer accounts only have access to 2 AZs
+- Some opt-in regions may have fewer AZs
 
-Not all regions cost the same to operate.
+See the [AWS Regions documentation](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html)
+for the current AZ count per region.
 
 ### Service Availability
 
-Not all regions offer the full suite of AWS services or receive new services at the same rate as others. Other times,
-certain regions receive platform infrastructure updates slower than others. Also, recently AWS launched
+Not all regions offer the full suite of AWS services or receive new services at the same rate as others. Some regions
+receive platform infrastructure updates slower than others. AWS also offers
 [Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#AWS_Local_Zones) (e.g.
 `us-west-2-lax-1a`) which operate a subset of AWS services.
 
 See [AWS Regional Services List](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) for
 a complete breakdown of service availability by region.
 
-### Reference Architecture Component Availability
+Several services used in the reference architecture are only available in a subset of AWS regions:
 
-Beyond standard AWS services, certain components in the reference architecture have their own regional constraints that
-should factor into your primary region decision.
+<Steps>
+  1. **[AWS App Runner](https://aws.amazon.com/apprunner/)** is only available in these regions:
+     `us-east-1`, `us-east-2`, `us-west-2`,
+     `eu-central-1`, `eu-west-1`, `eu-west-2`, `eu-west-3`,
+     `ap-south-1`, `ap-southeast-1`, `ap-southeast-2`, `ap-northeast-1`.
+     We use App Runner for [RunsOn](/layers/github-actions/runs-on/), our recommended solution for self-hosted GitHub runners.
 
-#### RunsOn (Self-Hosted GitHub Runners)
+  1. **[Amazon Managed Grafana](https://aws.amazon.com/grafana/)** is only available in these regions:
+     `us-east-1`, `us-east-2`, `us-west-2`,
+     `eu-central-1`, `eu-west-1`, `eu-west-2`,
+     `ap-northeast-1`, `ap-northeast-2`, `ap-southeast-1`, `ap-southeast-2`.
+     We use Managed Grafana for centralized monitoring dashboards in the
+     [Grafana monitoring stack](/layers/monitoring/).
+</Steps>
 
-[RunsOn](/layers/github-actions/runs-on/) is our recommended solution for self-hosted GitHub runners. It relies on
-[AWS App Runner](https://aws.amazon.com/apprunner/), which is only available in a subset of AWS regions:
+#### Deploying in Unsupported Regions
 
-- `us-east-1`, `us-east-2`, `us-west-2`
-- `eu-central-1`, `eu-west-1`, `eu-west-2`, `eu-west-3`
-- `ap-south-1`, `ap-southeast-1`, `ap-southeast-2`, `ap-northeast-1`
+If your primary region doesn't support one of these services, you can still use that region by deploying the service
+in a supported region and connecting it back. Depending on the service, this may require connecting the alternate region
+via [Transit Gateway](/components/library/aws/tgw/hub/) with a cross-region peering connection, deploying cross-region
+IAM roles, or a combination of both. These workarounds add complexity and cost (e.g. Transit Gateway cross-region
+data transfer adds approximately **$80/month**).
 
-Notably, **`us-west-1` does not support App Runner**, and therefore RunsOn cannot be deployed there directly.
-
-If your primary region doesn't support App Runner but you still want to use that region, you'll need to deploy RunsOn
-in a supported region and connect it to your primary region. We recommend using Transit Gateway with a cross-region
-peering connection for this, though other connectivity options exist. This adds approximately **$80/month** in Transit
-Gateway cross-region data transfer costs.
+### Cost
 
-For most deployments, we recommend choosing a primary region that supports App Runner to avoid this additional
-complexity and cost.
+Not all regions cost the same to operate.
 
 ### Instance Types
 
@@ -85,7 +94,25 @@ Not all instance types are available in all regions
 Latency between v1 infrastructure and v2 infrastructure could be a factor. See
 [cloudping.co/grid](https://www.cloudping.co/grid) for more information.
 
-### References
+## Recommendation
+
+Taking all of the above into consideration, we recommend choosing a primary region that supports the services you need,
+has at least 3 availability zones, and is not `us-east-1` (due to its history of service interruptions). The regions
+that support both App Runner and Managed Grafana while meeting these criteria are:
+
+- `us-east-2` (US East, Ohio)
+- `us-west-2` (US West, Oregon)
+- `eu-central-1` (Europe, Frankfurt)
+- `eu-west-1` (Europe, Ireland)
+- `eu-west-2` (Europe, London)
+- `ap-southeast-1` (Asia Pacific, Singapore)
+- `ap-southeast-2` (Asia Pacific, Sydney)
+- `ap-northeast-1` (Asia Pacific, Tokyo)
+
+For US-based organizations, `us-east-2` and `us-west-2` are both solid choices. They avoid the stability concerns of
+`us-east-1`, offer low latency to other US regions, and support the full reference architecture without workarounds.
+
+## References
 
 - [https://www.geekwire.com/2017/analysis-rethinking-cloud-architecture-outage-amazon-web-services/](https://www.geekwire.com/2017/analysis-rethinking-cloud-architecture-outage-amazon-web-services/)
 - [https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/](https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/)