Ansible is a tool for performing changes on an environment to configure it so that it looks as has been defined. As such, nearly everything it does is purely for the purpose of enacting said changes and there are very few modules that don't make changes other than for fact gathering to enable other modules to make changes.
As such, I would say that if you are using Ansible to control your estate then you should back it entirely. If someone makes a change outside of Ansible then having Ansible change it back should be a good thing. In the event of some out of hours emergency where someone needs to make a manual change then that person should have some mechanism to prevent Ansible from running until the change is fed back into the automation code (at my company we use Jenkins to drive all of our automation so they can simply disable the relevant job(s)).
If this isn't an option for you then you could always shell out and describe the group before your change and then have a task check if the ec2_group
module changed anything and if so output what the security group looked like before:
- hosts: localhost
connection: local
vars:
security_group_name: testing
tasks:
- name: describe ec2 security group before change
shell: "aws ec2 describe-security-groups --group-names {{ security_group_name }}"
register: before
changed_when: false
- name: create ec2 security group
ec2_group:
name: "{{ security_group_name }}"
description: "{{ security_group_name }}"
rules:
- proto: tcp
from_port: 22
to_port: 22
cidr_ip: 0.0.0.0/0
- proto: udp
from_port: 123
to_port: 123
cidr_ip: 10.0.0.0/8
rules_egress:
- proto: all
cidr_ip: 0.0.0.0/0
register: ec2_group
- name: security group changed
debug: var=before
when: ec2_group.changed
Another option might be to simply use CloudTrail to see what has been changed in your AWS account.