My company is currently working to provide a large enterprise customer with a private AWS web application accessed via IPSec tunnels. We are in initial discussion with the customer's various IT/Networking teams but are working out possible architectures before the full design coordination meeting.
Key components of our current VPC design:
- VPC is a /16 RFC 1918 space e.g. 10.1.0.0/16
- Access to the application is via an internal AWS ALB with multiple AZs.
- The ALB client endpoint IPs are private and dynamically assigned and updated in DNS.
Anticipated Customer Constraints
- To avoid IP conflicts, Customer will not peer/reserve/route to RFC 1918
- We need to provide target IPs in advance (static IPs/CIDRs)
- Future changes are slow. Stable design is important upfront.
We are looking at ways to solve this and came across what is probably a bad idea, but we can't see why.
What if our company purchased and registered a public /24 but did not advertise routes on the public internet. Instead we add our new public range to the VPC as usable IPs (again not publicly routable or registered with AWS for public advertisement). We then configure the load balancer to use IPs from this CIDR as it's endpoint addresses.
To the customer, we provide this new privately-owned "public" range which they route across our B2B IPSec tunnel.
Conceivably this guarantees no conflicts on their end and makes it easy for us to dynamically use IPs from a given subnet (rather than randomly assigned non-contiguous AWS EIPs).
Here's the crazy idea: What if we reused this architecture and "public" CIDR with multiple customers (lets say 25 unique large enterprises)?
Pros:
- We only have to buy one public CIDR block.
- Design is standard and reproducible for customers
- Customer only has to configure routes for a single subnet rather than multiple /32 addresses.
Cons:
- Our org cannot access multiple customer stacks simultaneously without DNAT. (not an issue for us)
- Cannot advertise public CIDR on the internet.
What are we missing?
No comments:
Post a Comment