consul/website/content/docs/release-notes/consul-ecs/v0_7_x.mdx

---
layout: docs
page_title: 0.7.x
description: >-
  Consul ECS release notes for version 0.7.x
---

# Consul ECS 0.7.x

## Release highlights

- **Consul Dataplane:** Consul on ECS 0.7.x adopts the [Dataplane architecture](/consul/docs/connect/dataplane) to simplify connecting your ECS workloads to Consul. Refer to the documentation to learn more about the updated [ECS components](/consul/docs/ecs/architecture) and how to [deploy Consul to ECS using the Terraform module](/consul/docs/ecs/deploy/terraform).

- **New `control-plane` command:** The new, unified `control-plane` command combines the capabilities for the deprecated `mesh-init` and `health-sync` commands. The `control-plane` command starts a long running process with the following responsibilities:
  - Automatically (re)discover and (re)connect to Consul servers using connection manager.
  - Make an ACL Login request to obtain an ACL token when using the Consul AWS IAM auth method.
  - Register the service and sidecar proxy with the central catalog on the Consul servers.
  - Write the configuration for Consul Dataplane to a file on a shared volume.
  - Sync ECS health check statuses for the ECS task into the central catalog on the Consul servers on a periodic basis.
  - Gracefully shutdown when an ECS task is stopped. Upon receiving a SIGTERM, mark synced health checks critical and wait for Consul Dataplane to stop. Then remove health checks, services, and perform an ACL Logout if necessary.

- **New `controller` command:** The new `controller` command replaces the `acl-controller` command with the following changes:
  - Remove all CLI flags. Configuration is read from the `ECS_CONFIG_JSON` environment variable.
  - Automatically (re)discover and (re)connect to Consul servers, similar to the `control-plane` command.
  - Because Consul client agents are no longer used, the controller no longer configures the "client" auth method, policy, role, and binding rule which previously enabled Consul client agents to login.
  - Register the ECS cluster as a synthetic node in the central catalog on the Consul servers. The synthetic node is used to register services running in the ECS cluster.
  - Ensure leftover tokens and services are removed for ECS tasks that have stopped.

- **Locality aware routing (Enterprise):** Consul on ECS 0.7.x supports [locality-aware routing](/consul/docs/connect/manage-traffic/route-to-local-upstreams). In your ECS task meta JSON, set the `AWS_REGION` container environment variable and `AvailabilityZone` attributes to set the locality parameters in Consul service and proxy registrations. Consul uses these parameters to perform locality aware routing in Consul Enterprise installations.

## Breaking changes

- The new Dataplane architecture comes with the following breaking changes to configuring Consul on ECS. Refer to the [Upgrade to Consul dataplane architecture](https://developer.hashicorp.com/consul/docs/ecs/upgrade-to-dataplanes) documentation for a step-by-step upgrade guide.
  - Consul client agents are no longer used.
  - Consul Dataplane must be run in place of Envoy in each ECS task. Consul Dataplane manages the Envoy process and proxies xDS requests from Envoy to Consul servers.
  - The `consul-ecs` binary now communicates with Consul servers using HTTP(S) and GRPC.
  - Services are registered directly with the central catalog on the Consul servers. Services in the same ECS cluster are registered to the same Consul node name.
- Replaced the `mesh-init` and `health-sync` commands with a unified `control-plane`.
- Replaced the `acl-controller` command with `controller`.
- Add the `go-discover` binary to the Consul ECS image to better support [cloud auto-join](/consul/docs/install/cloud-auto-join).
- Changes to `ECS_CONFIG_JSON` schema.
  - Remove the `consulHTTPAddr` and `consulCACertFile` fields.
  - Add the `consulLogin.datacenter` field.
  - Add the `controller` field to support configuring the new `controller` command.
  - Add the `consulServers` field to specify the Consul server location and protocol-specific settings.
  - The `consulServers.hosts` field is required. This specifies the Consul server location as an IP address, DNS name, or `exec=` string specifying a command that returns a list of IP addresses. To use cloud auto-join, use an `exec=` string to run the `discover` CLI. For example, the following string invokes the discover CLI with a cloud auto-join string: 
    
    ```log
    exec=discover -q addrs provider=aws region=us-west-2 tag_key=consul-server tag_value=true
    ```
    
    By default, Consul ECS and Consul Dataplane images include the `discover` CLI.
  - Add the `proxy.healthCheckPort` field which can be hit to determine Envoy's readiness.
  - Add the `proxy.upstreams.destinationPeer` field to enable the proxy to hit upstreams present in peer Consul clusters.
  - Add the `meshGateway.healthCheckPort` field which can be hit to determine Envoy's readiness.
  - Add the `proxy.localServiceAddress` field to configure Envoy to use a different address for the local service.
  - Remove the `service.checks` field. Consul agent health checks are no longer supported because Consul client agents are not used. Instead, set the healthSyncContainers field to have consul-ecs sync ECS health checks into Consul.

## Supported software versions

- Consul: 1.17.x

## Changelogs

The changelogs for this major release version and any maintenance versions are listed below.

-> **Note**: These links will take you to the changelogs on the GitHub website.

- [0.7.0](https://github.com/hashicorp/consul-ecs/releases/tag/v0.7.0)