Erro 503 e services com incoscistência no cluster ECS

Ola! o comportamento que você descreveu (services no ECS subindo e logo caindo, resultando em erro 503) normalmente está mais ligado à configuração das tasks/services do que à região da AWS em si.
O fato de seu usuário estar na us-east-2 e o cluster ser criado na us-east-1 não costuma gerar instabilidade, desde que todos os recursos que a sua aplicação depende (ECS cluster, ALB, target groups, VPC, subnets, security groups, etc.) estejam na mesma região.

Health check do Target Group/ALB

• O ECS registra suas tasks no Target Group do Load Balancer.
• Se o health check estiver configurado para uma rota incorreta (ex: / quando sua API responde em /health), o ALB marcará suas instâncias como UNHEALTHY → as tasks sobem e logo são descartadas → gera o 503.
  Ve no Target Group qual a rota e porta configuradas.

Port mapping incorreto

• Se sua aplicação Node.js expõe a porta 3000, mas na definição da task o containerPort ou o portMappings não estão corretos, o ALB não consegue chegar nela.

• Certifique-se de que:

  • O containerPort = porta que sua app realmente usa.
  • O hostPort = 0 (para ECS gerenciar dinamicamente) ou igual ao containerPort.

Problema de rede (VPC/Subnets/Security Groups)

• As tasks precisam estar em subnets com acesso à internet (caso precisem buscar algo externo).
• O security group do serviço precisa permitir tráfego do ALB na porta da aplicação.
• O security group do ALB precisa estar liberado para receber tráfego externo (porta 80/443).

Logs das tasks

• Vá no ECS → Cluster → Service → Tasks → selecione a task → Logs.
• Ali você verá se o container está caindo por erro de aplicação (ex.: não encontra variáveis de ambiente, falha de conexão em banco, etc.).

Se quiser, você pode me mostrar:

• O trecho da task definition (principalmente portMappings).
• Como está configurado o health check do Target Group.