links: была важной частью сетевой конфигурации Docker первого поколения. Как только Docker представил серию команд docker network и Docker Compose настроил частную сеть по умолчанию, это стало намного менее важным, и на самом деле не было никакой причины использовать его вообще в современных Docker.
Compose имеет собственную опцию depends_on:. Если служба a depends_on: [b], то при запуске a (может быть, потому что вы явно docker-compose up a, или, может быть, просто как ограничение порядка), контейнер b гарантированно существует. Если b является базой данных или какой-либо другой службой, запуск которой занимает некоторое время, она не обязательно будет функциональной , но, например, b будет допустимым именем хоста из a. точка зрения.
В рамках одной задачи ECS один контейнер может dependsOn других. Это похоже на параметр Compose depends_on:, но имеет дополнительный параметр condition, который может поддерживать несколько различных жизненных циклов. Следует отметить, что один контейнер может ожидать, пока другой станет "condition": "HEALTHY", что означает, что в Docker Compose требуется, чтобы ожидающий контейнер самостоятельно проверял вручную (чаще всего с помощью вспомогательного скрипта, например wait-for-it.sh); он также может подождать, пока другой контейнер не наберет "condition": "COMPLETE", если один контейнер просто выполняет настройку для другого.
Если вы переносите файл Docker Compose в задачу ECS, я бы начал с попытки заменить links: с depends_on:, что не должно вызывать особых функциональных изменений; переводя это в ECS, семантика которого очень похожа на "dependsOn": [{"condition": "START"}].