Let's look at how to do it right, optimizing for both security and accessibility at the same time. This is a problem that I've had to solve everywhere that I've worked, so I imagine it's a problem others have had to face, too. If your employees happen respond to an outage from an airport or coffee shop, they might spend minutes (hours?) manually monkeying with VPC security groups before they can even get access to address the outage. If your employees are working from home (which, in this COVID-riddled year, they very likely are), you will either need your employees to maintain a VPN connection to your office, or you will need to maintain a whitelist of all of your employees' home IP addresses.
While that's true - locking down your resources this way is better than nothing - this strategy yields two pitfalls: Other people on the internet are blocked because of their IP addresses". You might argue "it's fine we lock down our VPC security groups so that only people from our office IP can access our EC2, RDS, or ElastiCache instances. But should you? Exposing databases and servers publicly yields a pretty obvious security issue: your sensitive data is directly accessible to anyone on the internet. You can expose SSH on your webservers and you can expose your AWS Relational Database Service (RDS) and Redis/ElastiCache servers to the internet for easy access.
#Aws bastion code
It's nice to be able to ssh to do some live code debugging, or psql -U my-user -h my-database-instance to assess the current state of your database. You want to get something - anything - out the door, and you therefore want to be able to write code and debug issues quickly.īecause of that, it's awfully tempting to spin up servers and databases in public subnets so that you can readily connect to them for debugging sessions. When you first develop infrastructure for a new project, you naturally optimize for rapid development. The Problem with Publicly Accessible AWS Resources