I am chasing some general guidance for setting up my network and VPN peering.
Basically, I want to setup a connection from my office to aws, but am wondering what the best practice is for multiple aws accounts?
Should I setup the vpn peer from the office to just one account subnet, and then peer to the other account from that subnet or,
should I setup individual vpn peers to both/all accounts from the office
I am just chasing what is the normal best practice for network design in this case.
It's now possible to link multiple VPCs and your VPN connection with a Transit Gateway.
so you can use your vpn to connect to the TGW then connect to any VPC-A or VPC-B.
https://aws.amazon.com/transit-gateway/
You can enable VPC Peering between accounts and their respective VPCs, but VPC Peering is not transitive, meaning that they will not forward packets. This means that if you use a VPN to connect to VPC-A and VPC-A is peering with VPC-B, your VPN traffic will NOT be forwarded to VPC-B thru VPC-A. So this eliminates VPC Peering as an option.
The best solution is to create a site-to-site VPN from your office to each account/VPC that you need connectivity with. I recommend that you look into a software solution such as OpenSwan or Windows Server Routing and Remote Access if you need company wide routing. AWS also lists a number of hardware routers that work very well. If just individuals need access then a good choice is OpenVPN (Desktop to AWS).
Keep in mind that there will be costs to enable site-to-site routing. You will either need AWS VGW or an EC2 instance running VPN software. This means a per hour cost 24 hours per day. VGW is $.05 per hour (for most regions). EC2 instance is around another $.05 per hour for a small instance. VGW is the better choice but then you are limited on what types of hardware / software that supports connections to VGW and its setup complexity. However, VGW allows you to use one VPN connection to route to multiple VPCs.
For more complex configurations / very high bandwidth, AWS and Cisco have partnered on the Cisco CSR. This is a high end solution with a high end cost. There is also Direct Connect for the best solution of all.
Your final choice will be determined by cost, software versus hardware solution, site-to-site or client-to-site, permanent always on routing or connect when required routing.
Related
I am trying to connect to an RDS Instance from my local machine through a VPC Peering connection. In my AWS Account I have two VPCs: VPC1 is connected to my local network via DirectConnect, VPC2 isn't. VPC2 contains all of my infrastructure and the idea is that if I want to connect to that infrastructure from my local machine I need to work through VPC1.
I have configured a route in the peering connection to forward IP based requests to VPC2 for a given address range. This doesn't really help me for RDS though because I don't know what the IP Address for RDS is, only the endpoint. I am guessing that there is some combination of DNS/Routing/Networking/Peering that will solve this problem but I haven't found any documentation that describes how to solve this issue.
Has anyone solved this issue before, or know of any documentation that describes what needs to be done?
Update:
The exact problem is that I can't connect to the RDS instance from my local machine. For example, if I use the RDS Endpoint as the server for my connection, the Sql Client I am using simply can't connect with a timeout error. My suspicion is that traffic is not being routed to VPC2 correctly but I don't know how to prove that.
As far as DNS goes, I am not sure how OnPrem is setup however I have 4 hosted zones in Route53 with a variety of URLs. Items that I setup in Route53 I am able to resolve by host name on my local.
Likewise, I am not sure how the network has been configured with DirectConnect (full VPN tunnel or otherwise).
As far as DNS and the network connections between AWS go though, that stuff works. I am able to resolve pieces of infrastructure in VPC1 fine I just (seemingly) can't get traffic to move across the Peering Connection in the way that I would expect.
I think the problem is that you think you can access vpc2 resources from on-prem just b/c you have direct connect to vpc1. What vpc-peering is giving you is access from vpc1 to vpc2 via private ip addresses. In your case you want vpc1 to act like a router to just transit your request from on-prem to vpc2. It does not work that way.
What are your options:
You could have a host vpc1 access vpc2 (like a bastion host) and you could ssh into that one first.
If possible, you can create a vpn connection from on-prem to vpc2.
And there are more complex solutions via transit gateway.
The doc here talks about vpc-peering limitations, it will basically explain that transitive connections like you want won't work: https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html
AWS scenario documentation to reach db mentions option 1 here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.Scenarios.html
Sorry for the Japanese material.
I think VPC1 and VPC2 cannot communicate even if you configure routing. So as long as communication is impossible, configuring DNS will not accomplish the goal, I guess.
AWS Solutions Architect ブログ: VPC Peeringの使いどころとTips等々
VPC Peering provides peering, not routing between multiple VPCs, so if you are peering 3 or more VPCs or connecting to locations outside of AWS via VPN or DirectConnect, even if you set the Routing Table appropriately for each, there will be no IP layer routing to networks more than 2 hops away. Even if you configure the Routing Table appropriately, there will be no IP layer routing to networks more than 2 hops away. Workarounds such as using proxies or stepping stones are required as before.
Translated with www.DeepL.com/Translator (free version)
Could PrivateLink help you achieve your goal?
AWS-40_AWS_Summit_Online_2020_NET01.pdf
Along the example on page 42:
local network --> Direct Connect --> VPC Endpoint (in VPC1) --> NLB (in VPC2) --> RDS (in VPC2)
The way my set-up works is that I have a 'development', 'staging' and 'production' environment all sitting in separate VPCs and I want to create a client VPN endpoint to allow engineers access to the internals of all these environments (the database mostly).
However, I can't decide how to approach this issue, my first idea was to create a single VPC which peers into all the other VPCs. This would make building the resource in terraform easier as the VPN can be completely separated out.
My other option would be to just have the VPN connection to the development VPC for example and then from there the development VPC peers into the production & staging VPCs however I really don't like this approach
As Steve mentioned from the comment, if you want to centralize your networking setup, for example:
A single or multi AWS VPN S2S with many VPCs
A single or multi DX connection with many VPCs
A single AWS Client VPN to many VPCs
and more
The answer is AWS Transit Gateway. This service also helps you if you have your VPCs placing under different AWS accounts.
For your use-case, AWS has published a blog post with detailed architecture with use-cases for your reference.
https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-client-vpn-to-scale-your-work-from-home-capacity/
I looked for in the documentation in the official AWS page to find out what are the differences between Amazon Connect, Amazon Direct Connection, AWS Managed VPN and Amazon Connect . Each time I get the question with this 4 options i am not sure which one should i use. Could anyone give me advice how to easily distinguish how to recognise correct use of this services ?
Amazon Connect
This is very different to either of the other services, it is a service that operates as a Cloud based call centre replacing on-premise software solutions that would have done this in the past.
Amazon Managed VPN
A VPN (otherwise known a virtual private network) allows a connection to be established over the internet to your AWS VPC(s). AWS has 2 versions of this, a site-to-site VPN and a client VPN.
The site-to-site VPN offers a fixed VPN connection between your AWS VPC and an on-premise location. This will require a static IP to maintain the connection, with all traffic routed over the public internet via IPSec and IKE.
The client VPN is similar to the site-to-site but will allow the client connection from anywhere. Using OpenVPN software you establish the connection with AWS which is maintained for as long as the connection is alive. This again uses the internet for all communication.
Direct Connect
With Direct Connect you can maintain a dedicated connection between AWS and your on-premise. This means you will no longer be using the public internet to connect which improves the performance between your on-premise and AWS. It supports both connections to VPC and connections to the public services of AWS (those not in a VPC such as S3 and DynamoDB).
There are a range of network speeds to choose from upto 10GB, to establish this it has specific hardware requirements and will require the hardware to be hosted at a authorized site. Alternatively you can use a hosted connection from a partner who will provide this hardware for you.
I have an organization with multiple projects. I must have a service that all compute, serverless, gke assets can connect to from all projects through https. Preferably this would not traverse the internet and would stay inside our organization.
Is this only possible with a shared vpc?
There are 3 platform-native ways to connect VPCs:
Shared VPC
VPC Peering
Cloud VPN
Shared VPC is typically preferable for organizations that have central control over their networking. If you can't use Shared VPC, then your best bet for shared services is to settle for VPN tunnels.
You can use VPN tunnels between VPCs in different projects. Packets will hit the internet, but they will be secure.
I am looking to find a way to communicate between 2 VPCs in AWS without the use of VPN connections to and from a certain company (outside AWS) - so that the traffic does not pass through the company's gateway. Or, simply said, access an EC2 instance in a VPC from another VPC (both in AWS) without leaving the Amazon Network (not going out on the internet, not even encrypted).
Basically what I want to do is to have a VPC acting as a "proxy" (let's call it PROX) and one acting as a "target" (called TARG). Now I want to connect a company through VPC to the PROX and inside the PROX route the requests to the TARG. Is this achievable? I would go for a traditional public-private single VPC, but I was asked to look into the previously described "architecture".
Use two Linux machines as VPN GW, each in each VPC.
Configure IPsec VPN between them.
That's all you need
This is not possible. You have to use a VPN connection between the two VPCs. You can directly connect them though relatively easily using the pair of IPSec gateways though. This is the recommended method of cross-connecting VPC's across regions.