# Using EC2 Dynamic Inventory **URL:** \ **Category:** Ansible Project\ **Created:** [November 24, 2015, 1:03pm UTC](https://forum.ansible.com/t/using-ec2-dynamic-inventory/19839 "2015-11-24T13:03:18Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Rob\_Wilkerson](https://avatars.discourse-cdn.com/v4/letter/r/c67d28/32.png) [@Rob\_Wilkerson](https://forum.ansible.com/u/Rob_Wilkerson)\ **Post date:** [November 24, 2015, 1:03pm UTC](https://forum.ansible.com/t/using-ec2-dynamic-inventory/19839/1 "2015-11-24T13:03:18Z")
I’m working on a system that can run one playbook to launch some number of EC2 instances for any number of purposes. For example, a development, it might lauch & provision 2 web servers and 1 search server. In production, it might be even more specific and launch 2 api servers, 2 dashboard servers, 1 general web server and 1 search server. It’s trying to be pretty flexible like that. When launched, the instances are tagged in various ways. For example: ManagedBy: Ansible Environment: dev|stg|prd Roles: web,api,dashboard,corp,search Now I need to write playbooks that execute against existing servers and I’d like to be able to run something like this: $ ansible-playbook -i development/ec2.py dosomething.yml --ask-vault-pass And then, in my playbook, identify my hosts based on tags. In the simplest case, set hosts: \. Is it possible to set the hosts value based on multiple tags? In a slightly different example, I may need to execute a set of roles/tasks only against a server whose role includes “api”. This would mean parsing the “Roles” tag that is a comma delimited list of the projects installed on a given instance. Am I asking dynamic inventory to do too much? Is this possible in this or any other reasonable way? Thanks. ---
**Author:** ![Ivan\_S\_Freitas](https://avatars.discourse-cdn.com/v4/letter/i/e99b99/32.png) [@Ivan\_S\_Freitas](https://forum.ansible.com/u/Ivan_S_Freitas)\ **Post date:** [November 24, 2015, 1:53pm UTC](https://forum.ansible.com/t/using-ec2-dynamic-inventory/19839/2 "2015-11-24T13:53:27Z")
> I'm working on a system that can run one playbook to launch some number of > EC2 instances for any number of purposes. For example, a development, it > might lauch & provision 2 web servers and 1 search server. In production, it > might be even more specific and launch 2 api servers, 2 dashboard servers, 1 > general web server and 1 search server. It's trying to be pretty flexible > like that. > > When launched, the instances are tagged in various ways. For example: > > ManagedBy: Ansible > Environment: dev|stg|prd > Roles: web,api,dashboard,corp,search > > Now I need to write playbooks that execute against existing servers and I'd > like to be able to run something like this: > > $ ansible-playbook -i development/ec2.py dosomething.yml --ask-vault-pass > > And then, in my playbook, identify my hosts based on tags. In the simplest > case, set hosts: \ Environment tag is "development"\>. Is it possible to set the hosts value > based on multiple tags? You can specify the intersection of groups with the syntax: - hosts:     - tag\_ManagedBy\_Ansible:&tag\_Environment\_development It is documented here: [http://docs.ansible.com/ansible/intro\_patterns.html](http://docs.ansible.com/ansible/intro_patterns.html) > In a slightly different example, I may need to execute a set of roles/tasks > only against a server whose role includes "api". This would mean parsing the > "Roles" tag that is a comma delimited list of the projects installed on a > given instance. As far as the ec2 dynamic inventory scripts works, the commas are replaced by underscores, e.g. tag\_Roles\_web\_api\_dashboard, accordingly with the order in which the terms appear in the tag's value. That will probably cause problems if you try this approach, since tag\_Roles\_web\_api and tag\_Roles\_api\_web will be different groups. The simpler solution would be breaking down the list into separate tags (you can't have multiple tags with the same name, AFAIK) such as tag\_RoleAPI\_yes, tag\_RoleWeb\_yes, etc. Mind the limit of number of tags, though.