Best Practices for Setting Up Security Groups in AWS

Don't stick with one security group for everything. Use separate security groups and allow traffic via security group references instead of opening everything up with 0.0.0.0/0. For instance, your ALB's security group should allow traffic on ports 80/443 from the internet, the EC2 group allows incoming app ports from the ALB, and the DB group allows traffic only from the EC2 group. It will be stateful, meaning return traffic will be handled automatically. This method works great in dev and prepares you for a proper production setup.

This is a classic 3-tier web application scenario. You might want to check out some standard patterns or resources for this kind of setup. A simple search will yield lots of infrastructure-as-code examples to get you started.

Think about how much maintenance you're willing to put in. You can create a database server security group that only accepts database traffic and another for client traffic. Just ensure the server group accepts requests from the client group only. This approach keeps things secure but does require extra setup.

For development, it's best to separate each component into its own security group. Keep your EC2, database, and load balancer in individual groups. Only the load balancer should be accessible from the internet. Then, configure the EC2 security group to only accept traffic from the load balancer's security group, and the database security group to accept traffic from the EC2 group's security group. This way, you're tightening your security while still allowing necessary communication.