diff --git a/website/content/docs/ecs/architecture.mdx b/website/content/docs/ecs/architecture.mdx
index e3d9dcb345..b6e262832e 100644
--- a/website/content/docs/ecs/architecture.mdx
+++ b/website/content/docs/ecs/architecture.mdx
@@ -31,12 +31,17 @@ at startup and sets up initial configuration for Consul and Envoy.
This diagram shows the timeline of a task starting up and all its containers:
-
+
- **T0:** ECS starts the task. The `consul-client` and `mesh-init` containers start:
- `consul-client` uses the `retry-join` option to join the Consul cluster
- - `mesh-init` registers the service for this task and its sidecar proxy into Consul. It runs `consul connect envoy -bootstrap` to generate Envoy’s bootstrap JSON file and write it to a shared volume. After registration and bootstrapping, `mesh-init` exits.
-- **T1:** The `sidecar-proxy` container starts. It runs Envoy by executing `envoy -c `.
+ - `mesh-init` registers the service for the current task and its sidecar proxy with
+ Consul. It runs `consul connect envoy -bootstrap` to generate Envoy’s
+ bootstrap JSON file and write it to a shared volume. `mesh-init` exits after completing these operations.
+
+- **T1:** The following containers start:
+ - The `sidecar-proxy` container starts and runs Envoy by executing `envoy -c `.
+ - If applicable, the `health-sync` container syncs health checks from ECS to Consul (see [ECS Health Check Syncing](#ecs-health-check-syncing)).
- **T2:** The `sidecar-proxy` container is marked as healthy by ECS. It uses a health check that detects if its public listener port is open. At this time, your application containers are started since all Consul machinery is ready to service requests. The only running containers are `consul-client`, `sidecar-proxy`, and your application container(s).
### Task Shutdown
@@ -77,3 +82,15 @@ token does not yet exist.
The ACL controller stores all ACL tokens in AWS Secrets Manager, and tasks are configured to pull these
tokens from AWS Secrets Manager when they start.
+
+### ECS Health Check Syncing
+
+If the following conditions apply, ECS health checks automatically sync with Consul health checks for all application containers:
+
+* marked as `essential`
+* have ECS `healthChecks`
+* are not configured with native Consul health checks
+
+The `mesh-init` container creates a TTL health check for
+every container that fits these criteria and the `health-sync` container ensures
+that the ECS and Consul health checks remain in sync.
diff --git a/website/public/img/ecs-task-startup.png b/website/public/img/ecs-task-startup.png
deleted file mode 100644
index 6b9e587b2c..0000000000
Binary files a/website/public/img/ecs-task-startup.png and /dev/null differ
diff --git a/website/public/img/ecs-task-startup.svg b/website/public/img/ecs-task-startup.svg
new file mode 100644
index 0000000000..5d79473d87
--- /dev/null
+++ b/website/public/img/ecs-task-startup.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
- **T0:** ECS starts the task. The `consul-client` and `mesh-init` containers start:
- `consul-client` uses the `retry-join` option to join the Consul cluster
- - `mesh-init` registers the service for this task and its sidecar proxy into Consul. It runs `consul connect envoy -bootstrap` to generate Envoy’s bootstrap JSON file and write it to a shared volume. After registration and bootstrapping, `mesh-init` exits.
-- **T1:** The `sidecar-proxy` container starts. It runs Envoy by executing `envoy -c