ピアリング後に別のVPCのEC2インスタンスからAWS RDSインスタンスに接続できないのはなぜですか
VPC AのEC2インスタンスでTableau Serverを実行しています。その間、別のVPC Bにpostgres RDSを作成しました。ここで、Tableau ServerとRDS間の接続を確立します。 RDS VPCのCIDRは172.31.0.0/16で、EC2 VPCのCIDRは10.0.0.0/16です。
別のVPCのEC2インスタンスによってアクセスされるVPCのDBインスタンス によると、VPC AとVPC Bの間にピアリングpcx-xyz123を作成しました。また、VPC用に次のルートテーブルも作成しました。
RDS VPC
Destination Target
172.31.0.0/16 local
10.0.0.0/16 pcx-xyz123
EC2 VPC
Destination Target
10.0.0.0/16 local
172.31.0.0/16 pcx-xyz123
両方のルートテーブルがメインです。ただし、それぞれに0のサブネットがあります（これが重要かどうかはわかりません）。
ただし、Tableau ServerからRDSに接続できません。
2つのインスタンスは同じアカウントで作成されます。どちらも米国東部（オハイオ）にリストされています。だから彼らは同じ地域にいると思います。さらに、両方ともus-east-2ホスト名に。私のPCから、psqlコマンドまたはpgAdminを使用してRDSに接続できます。
2つのインスタンスを接続できないのはなぜですか？
[〜＃〜] edit [〜＃〜]：Tableau Serverと同じVPCの同じサブネット内に別のEC2 Linuxインスタンスを作成しましたデバッグ目的でのみ。ピアリングとルートテーブルを同じ方法で構成し、サブネットをルートテーブルに関連付けました。ただし、EC2 LinuxインスタンスでRDSに接続できません。
VPCピアリングは、パブリックサブネットがインターネットゲートウェイに接続する方法とほぼ同じように機能します--ルートテーブルは、トラフィックがサブネットに出入りする方法を定義します。
VPCピアリングが機能するには：
- 招待して承諾ピアリング接続（完了）
- 他のVPCのIP範囲（完了）のピアリング接続を指す各VPCにルートテーブルを作成します
- 各サブネットを関連付けるルートテーブルをピアリングできるようにする
- または、既存のルートテーブルを編集して、ピアリングエントリを含めます
- RDSデータベースがパブリックで、データベースのパブリックDNSを使用して接続しようとしている場合は、DNS解決を許可するために ピアリング接続のDNS設定を編集 する必要があります。
ルーティングは次のように機能します。
- トラフィックがサブネットを離れると、ルートテーブルが参照され、トラフィックの送信先が決定されます
- 最も制限の厳しいもの（例：/ 24）が最初に評価され、最も制限の少ないもの（例：/ 0）まで評価されます。
- トラフィックは、適切なルートテーブルエントリに従ってルーティングされます。
つまり、すべてのサブネットを含める必要がなく、ピアリングするサブネットのsomeを構成できます。伝統的に、それはプライベートサブネットそのピアであり、おそらくのみプライベートサブネットです-しかし、それは完全にあなたの選択です。
それはロードマップ上の方向と考えて、どこに向かうべきかを交通に伝えます。
以下は、VPCピアリングを介してプライベートRDSにアクセスできるようにする手順です。
2つのVPCがあるとします。
- 本番VPC：10.0.1.0/24
- RDS VPC：10.0.2.0/24
ステップ1：2つのVPC間にVPCピアリング接続を作成します。次に、接続を確立する要求を受け入れます。次のような接続IDを取得します。pcx-e8e8e8e8
ステップ2：eachVPCでルートテーブルを構成する
- 本番VPC：このルートをRDS VPCに追加：10.0.2.0/24 —> pcx-e8e8e8e8
- RDS VPC：このルートを本番VPCに追加します：10.0.1.0/24 —> pcx-e8e8e8e8
ステップ3：このインバウンドルールを追加して、本番VPCのIP範囲を受け入れるようにRDSのセキュリティグループを構成する
- ポート（MS SQL：1433、MySQL：3306など）—ソースを許可：10.0.1.0/24
これで接続の準備ができました。
注：RDSに接続するときは、提供されたDNS名を使用して回復力を高める必要があります。 AWS VPC DNSは、この名前をRDSインスタンスのローカルIPアドレスに解決します。
上記のすべてを実行した後も、RDSインスタンスへの接続に問題がありました。初めて、まあ、これまで、私は実際にはRedditでSO（ここでは： https://www.reddit.com/r/aws/comments/ 8hx28w/rds_access_from_a_different_vpc/dyn616i / ）。
Tl; DrVPCをピアリングし、ルートテーブルを変更し、DBセキュリティグループを開いてソースVPC CIDRからの接続を許可している場合（基本的に、@ John Rotensteinの提案 https://stackoverflow.com/a/46331624/183062 ）、RDSインスタンスがパブリックとしてマークされていないことを確認してください。
VPCピアリングはすべて詳細に関係しています。これが機能するために実行しなければならなかったアイテムです。
ピアVPC 1からVPC 2へ（当然ですが、この手順を実行しなかったユーザー向けに含まれています）。 VPC 1からVPC 2へのピアリングを確立します。リクエストを受け入れます。リージョンが異なる場合は、VPC 2リージョンに切り替えて、ピアリクエストを受け入れます。
例：
VPC 1 CIDR = 10.0.0.0/16
VPC 2 CIDR = 172.16.0.0/16
VPC 1（RDSインスタンスのあるVPC）
1。 RDSインスタンスのルートテーブルサービスサブネット-VPC 2 CIDRブロック（172.16.0.0/16）とターゲットVPC 2ピアリング接続（リストから選択-pcx-#####）にルート宛先を追加します。
2。 RDSセキュリティグループ-VPC 2 CIDRブロック（172.16.0.0/16）であるソースIPを使用して、DBポートの受信ルールを追加します。したがって、DBポートには2つのインバウンドルールがあります。 1つはVPC 1（10.0.0.0/16）CIDRブロック用で、もう1つはVPC 2（172.16.0.0/16）用です。
3。プライベートルートテーブルのネットワークアクセスコントロールリスト-特定のポートのみを許可する場合は、DBポート、ソース= VPC 2 CIDRブロック（172.16.0.0/16）、および許可のルールを追加します。
VPC 2
1。 EC2インスタンスのルートテーブルサービスサブネット-VPC 1 CIDRブロック（10.0.0.0/16）とターゲットVPC 1ピアリング接続（リストから選択-pcx-#####）にルート宛先を追加します。
2。インスタンスセキュリティグループ-ソースIPがVPC 1 CIDRブロック（10.0.0.0/16）であるDBポートのインバウンドルールを追加します。
3。ルートテーブルのネットワークアクセスコントロールリスト-特定のポートのみを許可する場合は、DBポート、ソース= VPC 1 CIDRブロック（10.0.0.0/16）、および許可のルールを追加します。
それでよかったのですが、別の設定を見つけたら、このメッセージを更新します。
ほんの少しの歴史ですが、私たちは災害復旧のためにこれを行っていました。本番インスタンスとRDS MS SQL DBはus-east-1（VPC 1）にあり、ディザスターリカバリーウォームスタンバイインスタンスはus-west-2（VPC 2）にあります。ほとんどの場合米国からのトラフィックを取得しますが、スタンバイサイトを実際の本番コピー（スケーリンググループ）にしてから、ルート5レコードをレイテンシベースのルーティングに変更することを検討します。
質問はすでに回答されていますが、RDSのパブリックDNSに接続している場合は追加したいと思います（例：prod.upd9999upd.us-east-1.rds.amazonaws.com）次に、プライベートIPへのDNS解決を有効にする必要があります。これはAllowDnsResolutionFromRemoteVpcを通じて行われます。
例：Vpc EC2_PROD（172.0.0.0/16）からVpc RDS_PROD（30.0.0.0/16）
1）作成 ピアリング接続 EC2 VPC（Requester）からRDS VPC（Accepter）へ。作成済みのピアリング接続を右クリックし、[DNS設定の編集]を使用して、UIでAllowDnsResolutionFromRemoteVpcを必ず有効にしてください。または 次のコマンド
aws ec2 modify-vpc-peering-connection-options --vpc-peering-connection-id "pcx-04a511409bb08ef16" --requester-peering-connection-options '{"AllowDnsResolutionFromRemoteVpc":true}' --accepter-peering-connection-options '{"AllowDnsResolutionFromRemoteVpc":true}' --region us-east-1
最終的なピアリング接続は次のようになります。
aws ec2 describe-vpc-peering-connections --profile aws-work --region us-east-1
{
"VpcPeeringConnections": [
{
"Status": {
"Message": "Active",
"Code": "active"
},
"Tags": [
{
"Value": "ec2-to-rds-peering-connection",
"Key": "Name"
}
],
"AccepterVpcInfo": {
"PeeringOptions": {
"AllowEgressFromLocalVpcToRemoteClassicLink": false,
"AllowDnsResolutionFromRemoteVpc": true,
"AllowEgressFromLocalClassicLinkToRemoteVpc": false
},
"VpcId": "vpc-RDS",
"Region": "us-east-1",
"OwnerId": "?",
"CidrBlockSet": [
{
"CidrBlock": "30.0.0.0/16"
}
],
"CidrBlock": "30.0.0.0/16"
},
"VpcPeeringConnectionId": "pcx-04a511409bb08ef16",
"RequesterVpcInfo": {
"PeeringOptions": {
"AllowEgressFromLocalVpcToRemoteClassicLink": false,
"AllowDnsResolutionFromRemoteVpc": true,
"AllowEgressFromLocalClassicLinkToRemoteVpc": false
},
"VpcId": "vpc-ec2",
"Region": "us-east-1",
"OwnerId": "?",
"CidrBlockSet": [
{
"CidrBlock": "172.0.0.0/16"
}
],
"CidrBlock": "172.0.0.0/16"
}
}
]
}
2）リクエスターVPC（Ec2 VPC）ルートテーブルにはアクセプターIP cider（eg 30.0.0.0/16）が追加されました。 （下記のRoutesタブを参照）
aws ec2 describe-route-tables --filters Name=tag:Name,Values=EC2_PROD --profile aws-work --region us-east-1
{
"RouteTables": [
{
"Associations": [
{
"RouteTableAssociationId": "rtbassoc-?",
"Main": true,
"RouteTableId": "rtb-?"
}
],
"RouteTableId": "rtb-?",
"VpcId": "vpc-EC2_PROD",
"PropagatingVgws": [],
"Tags": [
{
"Value": "EC2_PROD",
"Key": "Name"
}
],
"Routes": [
{
"GatewayId": "local",
"DestinationCidrBlock": "172.0.0.0/16",
"State": "active",
"Origin": "CreateRouteTable"
},
{
"Origin": "CreateRoute",
"DestinationCidrBlock": "30.0.0.0/16", // Accepter IP cider block
"State": "active",
"VpcPeeringConnectionId": "pcx-04a511409bb08ef16"
},
{
"GatewayId": "igw-???",
"DestinationCidrBlock": "0.0.0.0/0",
"State": "active",
"Origin": "CreateRoute"
}
]
}
]
}
3）同様にAcceptor VPC（RDS VPC）ルートテーブルにはRequester IP cider（eg 172.0.0.0/16）が追加されました。 （下記のRoutesタブを参照）
aws ec2 describe-route-tables --filters Name=tag:Name,Values=RDS_PROD --profile aws-work --region us-east-1
{
"RouteTables": [
{
"Associations": [
{
"SubnetId": "subnet-?",
"RouteTableAssociationId": "rtbassoc-?",
"Main": false,
"RouteTableId": "rtb-?"
}
],
"RouteTableId": "rtb-?",
"VpcId": "vpc-RDS",
"PropagatingVgws": [],
"Tags": [
{
"Value": "RDS_PROD",
"Key": "Name"
}
],
"Routes": [
{
"Origin": "CreateRoute",
"DestinationCidrBlock": "172.0.0.0/16", // Requester IP cider block
"State": "active",
"VpcPeeringConnectionId": "pcx-04a511409bb08ef16"
},
{
"GatewayId": "local",
"DestinationCidrBlock": "30.0.0.0/16",
"State": "active",
"Origin": "CreateRouteTable"
},
{
"GatewayId": "igw-???",
"DestinationCidrBlock": "0.0.0.0/0",
"State": "active",
"Origin": "CreateRoute"
}
]
}
]
}
4）最後にAccepter VPC（RDS）のファイアウォール/セキュリティグループを更新 mysqlの場合、ポート3306のEc2 VPCからの接続を許可します。
aws ec2 describe-security-groups --filters Name=tag:Name,Values=RDS_FIREWALL --profile aws-work --region us-east-1
{
"SecurityGroups": [
{
"IpPermissionsEgress": [
{
"IpProtocol": "-1",
"PrefixListIds": [],
"IpRanges": [
{
"CidrIp": "0.0.0.0/0"
}
],
"UserIdGroupPairs": [],
"Ipv6Ranges": []
}
],
"Description": "Dev",
"Tags": [
{
"Value": "RDS_FIREWALL",
"Key": "Name"
}
],
"IpPermissions": [
{
"PrefixListIds": [],
"FromPort": 3306,
"IpRanges": [
{
"Description": "EC2_VPC_IP_CIDER",
"CidrIp": "172.0.0.0/16"
}
],
"ToPort": 3306,
"IpProtocol": "tcp",
"UserIdGroupPairs": [],
"Ipv6Ranges": []
}
],
"GroupName": "RDS_FIREWALL",
"VpcId": "vpc-???",
"OwnerId": "???",
"GroupId": "sg-???"
}
]
}
私は同様の問題に直面しました、これは私がやったことです：
上記のスレッドで説明したように、VPCピアリングを作成しました。
RDSインスタンスのセキュリティグループで、ポート5432（Postgresポート）Securitygroupid/hostIP/VPC_CIDRを許可するルールを追加できます。
EC2インスタンスにログインして、psql（
Sudo yum install postgresql-server postgresql-contrib）、次のコマンドを実行します：# this will ask for the password and connect. psql --Host=xxxxxx.us-west-2.rds.amazonaws.com --port=5432 --username=xxxxx --password --dbname=xxxxx