Hi Yevgeniy,

Thanks for your comments!

1. You can use .tfvars files, or a configuration registry like Consul.
2. For small, simple environments a single state file makes sense. As it gets more complicated, splitting it up makes sense. This is what my “infrastructure as microservices” talk is about — how to split it up. Conway’s Law is relevant — if you have multiple teams, consider splitting it accordingly, so each team can handle changes to their parts without too much coordination. There are patterns for pipeline design and testing that can help with dependencies, e.g. Consumer Driven Contract (CDC) testing.
3. Blue green for the entire environment is probably too heavyweight. But if you do split it into different stacks, it becomes more tractable. This is another factor in deciding how to split it, and how small the pieces should be. I’ve seen teams do fairly large chunks with blue/green — multiple VPC’s which each contain a related group of services, for example. Managing state is of course an issue, you have to work out the best approach. I tend to split out stateful things, and work out an appropriate approach. Sometimes you can clone data (e.g. EBS volumes) to the new instance, sometimes the applications can handle it (e.g. adding nodes to an existing cluster in the new instance and allowing the data to replicate). Best of all is to keep the state in RDS and let Amazon worry about it for you!