By using AWS re:Post, you agree to the Terms of Use
/AWS Direct Connect/

Questions tagged with AWS Direct Connect

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Encrypted VPN Connectivity from VMC on AWS SDDC to On-Premise DC

Dear Team, I have the following setup requirements between VMware on AWS SDDC and on-Premise DC. 1. Need an encrypted VPN Solution between SDDC and On-Premise DC. 2. Need an Encrypted VPN Solution between SideCar VPC and On-Premise DC. 3. We have direct connect setup between DC and AWS. 4. Protected firewall sitting behind the edge device in on-Premise DC , encrypted VPN setup on DX need two set of public. Firewall sitting behind edge devise VPN connectivity but that firewall could not configured with public ip. The last hop where the public ip could be configured is the edge devise on the customer site. As per my understanding, I can use the public VIF on direct connect to setup the encrypted VPN connection between the client edge devise and AWS router. But the problem statement in this case is 1. How to setup the encrypted VPN solution for both SDDC and sidecar VPC? Can we route the traffic from SDDC to VTGW to TGW(of the sidecar account) and then leverage public VIF to setup encrypted VPN from TGW to customer edge devise? 2. Do we need the DX gateway to setup the encrypted VPN connectivity? 3. Encrypted VPN on DX would need to set of public IPS. What if the customer firewall is not having the option to configure the public IP for encrypted VPN ? 4. Can I use the DX setup in one OU to create the public VIF for another account in separate OU. This is required because I am looking to create the encrypted VPN connection from two OUs to the DC. Please advise with your comments or if there is any reference architecture available with VMC/AWS. Many Thanks Rio
1
answers
0
votes
3
views
asked 3 days ago

How do we correctly link the DC Gateway into the VPC, is a VG required?

I'm struggling to get my head around a lot of the AWS information. We have a Direct Connection and it's half working. The DC Gateway has a virtual interface that links to my onsite hardware. Ping works. BGP works. The DC has no other associated gateways. I think what I'm supposed to do is create a Virtual Private gateway that links to a VPC. I can do this, and it sort of works, to the extent that the subnets that are in the VPC can be successfully advertised over the BGP session to my hardware. However, it doesn't actually work because I can't exchange traffic with IP addresses inside the VPC from my onsite hardware anyway. So what gives me pause here is when I try to create the Private gateway, the string appears: "A virtual private gateway is the router on the Amazon side of the VPN tunnel." but I don't want AWS to setup a VPN tunnel. Also that VPG wants an AS configured, which implies that it wants to do BGP peering into the VPC with some device that's talking BGP back to it, which doesn't seem right to me. So how and where do I configure the VPC side of the DC gateway? Where do I type in a static IP that will be the default gateway for my VPC's subnet, so that the instances can send packets to that IP which will arrive at the hardware end of my AWS DC? Also -- with no traditional console access to the "router" that forms the AWS side of the DC, how do we do packet captures and other debugging to find out where packets are being lost? Edited by: DC-Client on Sep 1, 2021 4:25 PM
1
answers
0
votes
11
views
asked 9 months ago

Business case for direct connect vs VPN

Hello, My customer is starting with AWS and is running a few workloads on our cloud already. They are looking at interconnecting their data centers with AWS and we presented the different options VPN vs Direct Connect. This is what we shared to compare both: VPN: - Over the Internet - Easy to install, set up in minutes - Bandwidth: 1 VPN tunnel = 1.25 Gbps - Encryption: Encrypted in transit - Cost: Charged per hour per VPN connection + data transfer (0.9€/GB) Direct connect: - Physical, dedicated connection (not using the internet) = consistent performance, reduced bandwidth costs - Some set-up time required –can be few days - Bandwidth: Direct Connect Connection = 50 Mbps–10Gbps - Encryption: Not encrypted in transit but can be combined with VPN to have encryption - Cost: Charged per port hour + data transfer (0.2€/GB) We also said that a VPN is good to start or when the cloud is only used for test and development but that a direct connect is better in case they want to migrate applications to the cloud, use split-tier architecture or want to use our cloud as disaster site for example. Data transfer costs are also lower with direct connect so in case they are transferring a lot of data, a direct connect might be cheaper. My questions are: - Is there a white paper or another document comparing direct connect vs vpn that I could share with the customer ? - Do we have a list of use cases requiring direct connect that my customer could use to justify a direct connect? - Do we have a business case for direct connect vs VPN? I mean can direct connect becomes cheaper than VPN if there is a lot of data transfer for example. Thanks for your help
1
answers
0
votes
3
views
asked 2 years ago

How can we shorten failover time DX and VPN?

