- Newest
- Most votes
- Most comments
Your EC2 and other points of ingress typically support multiple Security Groups. So it makes perfect sense that one traffic profile type would be just one single Security Group if their lifecycle is tightly connected to each other.
So for example you could have Security Group called "AllowTrustedSources" that contains your list of IP addresses you will allow, you should manage this with one Cloudformation stack and share it cross different apps if it makes sense for you. What I mean by this is how do you in general manage the Cloudformation stacks? Do you have one per App?
Other method you could use to centrally manage the allowed IP addresses is to use VPC Prefixlists and then refer to this prefix list in all your different Security Groups. This allows you to have Security Group per application, giving each apps Cloudformation stack independence from each other but still gives you control centrally on the addresses you allow to connect to your apps.
Also see Tushar_J's comment below on when to to use multiple security groups. I totally agree what they wrote. You should share Security Group only if the traffic profile you allow in them is completely common between the apps. Such as Internet to Apps allowing port 443 from certain IP addresses.
Instead of keeping just 1 flat security group I would recommend creating multiple groups - for example, if you have a 3 Tier architecture then create Web, App & DB security group, in DB SG you can allow (reference) only App SG, similarly in App SG you can allow/reference only Web SG. If you create just 1 SG there will be lot of unnecessary rules that are not really required for each of the functionality for which the SG is applied to.
Relevant content
- asked 3 years ago
- Accepted Answerasked a year ago
- Accepted Answerasked 6 months ago
- Accepted Answerasked 4 months ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago