Nicolas De loof

Fargate `exec` has eventually been implemented: https://aws.amazon.com/fr/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/

please run command with debug log level to help diagnose this error: `docker --debug compose up`

we indeed used tag where possible, but are blocked by https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/77

A possible approach to address this request would be to leverage network attribute [`internal`](https://github.com/compose-spec/compose-spec/blob/master/spec.md#internal), so ECS integration knows network is not designed for connectivity from the Internet. Would then need...

I tested a few scenarios: [x] using env only - context created with "From Environment" option, - export AWS_REGION=us-west-2 - docker compose up, => application is deployed in expected region...

I hardly can imagine how the compose file complexity can impact setting up the AWS go SDK....

Region _should_ be set: 1. by your ~/.aws/config file if you created a docker ecs context based on profiles 1. by AWS_REGION / AWS_DEFAULT_REGION, or region configured by AWS_PROFILE if...

`AWS_CONFIG_FILE` _should_ be considered by the aws-go-sdk. I wonder it has some subtle difference vs the aws CLI that could explain this behaviour. Unfortunately there's no debug mode that could...

Better than yet another custom extension, we could rely on https://github.com/compose-spec/compose-spec/blob/master/spec.md#domainname. > we could have multiple services using the same "published" port This would be a problem as one could...

> Using port other than 80/443 creates a network load balance > Using ports 80/443 creates an application load balancer This is by design. Use `x-aws-protocol: http` on to declare...