Connecting to Aurora Serverless via intra-region VPC Peering
I have two AWS accounts, which I will call prod and dev.
prod has an Aurora Serverless cluster (not instance!), perfectly connectable within its own VPC in the prod account. To save time and money, I would like to use this cluster in dev (obviously with read-only permissions, etc) instead of spinning up a new cluster, mostly due to volume of data and the need for parity during development.
I have set up dev exactly the same as prod, minus the Aurora cluster and with a different CIDR block for the VPC. I have set up a VPC peering connection between the VPCs in dev and prod with DNS resolution on both VPCs and enabled in the peering connection. I have added this peering connection to the route tables for each VPC, with the affected subnets explicitly associated. I have added both CIDR and SGs (including the VPC default SG, as I read recommended on SO in a tangentially related answer) to all affected SGs (Aurora cluster SG, SG for Lambda that is calling out to Aurora, default SG for VPC in both accounts). I also added the CIDR blocks to the ACL explicitly.
I can't get any kind of connection whatsoever. Documentation on whether this is even possible leads me in a recursive loop of not-quite-useful information, though it does seem the intra-region peering should be possible. I am no network expert, so it's entirely possible I have just horribly misconfigured something along the way, but I can't find any guides or useful documentation for this particular situation.
Is this even possible? Is there a checklist somewhere of changes to be made to allow connections like this (outside of the severely lacking AWS docs on VPC peering)? Route tables, subnets, security groups, ACLs, VPC peering connections...it's a lot of pieces and I feel like at this point I have just missed something, despite having torn down/reconfigured this setup via several guides.
amazon-web-services amazon-rds amazon-vpc amazon-rds-aurora vpc
asked Nov 20 at 19:00
slaughtr
1009
add a comment |
I have two AWS accounts, which I will call prod and dev.
prod has an Aurora Serverless cluster (not instance!), perfectly connectable within its own VPC in the prod account. To save time and money, I would like to use this cluster in dev (obviously with read-only permissions, etc) instead of spinning up a new cluster, mostly due to volume of data and the need for parity during development.
I have set up dev exactly the same as prod, minus the Aurora cluster and with a different CIDR block for the VPC. I have set up a VPC peering connection between the VPCs in dev and prod with DNS resolution on both VPCs and enabled in the peering connection. I have added this peering connection to the route tables for each VPC, with the affected subnets explicitly associated. I have added both CIDR and SGs (including the VPC default SG, as I read recommended on SO in a tangentially related answer) to all affected SGs (Aurora cluster SG, SG for Lambda that is calling out to Aurora, default SG for VPC in both accounts). I also added the CIDR blocks to the ACL explicitly.
I can't get any kind of connection whatsoever. Documentation on whether this is even possible leads me in a recursive loop of not-quite-useful information, though it does seem the intra-region peering should be possible. I am no network expert, so it's entirely possible I have just horribly misconfigured something along the way, but I can't find any guides or useful documentation for this particular situation.
Is this even possible? Is there a checklist somewhere of changes to be made to allow connections like this (outside of the severely lacking AWS docs on VPC peering)? Route tables, subnets, security groups, ACLs, VPC peering connections...it's a lot of pieces and I feel like at this point I have just missed something, despite having torn down/reconfigured this setup via several guides.
amazon-web-services amazon-rds amazon-vpc amazon-rds-aurora vpc
asked Nov 20 at 19:00
slaughtr
1009
Aurora Serverless uses some hidden network magic to allow it to (among other things) accept connections when it isn't actually running, start up, and handle those connections. Reading between the lines, within a region across a VPC peering connection, this may only currently work when you are using an instance with a Nitro hypervisor -- like c5, m5, r5, and t3. Peering involves the hypervisors (it's not an actual gateway) so older instance types can't necessarily do everything newer ones can.
– Michael - sqlbot
Nov 21 at 5:12
@Michael-sqlbot excuse I'm not 100% sure I follow what you're suggesting, so excuse me if this is incredibly wrong: I will need to create an EC2 with Nitro (inprod?) that would effectively tunnel my connection through to the VPCE for Aurora? Currently I have a non-Nitro instance setup as a Bastion host that allows connections to the Aurora from outside via SSH tunneling without these issues, so I'm not 100% how or where the Nitro EC2 would work/allow those connections. Appreciate the help!
– slaughtr
Nov 21 at 5:35
If I'm right, the only instances in VPC B that can access Aurora Serverless in VPC A (via intra-region peering) would be Nitro instances. You could use any kind of machine as a proxy in the same VPC as Aurora or a Nitro-based machine as a proxy in the remote VPC. Simple test, fire up a t3 in the foreign VPC and see if it can access the serverless cluster.
– Michael - sqlbot
Nov 21 at 13:10
add a comment |
I have two AWS accounts, which I will call prod and dev.
prod has an Aurora Serverless cluster (not instance!), perfectly connectable within its own VPC in the prod account. To save time and money, I would like to use this cluster in dev (obviously with read-only permissions, etc) instead of spinning up a new cluster, mostly due to volume of data and the need for parity during development.
I have set up dev exactly the same as prod, minus the Aurora cluster and with a different CIDR block for the VPC. I have set up a VPC peering connection between the VPCs in dev and prod with DNS resolution on both VPCs and enabled in the peering connection. I have added this peering connection to the route tables for each VPC, with the affected subnets explicitly associated. I have added both CIDR and SGs (including the VPC default SG, as I read recommended on SO in a tangentially related answer) to all affected SGs (Aurora cluster SG, SG for Lambda that is calling out to Aurora, default SG for VPC in both accounts). I also added the CIDR blocks to the ACL explicitly.
I can't get any kind of connection whatsoever. Documentation on whether this is even possible leads me in a recursive loop of not-quite-useful information, though it does seem the intra-region peering should be possible. I am no network expert, so it's entirely possible I have just horribly misconfigured something along the way, but I can't find any guides or useful documentation for this particular situation.
Is this even possible? Is there a checklist somewhere of changes to be made to allow connections like this (outside of the severely lacking AWS docs on VPC peering)? Route tables, subnets, security groups, ACLs, VPC peering connections...it's a lot of pieces and I feel like at this point I have just missed something, despite having torn down/reconfigured this setup via several guides.
amazon-web-services amazon-rds amazon-vpc amazon-rds-aurora vpc
asked Nov 20 at 19:00
slaughtr
1009
I have two AWS accounts, which I will call prod and dev.
prod has an Aurora Serverless cluster (not instance!), perfectly connectable within its own VPC in the prod account. To save time and money, I would like to use this cluster in dev (obviously with read-only permissions, etc) instead of spinning up a new cluster, mostly due to volume of data and the need for parity during development.
I have set up dev exactly the same as prod, minus the Aurora cluster and with a different CIDR block for the VPC. I have set up a VPC peering connection between the VPCs in dev and prod with DNS resolution on both VPCs and enabled in the peering connection. I have added this peering connection to the route tables for each VPC, with the affected subnets explicitly associated. I have added both CIDR and SGs (including the VPC default SG, as I read recommended on SO in a tangentially related answer) to all affected SGs (Aurora cluster SG, SG for Lambda that is calling out to Aurora, default SG for VPC in both accounts). I also added the CIDR blocks to the ACL explicitly.
I can't get any kind of connection whatsoever. Documentation on whether this is even possible leads me in a recursive loop of not-quite-useful information, though it does seem the intra-region peering should be possible. I am no network expert, so it's entirely possible I have just horribly misconfigured something along the way, but I can't find any guides or useful documentation for this particular situation.
Is this even possible? Is there a checklist somewhere of changes to be made to allow connections like this (outside of the severely lacking AWS docs on VPC peering)? Route tables, subnets, security groups, ACLs, VPC peering connections...it's a lot of pieces and I feel like at this point I have just missed something, despite having torn down/reconfigured this setup via several guides.
amazon-web-services amazon-rds amazon-vpc amazon-rds-aurora vpc
amazon-web-services amazon-rds amazon-vpc amazon-rds-aurora vpc
asked Nov 20 at 19:00
slaughtr
1009
asked Nov 20 at 19:00
slaughtr
1009
edited Nov 20 at 19:11
asked Nov 20 at 19:00
slaughtr
1009
asked Nov 20 at 19:00
slaughtr
1009
asked Nov 20 at 19:00
slaughtr
1009
1009
Aurora Serverless uses some hidden network magic to allow it to (among other things) accept connections when it isn't actually running, start up, and handle those connections. Reading between the lines, within a region across a VPC peering connection, this may only currently work when you are using an instance with a Nitro hypervisor -- like c5, m5, r5, and t3. Peering involves the hypervisors (it's not an actual gateway) so older instance types can't necessarily do everything newer ones can.
– Michael - sqlbot
Nov 21 at 5:12
@Michael-sqlbot excuse I'm not 100% sure I follow what you're suggesting, so excuse me if this is incredibly wrong: I will need to create an EC2 with Nitro (inprod?) that would effectively tunnel my connection through to the VPCE for Aurora? Currently I have a non-Nitro instance setup as a Bastion host that allows connections to the Aurora from outside via SSH tunneling without these issues, so I'm not 100% how or where the Nitro EC2 would work/allow those connections. Appreciate the help!
– slaughtr
Nov 21 at 5:35
If I'm right, the only instances in VPC B that can access Aurora Serverless in VPC A (via intra-region peering) would be Nitro instances. You could use any kind of machine as a proxy in the same VPC as Aurora or a Nitro-based machine as a proxy in the remote VPC. Simple test, fire up a t3 in the foreign VPC and see if it can access the serverless cluster.
– Michael - sqlbot
Nov 21 at 13:10
add a comment |
Aurora Serverless uses some hidden network magic to allow it to (among other things) accept connections when it isn't actually running, start up, and handle those connections. Reading between the lines, within a region across a VPC peering connection, this may only currently work when you are using an instance with a Nitro hypervisor -- like c5, m5, r5, and t3. Peering involves the hypervisors (it's not an actual gateway) so older instance types can't necessarily do everything newer ones can.
– Michael - sqlbot
Nov 21 at 5:12
@Michael-sqlbot excuse I'm not 100% sure I follow what you're suggesting, so excuse me if this is incredibly wrong: I will need to create an EC2 with Nitro (inprod?) that would effectively tunnel my connection through to the VPCE for Aurora? Currently I have a non-Nitro instance setup as a Bastion host that allows connections to the Aurora from outside via SSH tunneling without these issues, so I'm not 100% how or where the Nitro EC2 would work/allow those connections. Appreciate the help!
– slaughtr
Nov 21 at 5:35
If I'm right, the only instances in VPC B that can access Aurora Serverless in VPC A (via intra-region peering) would be Nitro instances. You could use any kind of machine as a proxy in the same VPC as Aurora or a Nitro-based machine as a proxy in the remote VPC. Simple test, fire up a t3 in the foreign VPC and see if it can access the serverless cluster.
– Michael - sqlbot
Nov 21 at 13:10
Aurora Serverless uses some hidden network magic to allow it to (among other things) accept connections when it isn't actually running, start up, and handle those connections. Reading between the lines, within a region across a VPC peering connection, this may only currently work when you are using an instance with a Nitro hypervisor -- like c5, m5, r5, and t3. Peering involves the hypervisors (it's not an actual gateway) so older instance types can't necessarily do everything newer ones can.
– Michael - sqlbot
Nov 21 at 5:12
Aurora Serverless uses some hidden network magic to allow it to (among other things) accept connections when it isn't actually running, start up, and handle those connections. Reading between the lines, within a region across a VPC peering connection, this may only currently work when you are using an instance with a Nitro hypervisor -- like c5, m5, r5, and t3. Peering involves the hypervisors (it's not an actual gateway) so older instance types can't necessarily do everything newer ones can.
– Michael - sqlbot
Nov 21 at 5:12
@Michael-sqlbot excuse I'm not 100% sure I follow what you're suggesting, so excuse me if this is incredibly wrong: I will need to create an EC2 with Nitro (in
prod?) that would effectively tunnel my connection through to the VPCE for Aurora? Currently I have a non-Nitro instance setup as a Bastion host that allows connections to the Aurora from outside via SSH tunneling without these issues, so I'm not 100% how or where the Nitro EC2 would work/allow those connections. Appreciate the help!– slaughtr
Nov 21 at 5:35
@Michael-sqlbot excuse I'm not 100% sure I follow what you're suggesting, so excuse me if this is incredibly wrong: I will need to create an EC2 with Nitro (in
prod?) that would effectively tunnel my connection through to the VPCE for Aurora? Currently I have a non-Nitro instance setup as a Bastion host that allows connections to the Aurora from outside via SSH tunneling without these issues, so I'm not 100% how or where the Nitro EC2 would work/allow those connections. Appreciate the help!– slaughtr
Nov 21 at 5:35
If I'm right, the only instances in VPC B that can access Aurora Serverless in VPC A (via intra-region peering) would be Nitro instances. You could use any kind of machine as a proxy in the same VPC as Aurora or a Nitro-based machine as a proxy in the remote VPC. Simple test, fire up a t3 in the foreign VPC and see if it can access the serverless cluster.
– Michael - sqlbot
Nov 21 at 13:10
If I'm right, the only instances in VPC B that can access Aurora Serverless in VPC A (via intra-region peering) would be Nitro instances. You could use any kind of machine as a proxy in the same VPC as Aurora or a Nitro-based machine as a proxy in the remote VPC. Simple test, fire up a t3 in the foreign VPC and see if it can access the serverless cluster.
– Michael - sqlbot
Nov 21 at 13:10
add a comment |
1 Answer
1
active
oldest
votes
Amazon has answered this for me with the newly announced VPC sharing
answered Dec 6 at 3:48
slaughtr
1009
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399804%2fconnecting-to-aurora-serverless-via-intra-region-vpc-peering%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Amazon has answered this for me with the newly announced VPC sharing
answered Dec 6 at 3:48
slaughtr
1009
add a comment |
Amazon has answered this for me with the newly announced VPC sharing
answered Dec 6 at 3:48
slaughtr
1009
add a comment |
Amazon has answered this for me with the newly announced VPC sharing
answered Dec 6 at 3:48
slaughtr
1009
Amazon has answered this for me with the newly announced VPC sharing
answered Dec 6 at 3:48
slaughtr
1009
answered Dec 6 at 3:48
slaughtr
1009
answered Dec 6 at 3:48
slaughtr
1009
answered Dec 6 at 3:48
slaughtr
1009
1009
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399804%2fconnecting-to-aurora-serverless-via-intra-region-vpc-peering%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Aurora Serverless uses some hidden network magic to allow it to (among other things) accept connections when it isn't actually running, start up, and handle those connections. Reading between the lines, within a region across a VPC peering connection, this may only currently work when you are using an instance with a Nitro hypervisor -- like c5, m5, r5, and t3. Peering involves the hypervisors (it's not an actual gateway) so older instance types can't necessarily do everything newer ones can.
– Michael - sqlbot
Nov 21 at 5:12
@Michael-sqlbot excuse I'm not 100% sure I follow what you're suggesting, so excuse me if this is incredibly wrong: I will need to create an EC2 with Nitro (in
prod?) that would effectively tunnel my connection through to the VPCE for Aurora? Currently I have a non-Nitro instance setup as a Bastion host that allows connections to the Aurora from outside via SSH tunneling without these issues, so I'm not 100% how or where the Nitro EC2 would work/allow those connections. Appreciate the help!– slaughtr
Nov 21 at 5:35
If I'm right, the only instances in VPC B that can access Aurora Serverless in VPC A (via intra-region peering) would be Nitro instances. You could use any kind of machine as a proxy in the same VPC as Aurora or a Nitro-based machine as a proxy in the remote VPC. Simple test, fire up a t3 in the foreign VPC and see if it can access the serverless cluster.
– Michael - sqlbot
Nov 21 at 13:10