Everything and the kitchen sink vpc #1
Conversation
This is an out of the box aws example that has way more than is necessary. It can be trimmed down to just what is relevant.
There was a problem hiding this comment.
So my overall concern here is that we're opting into inheriting and modifying a sub-DSL developed by someone else. I don't object to the sub-DSL per-se, I just have a desire for us to control it for our own purposes.
I'm starting to get the impression that Terraform still isn't advanced enough yet to offer the modularity we need/want from it to re-use across projects. I want it to be like node_modules. 🤔
On that point: It's not yet clear to me how this work gets into client projects with low friction. This obviously overlaps with your L&D so I for one don't need to have the answer yet-- I'm just interested in discovering it before we have to commit to a path.
| database_subnets = ["20.10.21.0/24", "20.10.22.0/24", "20.10.23.0/24"] | ||
| elasticache_subnets = ["20.10.31.0/24", "20.10.32.0/24", "20.10.33.0/24"] | ||
| redshift_subnets = ["20.10.41.0/24", "20.10.42.0/24", "20.10.43.0/24"] | ||
| intra_subnets = ["20.10.51.0/24", "20.10.52.0/24", "20.10.53.0/24"] |
There was a problem hiding this comment.
Curious about the choice of network here. 20.10.x.x is a publicly routable block. Choosing this as the internal network would shadow these public IPs, making them unreachable.
As a theoretical example: If I were to dig google.com and get the response 20.10.66.129 back, google.com would fail to load from any machine in this VPC. Now obviously this is probably NOT one of Google's addresses, but any services out there with public IPs in this range will be unreachable, leading to bizarre troubleshooting issues later.
To my knowledge, the only "safe" private IP blocks are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. So 192.168.x.x is okay, but somebody out there might already have 192.160.x.x and we might want our servers to be able to reach them.
Ref: https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses
|
|
||
| enable_dhcp_options = true | ||
| dhcp_options_domain_name = "service.consul" | ||
| dhcp_options_domain_name_servers = ["127.0.0.1", "10.10.0.2"] |
There was a problem hiding this comment.
I recognize much of this is boilerplate, so this is directed at the boilerplate and not you:
dhcp_options_domain_name_servers needs further attention, since 10.10.0.2 probably isn't going to answer DNS requests for our network. 😅
| Project = "Secret" | ||
| Endpoint = "true" | ||
| }) | ||
| } |
There was a problem hiding this comment.
If we're angling towards [redacted] specifically, then I'm seconding that just about everything can come out of vpc_endpoints here. ecs is probably the only keeper? Maybe ecr_api?
This is an out of the box aws example that has way more than is
necessary. It can be trimmed down to just what is relevant.