Cross-link the deployment guide to the AWS guide and example configs

Author: magnetised

website/docs/sync/api/config.md

@@ -554,6 +554,8 @@ If provided must be one of `MEMORY` or `FAST_FILE`.
 
 Path to root folder for storing data on the filesystem.
 
+This must be persistent storage that survives restarts. See [Optimizing for disk](/docs/sync/guides/deployment#optimizing-for-disk) in the deployment guide for what to run it on.
+
 </EnvVarConfig>
 
 ## Telemetry

website/docs/sync/guides/deployment.md

@@ -129,19 +129,23 @@ You can deploy it anywhere you can run a container with a filesystem and exposed
 - [Fly.io](/docs/sync/integrations/fly)
 - [Render](/docs/sync/integrations/render)
 
+The [AWS guide](/docs/sync/integrations/aws#deploy-electric) goes into the most depth, covering how to choose an ECS launch type and storage backing. It comes with [example Terraform and Pulumi configurations](https://github.com/electric-sql/electric-aws) that provision the whole stack — database, sync service and load balancer.
+
 ### Docker container
 
 Images are deployed to Docker Hub at [electricsql/electric](https://hub.docker.com/r/electricsql/electric).
 
 ### Optimizing for disk
 
-Electric caches [Shape logs](/docs/sync/api/http#shape-log) and metadata on the filesystem. Your Electric host must provide a persistent filesystem. Ideally this should be large, fast and locally mounted, such as a NVMe SSD. If you're configuring a machine and you want to optimise it for Electric, the factors to optimise for, in order of important, are:
+Electric caches [Shape logs](/docs/sync/api/http#shape-log) and metadata on the filesystem. Your Electric host must provide a persistent filesystem. Ideally this should be large, fast and locally mounted, such as a NVMe SSD. If you're configuring a machine and you want to optimise it for Electric, the factors to optimise for, in order of importance, are:
 
 1. disk speed — low latency, high throughput reads and writes
 2. memory
 3. CPU
 
-For example, on AWS, [Storage Optimized](https://aws.amazon.com/ec2/instance-types/#Storage_Optimized) instances such as the `i3en.large`, or on Hetzner the [SX-line](https://www.hetzner.com/dedicated-rootserver/matrix-sx/) of dedicated servers would both be great choices.
+For example, on AWS, [storage optimized](https://aws.amazon.com/ec2/instance-types/#Storage_Optimized) instances such as the `i4i` family, or general purpose instances that ship local NVMe such as `m6id`, are both good choices. On Hetzner, the [SX-line](https://www.hetzner.com/dedicated-rootserver/matrix-sx/) of dedicated servers works well.
+
+For a worked example, see [ECS on EC2](/docs/sync/integrations/aws#ecs-on-ec2) in the AWS guide. It covers choosing between local NVMe and an attached EBS volume, and [preparing the disk on boot](/docs/sync/integrations/aws#bootstrapping-the-data-disk).
 
 ### Configuring storage
 

website/docs/sync/guides/upgrading.md

@@ -226,6 +226,8 @@ With `maxSurge: 1` and `maxUnavailable: 0`, Kubernetes will:
 
 This example uses EC2 launch type with a host bind mount for shared storage. Both old and new tasks share the same directory on the EC2 host.
 
+See [ECS on EC2](/docs/sync/integrations/aws#ecs-on-ec2) in the AWS guide for how to provision this. The [example configurations](https://github.com/electric-sql/electric-aws) run a single container instance per cluster, which satisfies the placement requirement below.
+
 > [!Warning] Same-host placement
 > ECS does not guarantee that the new task lands on the same host as the old one. To ensure both tasks share the same host volume, your ECS cluster must have exactly one EC2 instance matching your placement constraint, or use a custom instance attribute to pin tasks to a specific host.