Write the connection in plain English
For a website, user access and administrative access have different purposes. I would write who connects, to which service and why. This gives each rule a clear reason rather than adding broad access just to make an error disappear.
Keep access narrow
Use appropriate source ranges or supported security-group references. Review inbound and outbound rules separately. Security groups are stateful; understand return traffic instead of treating the rule list as a stateless filter. Remove temporary lab access when the exercise ends.
Troubleshoot the service as well
A failed connection can come from routing, network ACLs or an application that is not listening. A more permissive security group will not start a stopped service. Check the path in order and keep only the rules your application requires.
Try it yourself
Describe access for a public web server and private database. Explain why visitors should not connect directly to the database port.
A common question
Can I add a deny rule to a security group?
Security groups use allow rules. Other network controls have different rule models and scopes.
References & video notes
Use the video to follow the topic with me. Console screens and older offers can change, so check the current AWS documentation before performing a lab.
Keep learning
- Public and private IP addresses in AWS
- Elastic IP addresses: when a stable public address helps
- Amazon VPC: draw your network before creating it