Docker Compose now works natively with AWS ECS, so you could conceivably "scale" Docker Compose. Plus there's AWS's ecs-cli which can work, though IIRC you basically have to maintain two different configs, one for local development, one for remote.

And that's the general flaw in using Compose outside of local development. It's simply not designed as a general purpose (and thus large-scale) deployment orchestrator. If you get it working locally, you probably need a different setup for remote. That affects things like testing, which means it's not really the same in dev as in prod. And even if it were, Compose isn't persistent, meaning it's just a script to start jobs on some other thing.

Every time I've worked on a team that tried to do Compose in production (or even just for CI) it ended up a weird snowflake or with duplicate processes, and we replaced it with something more standard. My standard advice now is to model both production and local development to be as close as possible and then pick the simplest method to support that use case. In general this means going from "Compose on one host" to Swarm/Nomad/ECS on multiple hosts to K8s. And of course, try to make your CI use the same exact methods you use for dev and prod, so that using CI doesn't give you different results than in dev or prod.