Хотя вы всегда можете раскошеливаться с анзиблем вы обычно всегда лучше использовать модуль, если это возможно, поскольку он должен приносить с собой идемпотентность и лучший контроль потока и вывода.
Так что в этом случае вы должны использовать ec2_vpc_route_table
модуль выпущен в анзибле 2.
Простой пример может выглядеть примерно так:
- name: private route table
ec2_vpc_route_table:
vpc_id: "{{ vpc_a_id }}"
region: "{{ ec2_region }}"
tags:
Name: private
subnets:
- "{{ private_subnet_a.id }}"
- "{{ private_subnet_b.id }}"
- "{{ private_subnet_c.id }}"
routes:
- dest: 0.0.0.0/0
gateway_id: "{{ nat_instance }}"
- dest: "{{ vpc_b_cidr }}"
gateway_id: "{{ vpc_a_to_b_pcx_id }}"
register: private_route_table
Это создаст таблицу маршрутизации, связанную с 3 частных подсети и имеют 2 маршрута: один из них является пиринговым маршрутом VPC для VPC B для диапазона CIDR этого VPC, а другой - маршрутом по умолчанию, который отправляется в Интернет через экземпляр/шлюз NAT.
AWS автоматически добавляет маршруты, когда вы просматриваете VPC. Проверьте таблицы маршрутов. –
@KarenB Я уверен, что это не так. Это было бы потенциально безумным дефолтом, потому что вы могли бы только направлять одну подсеть в одну подсеть, а не весь VPC на весь VPC, так как они могли бы знать, что вы хотите сделать? – ydaetskcoR
@KarenB Нет, это не так. – PrashantB