Can creating an AWS RDS Read Replica screw with the Original's Security settings?
<p>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.</p>

<p>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 <code>Error 60</code>.  He blames me, and he's probably right to do so.</p>

<p>So <strong>first</strong>, 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?</p>

<p>And <strong>second</strong>, when I look at the Security Group settings, I don't exactly understand how it works.  It's setup like this:</p>

<pre><code>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
</code></pre>

<p>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?</p>