0

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?

Ermiya Eskandary
  • 15,323
  • 3
  • 31
  • 44
S. J.
  • 1,106
  • 1
  • 10
  • 23

1 Answers1

3

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).

Mark B
  • 183,023
  • 24
  • 297
  • 295
  • Thank you so much for your explanation. That makes much more sense! As for CloudTrail, it was not enabled. I assume, then, there's no other way to see if any changes to the Security Group were made? I'm absolutely at a loss as to why he could access MySQL from his home for the past 8 months, and not after I made my replica. – S. J. May 14 '16 at 04:58
  • @Luth I think someone must have modified the security groups at some point, if he was able to connect to the database remotely in the past. – Mark B May 14 '16 at 15:46
  • I tend to agree, but I checked with him, and he was able to connect a mere two hours before I made the replica. :-/ Though, as I indicated above, there's nothing in the Security Group policies that says he should have *ever* been allowed to access it remotely. It baffles me. – S. J. May 15 '16 at 19:45