I have an RDS instance that my client insists I not touch. He said it'd be okay to create a copy, though, and use that for testing the new features, so I went ahead and created a Read Replica from the original, and when that was completed, I promoted the Read Replica to a standalone instance. I then created a new Security Group (that allows only my IP), and on the replicated instance (only, I've confirmed) changed to use that Security Group. My copy instance works fine.
My client decided to log into the original MySQL RDS instance (as he is want to do for some reason) and has complained to me that for the first time in 8 months, he can't access it. He can't connect with Error 60. He blames me, and he's probably right to do so.
So first, does anything in this process look like it could have screwed up the original RDS's Security Group, or the original Security Group's inbound-allowed settings?
And second, when I look at the Security Group settings, I don't exactly understand how it works. It's setup like this:
RDS uses Security Group sg-001 [real ids changed for readability]
sg-001: Inbound TCP 3306 Source: sg-002
sg-002: Inbound TCP 80 Source: sg-003
sg-003: Inbound TCP 80 Source: 0.0.0.0/0
Inbound TCP 443 Source: 0.0.0.0/0
So when I read that, it appears to me that the RDS (which uses sg-001) wouldn't be able to have any incoming traffic at all, but the webservice (that also runs on AWS) is still able to read and write to RDS. Can someone help me understand this better?
For your first question, the steps you describe shouldn't have caused any issues that would result in the sudden inability for your client to connect to his database. Does the AWS account have CloudTrail enabled? If so, you should be able to see every change that was made to the RDS instance in order to explain exactly what happened.
For your second question, here's what each of your security group rules means:
sg-001: Inbound TCP 3306 Source: sg-002
Servers in sg-001 allow incoming traffic on port 3306 from any server that is a member of sg-002.
sg-002: Inbound TCP 80 Source: sg-003
Servers in sg-002 allow incoming traffic on port 80 from any server in sg-003.
sg-003: Inbound TCP 80 Source: 0.0.0.0/0
Inbound TCP 443 Source: 0.0.0.0/0
Servers in sg033g allow incoming traffic on ports 80 and 443 from anywhere.
I assume sg-001 is your database, sg-002 is your web server(s), and sg-003 is your Elastic Load Balancer. In this case any computer on the internet can hit ports 80 and 443 on the ELB. The web server(s) only accept traffic originating from the load balancer (i.e. you can't load a page from the server directly, you have to go through the ELB), and the database only accepts connections from the web server(s).