A customer has decided to use DirectConnect(DX) and VPN. So if DX failed, they want to fail over to VPN. But it takes about 20~30 seconds. What configuration does it effect to this long fail over time? AWS VPN Configuration is below ``` config vpn ipsec phase1-interface edit "transit-KR.P***" set interface "Loopbk" set local-gw 182.###.###.### set keylife 28800 set proposal aes128-sha1 set dhgrp 2 set remote-gw 15.###.###.### set psksecret . set dpd-retryinterval 1 set dpd enable set comments "aws-transit-****" next edit "transit-KR.****" set interface "Loopbk" set local-gw 182.###.###.### set keylife 28800 set proposal aes128-sha1 set dhgrp 2 set remote-gw 52.###.###.### set psksecret x set dpd-retryinterval 1 set dpd enable set comments "aws-transit-***" next end config vpn ipsec phase2-interface edit "transit-KR.####" set phase1name "transit-KR.####" set proposal aes128-sha1 set dhgrp 2 set keylifeseconds 3600 next edit "transit-KR.****" set phase1name "transit-KR.****" set proposal aes128-sha1 set dhgrp 2 set keylifeseconds 3600 next end config system interface edit "transit-KR.####" set ip 169.###.###.### 255.255.255.255 set allowaccess ping set tcp-mss 1387 set remote-ip 169.###.###.### set description "aws-transit-****" next edit "transit-KR****" set ip 169.###.###.### 255.255.255.255 set allowaccess ping set tcp-mss 1387 set remote-ip 169.###.###.### set description "aws-transit-****" next end config router bgp config neighbor edit "169.###.###.###" set remote-as 64514 set route-map-in aws-transitgw set route-map-out non-transit next edit "169.###.###.###" set remote-as 64514 set route-map-in aws-transitgw set route-map-out non-transit next end end *****-FW-1 $ get router info bgp nei 169.###.###.### routes BGP table version is 6042, local router ID is 182.###.###.### Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 10.80.64.0/18 169.###.###.### 100 0 64514 e *> 10.80.120.0/24 169.###.###.### 100 0 64514 e Total number of prefixes 2 ``` DX bgp configuration is below ``` interface g3/7.30 description AWS_DX_vpc_test logging event subif-link-status no ip redirects encapsulation dot1Q 30 ip address 172.16.1.57 255.255.255.252 bfd interval 100 min_rx 100 multiplier 3 ip as-path access-list 92 permit ^64513$ ip prefix-list ***-OUT-IPLIST seq 10 permit 10.56.0.0/13 le 32 ip prefix-list ***-OUT-IPLIST seq 20 permit 10.64.0.0/13 le 32 ip prefix-list ***-OUT-IPLIST seq 30 permit 10.28.0.0/14 le 32 ip prefix-list ***-OUT-IPLIST seq 40 permit 172.16.128.0/23 le 32 ip prefix-list ***-IN-IPLIST seq 10 permit 10.80.0.0/12 le 32 route-map AWS-KR-IN permit 10 match ip address prefix-list ***-IN-IPLIST match as-path 92 set local-preference 100 set community 9710:1493 route-map ***-OUT permit 10 match ip address prefix-list ***-OUT-IPLIST match as-path 1 set community none router bgp 64710 neighbor 172.16.1.58 remote-as 64513 neighbor 172.16.1.58 password ********** neighbor 172.16.1.58 description AWS dx-transitgw test neighbor 172.16.1.58 soft-reconfiguration inbound neighbor 172.16.1.58 route-map ***-IN in neighbor 172.16.1.58 route-map ***-OUT out neighbor 172.16.1.58 fall-over bfd ``` VPN config is downloaded from AWS VPN Config.
1
answers
0
votes
4
views
asked 2 years ago

hosted public VIF data transfer egress billing scenario clarification

Hello Networking TFC I noticed this in the FAQ for Public VIFs For publicly addressable AWS resources (for example, Amazon S3 buckets, Classic EC2 instances, or EC2 traffic that goes through an internet gateway), if the outbound traffic is destined for public prefixes owned by the same AWS payer account and actively advertised to AWS through an AWS Direct Connect public virtual Interface, the Data Transfer Out (DTO) usage is metered toward the resource owner at AWS Direct Connect data transfer rate. However it leaves the customer wanting to understand some scenarios, is this the same for hosted public VIF, and what if accounts are not in the same AWS organizations (different payer ) Example Scenario - Account A has the DX connection, and its own public VIF - Account B (not in AWS organizations with account A) was given a hosted public VIF from account A - Account C unrelated to Account A or B Scenario billing questions – please just respond with yes or no on the billing items so we can help the customer predict billings. - Scenario 1 - Account B S3 bucket, data transfer out to account B DX on premises. - Account A S3 egress yes/no - Account A DX egress yes/no - Account B S3 egress yes/no - Account B DX egress yes/no - Scenario 2 - Account B S3 bucket, data transfer out to account A DX on premises. - Account A S3 egress yes/no - Account A DX egress yes/no - Account B S3 egress yes/no - Account B DX egress yes/no - Scenario 3 - Account A S3 bucket, data transfer out to account B DX on premises. - Account A S3 egress yes/no - Account A DX egress yes/no - Account B S3 egress yes/no - Account B DX egress yes/no - Scenario 4 - Account C S3 bucket, data transfer out to account B DX on premises. - Account A S3 egress yes/no - Account A DX egress yes/no - Account B S3 egress yes/no - Account B DX egress yes/no Thanks in advance
1
answers
0
votes
2
views
asked 2 years ago

Data Transfer OUT Charges Through TGW in Another Account

Who is responsible for data transfer OUT charges when the transfer is originated by a VPC in one account, and that data passes through a Transit Gateway in another account on its way out through a Direct Connect (DX and TGW owned by the same account)? ***Details*** With the recent announcement on Direct Connect granular cost allocation (https://aws.amazon.com/about-aws/whats-new/2019/10/aws-direct-connect-aws-direct-connect-announces-the-support-for-granular-cost-allocation-and-removal-of-payer-id-restriction-for-direct-connect-gateway-association/), it is stated that we now "allocate Data Transfer Out charges to the AWS account responsible for the Data Transfer." I have a customer who acts as a transport service provider, and they own multiple DX connections that they plan to connect to Transit Gateways via a Transit VIF and DX-GW. The customers of my customer have VPCs in separate accounts that will be connected to my customer's TGW. With my customer owning the TGW, I am unclear on whether the cost allocation per the above announcement will consider the owner of the TGW responsible for the data transfer OUT, or whether that responsibility will be attributed to the owner of the VPC that originated the transfer. Also, if traffic routes through a firewall or IPS in Transit VPC owned by the DX an TGW owner on the way out of AWS, will that change the consideration of cost allocation?
1
answers
0
votes
8
views
asked 3 years ago
  • 1
  • 90 / page