By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Way to make environment hiden - Internet-facing ALB + CloudFront + Client VPN

0

Currently we have the next structure for development environment: frontend (CloudFront + S3), Application Load Balancer (API as target group based on EC2 for frontend part and several additional services).
The common sense that we want to restrict access to this environment (for CloudFront is not required, but nice to have too). We configured Client VPN connection to VPC and hosted two Route53 zones private and public. ALB has rules to filter clients by IP address, this IP is address of NAT Gateway where developers routing with Client VPN. It works fine, but instances behind ALB can not establish connection for each other (cause rule has IP address match only with IP of NATGW). Possible solution - we can route all traffic from instances through NAT Gateway and add rule to ALB to allow, but in this case traffic from instances leaves VPC and charges as NATGW traffic. We want to keep common structure: Internet-facing ALB + CloudFront + Client VPN, because we have the same for production, but want to hide development environment from external users (expose only for developers). Is there way to make connection between instances privately or any appropriate solution?

Topics
Networking & Content Delivery
Tags
Amazon VPCNetworking & Content DeliveryElastic Load BalancingApplication Load BalancerAWS Client VPN
Language
English
skuzmich
asked a year ago733 views
3 Answers
0

Why not add another rule to the ALB listener to accept and route the IP addresses of the private subnets where the instances reside?

I think you are going to need two ALBs, one Internet-facing and one Internal. Both have target groups that contain the same instance/containers. Similar to this architecture, How to use Multiple load balancer Target Group Support for Amazon ECS to access internal and external service endpoint using the same DNS name.

profile pictureAWS
EXPERT
kentrad
answered a year ago
  • skuzmich
    a year ago

    I have already checked this case. Now ALB rules has the next conditions to forward traffic: Host header = app2.mydomain.com Source IP = 54.54.54.54 (NATGW IP address), 172.31.0.0/16 (this is VPC CIDR) 10.10.0.0/24 (VPN network just in case) The same rule for app1.

    I successfully can reach app1 and app2 separately from my PC when VPN is established, but still can not access app1-app2 (or app2-app1)

  • kentrad EXPERT
    a year ago

    When the internal instances try to hit the ALB, are they using the internal IP or the public IP of the ALB?

  • skuzmich
    a year ago

    I guess this is the public IP of the ALB, cause ALB is internet-facing and its DNS resolved as public addresses like (name and addresses a little distorted for showing):

    nslookup alb-development-6904175701.us-west-2.elb.amazonaws.com
Server:         127.0.0.53
Address:        127.0.0.53#53
Non-authoritative answer:
Name:   alb-development-6904175701.us-west-2.elb.amazonaws.com
Address: 55.69.102.129
Name:   alb-development-6904175701.us-west-2.elb.amazonaws.com
Address: 101.22.199.199
Name:   alb-development-6904175701.us-west-2.elb.amazonaws.com
Address: 35.209.246.77
Name:   alb-development-6904175701.us-west-2.elb.amazonaws.com
Address: 53.27.177.112

    It is resolved by record in private DNS zone of Route53 as internal resource of VPC. BTW, in ALB logs I can observe string like that (when I am trying to curl app1-app2): h2 <...> app/alb--development/f6cfe6bba2fb636e 54.201.155.68:45042 - -1 -1 -1 404 - 31 84 "GET https://app1.mydomain.com:443/ HTTP/2.0" "curl/7.81.0" ECDHE-RSA-AES <...> "fixed-response" "-" "-" "-" "-" "-" "-"

    And this address 54.201.155.68 looks like outgoing of Internet gateway, right? Seems request anyway goes outside of VPC and hit ALB

0

One way is to use a VPC Endpoint to provide private connectivity between instances. A VPC Endpoint allows instances within a VPC to securely access AWS services such as S3 or DynamoDB without going over the internet. You can create a VPC Endpoint for the target service(s) that your instances need to communicate with (e.g. EC2, ALB) and configure your instances to use the VPC Endpoint as their default route. This will ensure that all traffic to the target service(s) stays within the VPC and does not incur NAT Gateway charges.

Wilklins
answered a year ago
0

You can create a VPC Endpoint for the target service(s) that your instances need to communicate with (e.g. EC2, ALB)

I have tried to create "ec2" or "elasticloadbalancing" (or both), but no positive result, Instances still can not access each other (was checked by "curl https://app2.mydomain.com" from app1 instance).

and configure your instances to use the VPC Endpoint as their default route

Could you give a bit more description what does it mean? How should I configure our instances for this route?

skuzmich
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content