1 Answer
- Newest
- Most votes
- Most comments
1
My advice is have NAT gateway(s) as it is managed service (vs EC2 instance you would be responsible of both capacity and keeping it up-to-date with patching etc). If the cost is the factor, you could consider using just a single NAT gateway instead one per AZ as it is now in the template. In theory this would lower the fault tolerance a bit, but would also cut your costs to 1/2 or (1/3 in case of 3 AZ deployment). To do this, remove NATGW2, NATGW3, ElasticIP2 and ElasticIP3, and then in AZ2 and AZ3 private route tables just point the default route to NATGW1.
Relevant content
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
There are also some rather strange tagging build into template. E.g. assigning StackId=${AWS::StackId} to many resources, but no all of them. Cloudformation assigns following tags by default to all resources; aws:cloudformation:logical-id aws:cloudformation:stack-id aws:cloudformation:stack-name So unless you must have "StackId" as key, this information is already available without explicitly stating it in templete. There are also some explicit dependencies that are not needed. E.g. when there is a routetable created it is assigned to VPC but there is also stated dependency to VPC. Cloudformation can figure out dependencies make you make references without explicitely stating them out. I thin these make the template look more complex than it needs to be.
Thanks for this! I've disabled one of the nat gateways and elastic IPs so I can still have 2 for some fault tolerance like you mentioned. I'll watch over the coming days to see how it affects the price. Thanks again!