- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
Hi Gary,
If the goal is to connect from NB-IoT provider to VPC1 (or VPC2) via the S2S connection to VPC-Central, we cannot leverage the peering connection between VPC-Central and VPC1/VPC2 as peering doesn't support transitive routing. So traffic from NB-IoT wont ever make it to VPC1/2 via Central.
You could setup a TGW with 2 VPC's only without the Central VPC. The Inbound Resolvers always sit in the VPC where the private hosted zone would be configured as they would be forwarding queries from VPN end to the VPC DNS resolvers which would then forward it to the private hosted zone internally for the respective domain query. As such, you would have to choose one VPC from either of the two (VPC1/2) to configure the private hosted zone/zones and the endpoints. However, the VPC1/2 would also have the IoT interface endpoint configured in it. In the central VPC model, only the central VPC connects to Iot provider via S2S and has the inbound endpoint and the private hosted zones configured in it along with TGW. You can then add multiple VPCs in different accounts/regions as needed with the IoT endpoints in them and connect it to the central VPC via the TGW model. It's more like a hub and spoke model where you can add/remove spokes as needed without needing to change much config on hub. I would also recommend to reach out to our TGW support team for more insights on different deployment models and their config as well.
Hello Gary,
When it comes to "AWS PrivateLink" setup, we have a 'service consumer' and a 'service provider' scenario where the consumer end would have an "Interface Endpoint" configured and the provider end would have an "Endpoint Service" configured. The provider end with the endpoint service configuration basically would have a Network Load Balancer or Gateway Load Balancer configured and pointing to the target which provides the service in question. Private link concepts are discussed in https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html.
Further, when it comes to a PrivateLink setup like above, the "interface endpoint" and the "endpoint service" configuration (pointing to the load balancer) have to be in the same region. If you need to access the "endpoint service" from another region VPC, you would need to first setup peering between this VPC and the VPC having the linked "interface endpoint" and then access the service provider using the IP address of the interface endpoint. This is similar to what is discussed in the "Inter-Region access to endpoint services" section in whitepaper you mentioned (https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-privatelink/aws-privatelink.pdf).
Now, when you configure an AWS IoT, you are provided with a DNS name which usually resolves to the AWS IoT service public IP range in the region in which it is deployed. However, for instances within a VPC which may not have internet access, one could still access this IoT endpoint by means of an Interface VPC Endpoint. As such, if I have understood your scenario correctly, you would be setting up multiple IoT environments in different regions (and possibly different accounts). You would like resources in your NB-IoT provider connect via a VPN to your VPC and access the IoT endpoint in each region via the VPC Interface endpoint of the region.
Let's take a setup like below:
IoT setup in N.Virginia and Oregon. VPC1 in N.Virginia with an IoT data interface endpoint 'vpce1' VPC2 in Oregon with an IoT data interface endpoint 'vpce2'
Now, if you would like to keep one VPC for the S2S VPN with your NB-IoT provider, you can configure another VPC, say 'VPC-Central' in N.Virginia which would have the S2S setup.
In the above setup, you can have two private hosted zones in 'VPC-Central', one for "iot.us-east-1.amazonaws.com" and another for "iot.us-west-2.amazonaws.com" for Oregon endpoint. In the 1st private hosted zone, have a record for N.Virginia setup IoT endpoints to point to vpce1. Similarly, in the second zone, have the records for IoT endpoints in Oregon region.
Then, configure an Inbound Resolver Endpoint in VPC-Central such that S2S provider DNS queries for the iot domains are forwarded to it.
Now, we need the S2S provider resources to be able to finally route to the VPC endpoints in either VPC1 or VPC2 via VPC-Central. For this, you could use a Transit Gateway (https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html) setup between the VPCs. We cannot use VPC-peering between the VPCs as VPC peering doesn't support transitive routing.
Hi Rohit,
Thank you for your answer. I'm in the middle of trying it with VPC-peering, but you've given me another option and food-for-thought. I'll get back later.
Hi Rohit, If the NB-IoT provider connects to VPC-Central via a S2S VPN, and VPC-Central connects to VPC1 (or VPC2) via a VPC Peering Connection, does transitive routing need to take place? I'm just double-checking before I look into transit gateways. (I'm building all this with CDK, so once the code is there, I can quickly try different scenarios). If I use a transit gateway, do I use 3 VPC attachments, or is it also possible to use 2 VPC attachments for VPC1 and VPC2, and a single VPN attachment to the NB-IoT provider's Customer Gateway in place of VPC-Central (I'm wondering where the inbound resolvers would sit)? Thanks again, Gary
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- Wie lösche ich meinen Network Load Balancer, der VPC-Endpunkt-Services (PrivateLink) zugeordnet ist?AWS OFFICIALAktualisiert vor 2 Jahren
- Wie veröffentliche ich MQTT-Nachrichten von meinem Gerät auf AWS IoT Core, wenn ich Python verwende?AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 4 Jahren
Hi Rohit, Thanks for the clarification. I will proceed with the TGW approach with a "Central VPC". Kind regards, Gary