AWS Rds security group settings consideration - amazon-web-services

We've setup a RDS for MS SQL database. I'd like to limit database connection only from our own applications such as Website, API, others. Normally we setup the security group like:
The problem is it allows anybody to access. I'd like to only allow some IPs to connect. But I can't do that for my API app which it's running through a Load balancer because there is no fixed ip address.
Any suggestions?

Don't use IP restrictions. When configuring Security Group rules, in the Source field you can also enter Security Group ID of the Instance that you want to allow to access your RDS.
Example from Adding Rules to a Security Group:

Related

AWS: How to allow all TCP traffic between all instances in same VPC?

I am setting up EMR clusters on demand, and have a windows EC2 server as a workstation, and a linux EC2 server as a secondary server. All in the same VPC. I would like to avoid having to set security group rules each time an instances comes up with a new IP.
How would I simply allow any traffic to flow freely between all servers in the same VPC?
Thanks!
EDIT- Thanks for the replies, I know this is not good practice in production, but we are dealing with some issues tracking down functionality which we believe is caused by ports, this is just a exploration phase, and this will help us. Thanks!
In the security groups, assign incoming access to other security groups by specifying a security group ID instead of IP addresses. In the web console, if you start typing "sg" in the source field it will pop up a list of your security groups to choose from. Using a security group ID as the source allows all resources that belong to that security group to have access.
Alternatively, if you just want one rule that allows access to every resource in your VPC you would specify your VPC's IP range.
to Allow any traffic between ALL servers in the VPC is not a good practice.
you should rethink in your VPC purpose.
Any way, if you want a group of servers to communicate with each other you can create a Security Group
And Assign it for all servers that you want.
and in inbound rules you add one rule from type "All TCP" and the source of this rule will be the same Security Group.
if your Security Group ID is 'sg-xxxxxxxx'
then the rule will be like this:
All TPC | TCP | 0-65535 | custom | sg-xxxxxxxx
To add to the other answers here, if you really want this, you can set it up via the Subnet or VPC IP CIDR Block
For example, if your VPC is 10.0.0.0/16, then add that to your security groups and all VPC traffic should be able to flow to each other.

Cannot access Amazon RDS instance

I have created a free-tier PostgreSQL RDS instance and everything appears to looks good on the portal. However, I am unable to get to the instance.
Going through the troubleshooting steps, they mention it could a firewall issue on my end. However, a quick ping from an external site reveals the same timeout issue.
Is there a step that I've missed?
Ping is typically disabled in AWS Security Groups. It is not recommended as a method of checking network connections.
The best method would be to use an SQL client to connect to the database via JDBC or ODBC.
Things to check:
Your RDS instance was launched as Publicly Accessible
Your RDS instance was launched in a Public Subnet (Definition: The subnet's Route Table points to an Internet Gateway)
The Security Group permits connections on the database port (this is also where you could permit PING access, but no guarantee that it would work with an RDS instance)
Check the associated Security Groups that you have tagged. Security groups hold the firewall rules. Either you may have to tweak the group that you have selected or try changing / modifying the group that you (or your profile) have access to.

AWS security group for inbound traffic

I have two AWS Linux AMI servers.
One with a Node.JS HTTPS server and the second running my Mongo DB.
The only way to connect to my Mongo DB server is through my Node.JS server.
In my in the AWS security group for the Mongo DB server I was able to put the name of the the AWS security group for the Node.JS server in the 'Source' column in the 'Inbound' tab and it allowed connectivity, but I'm wondering what setting the security group actually does?
More specifically, what IP addresses is this allowing?
If you click the 'i' next to Source it states:
I initially resorted to using the "private IP address" for communication between AWS instances because according to AWS documentation,
A private IP address is an IP address that's not reachable over the
Internet. You can use private IP addresses for communication between
instances in the same network (EC2-Classic or a VPC).
But after some discussion (see comments below) it seems the better solution may be to utilize AWS Security Groups. My initially hesitation in using AWS security groups was unfounded.
My fear was that if I added the same security group assigned to my Node.js server to the 'Source' for the inbound traffic tab of my MongoDB server, then my MongoDB server would inherit the same inbound traffic rules (all traffic).
The aforementioned fear is unfounded because setting the inbound source to a security group does NOT inherit the rules, but rather simply allows inbound traffic from any instance that has been assigned to that security group.

Organizing Security Groups in AWS

I'm having an issue with Security Groups in AWS. I have 4 security groups, 2 in EC2 and 2 in RDS.
ec2-prod
ec2-test
rds-prod
rds-test
On the other hand, I have a database DEV, having the rds-test security group associated.
In the rds-test inbound rules I've added ec2-prod and ec2-test, and my IP is added into the ec2-test, but for some reason it's not working.
If I add my IP directly on rds-test I can connect to the database, but this behavior make no sense to me.
Just in case, in the ec2-test security group, my IP has permission ALL TCP.
Any ideas?
It's the normal behavior. You have to add your IP to the DB security group.
The DB security group defines the access the RDS DB.
The EC2 security group defines the access the EC2 instance.
The fact that your IP is authorized to access the instance doesn't mean your IP is authorized to access the DB (but you can connect to the DB from the instance).

AWS - Configuring access to EC2 instance from Beanstalk App

So for reasons Id rather not go into, my DB is on an EC2 instance in eu-west-1 and I have created a beanstalk app on us-east-1. Id like my app to talk to that EC2 instance on a MySQL port (3306).
Can anyone assist with how Id set this up, what ingress rules I need to setup on the EC2 security group? Given that I will have multiple versions of the app in beanstalk, the IP address may change regularly (after environment rebuilds etc).
The important concept regarding Security Group Rules you might be missing is, that you do not necessarily specify IP addresses as traffic sources alone, rather regularly will refer to other security groups as well:
The source can be an individual IP address (203.0.113.1), a range of
addresses (e.g., 203.0.113.0/24), or an EC2 security group. The
security group can be another group in your AWS account, a group in
another AWS account, or the security group itself.
By specifying a security group as the source, you allow incoming
traffic from all instances that belong to the source security group.
[...] You might specify another security group in your account if you're creating a
three-tier web service (see Creating a Three-Tier Web Service).
[emphasis mine]
Consequently you'll simply need to add the Beanstalk app instances security group as a traffic source for TCP port 3306 within the MySQL instance security group.
Taking this further
An additional concept to make oneself familiar with is, that you can have multiple security groups assigned to an instance, thus enabling (possibly dynamic) composition of the resulting firewall.
For example, a recommended practice for larger architectures suggests to specify a dedicated security group per 'role' your instances have (rather than accumulating several rules within one security group as usual), e.g. we have security groups like 'role-ssh' (TCP port 22) and 'role-mysql' (TCP port 3306), which are assigned to EC2 instances as needed in turn. You can read more about this concept in e.g. Security Groups - Most Underappreciated Feature of Amazon EC2.