Do you want to write the scripts/orchestration that launches your Docker container, or do you want Amazon to manage it for you? Will your application comfortably fit on a single EC2 instance, or are you going to need to coordinate it across multiple instances?
If your application fits on a single instance and you don’t mind using Docker Compose to launch it or you don’t mind writing your own shell scripts to deal with it, you don’t really need ECS. If you have a larger application, ECS is one option. I’d probably look hard at EKS or other Kubernetes-based options; they’re more powerful, more complicated, and much less tied to AWS.
ECS is just another way to launch Docker containers. Put differently, ECS is a way to use Amazon’s APIs to run docker run commands.
… Learn how Dockerfiles and docker build work. Don’t bind-mount your code on to a container; especially not in production; and especially not in a multi-host environment.
… Set up a continuous integration server. Jenkins is popular but also kind of clunky; there are about 7,326 cloud-hosted options too (CircleCI and TravisCI immediately come to mind). You should be testing your application and building a Docker image on every commit to your source control.
… Set up a working development environment outside Docker. Set up a working test environment there. Get all of your tests passing locally. Then build a Docker image, and run it locally. Then deploy it to your remote cluster.
… Remember that Docker is a layer on top of other tools you have available to you. Don’t expect Docker to do everything; don’t expect to do everything in Docker. If you’re good at, say, writing shell scripts, it will translate to better Dockerfiles. If coding is new to you, for the most part a Docker-based environment will have all of the same requirements as whatever other path you were considering, plus Docker.
… If you’re doing something very simple then Docker may or may not be the right answer. For an all-AWS solution you might consider a hosted database (RDS) with an automated REST API in front of it (API Gateway), and your front-end deployed as static files (served from S3).