0

クライアントが触れないように主張する RDS インスタンスがあります。ただし、コピーを作成して、それを使用して新機能をテストしても問題ないというので、オリジナルからリード レプリカを作成し、それが完了したら、リード レプリカをスタンドアロンに昇格させました。実例。次に、新しいセキュリティ グループ (自分の IP のみを許可する) を作成し、レプリケートされたインスタンス (確認済みのみ) で、そのセキュリティ グループを使用するように変更しました。私のコピー インスタンスは正常に動作します。

私のクライアントは、元の MySQL RDS インスタンスにログインすることを決定し (何らかの理由でログインしたいので)、8 か月ぶりにアクセスできないと私に訴えてきました。彼は と接続できませんError 60。彼は私を責めます、そして彼はおそらくそうするのが正しいです。

最初に、このプロセスで、元の RDS のセキュリティ グループまたは元のセキュリティ グループのインバウンド許可設定を台無しにした可能性があると思われるものはありますか?

2 つ目は、セキュリティ グループの設定を見ても、その仕組みがよくわかりません。次のように設定されています。

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

したがって、それを読んだとき、RDS (sg-001 を使用する) は着信トラフィックをまったく受信できないように見えますが、Web サービス (AWS で実行される) は引き続き読み取りと書き込みを行うことができます。 RDSに。誰かがこれをよりよく理解するのを手伝ってくれますか?

4

1 に答える 1

3

最初の質問については、説明した手順によって、クライアントが突然データベースに接続できなくなるような問題が発生することはありませんでした。AWS アカウントで CloudTrail が有効になっていますか? その場合、何が起こったのかを正確に説明するために、RDS インスタンスに加えられたすべての変更を確認できるはずです。

2 番目の質問については、各セキュリティ グループ ルールの意味は次のとおりです。

sg-001: Inbound TCP 3306 Source: sg-002

sg-001 のサーバーは、sg-002 のメンバーである任意のサーバーからのポート 3306 での受信トラフィックを許可します。

sg-002: Inbound TCP 80   Source: sg-003

sg-002 のサーバーは、sg-003 の任意のサーバーからのポート 80 での受信トラフィックを許可します。

sg-003: Inbound TCP 80   Source: 0.0.0.0/0
        Inbound TCP 443  Source: 0.0.0.0/0

sg033g のサーバーは、ポート 80 および 443 でどこからでも着信トラフィックを許可します。

sg-001 がデータベース、sg-002 が Web サーバー、sg-003 が Elastic Load Balancer であると仮定します。この場合、インターネット上の任意のコンピューターが ELB のポート 80 および 443 にアクセスできます。Web サーバーはロード バランサーからのトラフィックのみを受け入れ (つまり、サーバーからページを直接ロードすることはできず、ELB を経由する必要があります)、データベースは Web サーバーからの接続のみを受け入れます。 .

于 2016-05-14T01:20:45.557 に答える