One of the possible issues exacerbating #177 and #178 is the fact that our Django application containers in ECS are connecting to the public IP address of the database server. This implies that we're still routing that App-to-DB traffic via the Internet (public routing) rather than over an AWS-direct-connection (private routing).
This has been performant enough for prototyping, and doesn't often get in the way of functional behaviours.
However, there are at least a couple of risks that this exposes us to:
Latency may become an issue as the apps become more sophisticated - sensitivity to API-to-DB network connectivity can be a problem.
NAT Gateway may be one of our hidden billing costs.
Issues like the "long lived idle connections" may be a direct result of the NAT Gateway MITM'ing the connections and creating further complexity.
One of the possible issues exacerbating #177 and #178 is the fact that our Django application containers in ECS are connecting to the public IP address of the database server. This implies that we're still routing that App-to-DB traffic via the Internet (public routing) rather than over an AWS-direct-connection (private routing).
This has been performant enough for prototyping, and doesn't often get in the way of functional behaviours.
However, there are at least a couple of risks that this exposes us to: