Cloudformation is infrastructure management, not configuration management. Both Ansible and Cloudformation can be used for both in different ways, but usually you have your configuration management (such as docker containers) in one step of your pipeline and cloudformation templates as another. That way you can test your infrastructure (by deploying cloudformation templates and tearing them down) as well as your code without them being too dependant.

I have used ansible to manage large production deployments of AWS infrastructure and what I will say is that it is very good at doing it, but it requires a lot of work compared to using something like terraform or cloud formation. Its not hard to have one playbook to provision all your infrastructure and make sure its up and running it just takes a good amount of lookups and facts calls.

The only reason I advocate for doing it is if a team will have a small infrastructure complexity ( like a basic ELB -> ASG -> RDS/EC2/S3 ) and they don't want to bring in more complex tools. Using ansible means you can use one tool to manage both your AMI's for immutable infrastructure and the infrastructure its self ( and can easily script your continuous deployment ). Once you start to really get a complex footprint getting a dedicated tool for infrastructure makes a lot of sense.

My opinion is that just because you can interact with AWS APIs with Ansible it means that you should. I think it's good to use AWS interaction with Ansible for things like dynamic inventory and the orchestration of certain tasks (e.g. stop a group of instances, switch load balancer config between blue/green deployments, etc.). That said I don't think it's that much worse than Cloudformation because it suffers from the same lack of statelessness and idempotency that you need to engineer around.

> using something like ansible to manage AWS

You may use Ansible for top level orchestration, deploying CF stacks and providing CF parameters. Just leave all resource creation to CF itself.