Support interacting directly with the database from the bastion host EC2 instance without a tunnel #77
Description
The current approach used to do administrative connections and STAC operations in the database (if deployed in an isolated subnet) is to create a 'bastion host' (an ec2 instance) that lives in the same VPC as the database and is allowed to make connections to it, and create a tunnel from the user's local machine to that ec2 instance.
However, creating the tunnel is not a straightforward task at all, and even though we provide a good documentation for how to do it, it would be better to avoid that step. In addition to being complicated, one must make sure that her/his SSH public key is registered in the EC2 instance side. We have a 'user data' parameter for this in the bastion host construct, but I noticed that it doesn't work when updating a deployment. Overall, it's not easy.
The only reason we need this tunnel is make use of the local machine environment, in particular libraries to connect and interact with the database (e.g. on macos psql and then pypgstac for CLI-based record loading or STAC queries). If instead, we set up the ec2 instance environment so that it has all these tools, we could do away entirely with the tunnel, and, in the above mentioned case of a DB deployed in a private, isolated, subnet, a user willing to make administrative connections and interactions with the DB would just have one command to run :
aws ssm start-session --target $EC2_INSTANCE_ID
Once logged into the instance, the user can freely interact with the DB.