By using AWS re:Post, you agree to the Terms of Use
/Networking & Content Delivery/

Questions tagged with Networking & Content Delivery

Sort by most recent
  • 1
  • 90 / page

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

How to connect a Load balancer and an Interface VPC Endpoint together using CDK?

Acronym legend: * ALB - ApplicationLoadBalancer * ATG - ApplicationTargetGroup aka Target Group * VPC - Virtual Private Cloud **Our situation:** Using the AWS Console manually, it was shown that using Route 53 to an ALB (Application Load Balancer) to a private Interface VPC Endpoint to a private REST API-Gateway to a private Lambda works well. (ALB and a gateway Custom-domain-name exist due to https and the needed Certificate) The ALB needs a Target Group which targets the IP addresses of the Interface VPC Endpoint. (We tried using InstanceIdTarget with the endpoint's vpcEndpointId, but that failed with the error *Instance ID 'vpce-WITHWHATEVERHERE' is not valid* ) Using CDK, we created the following (among other things) using the aws_elasticloadbalancingv2 module: * ApplicationLoadBalancer (ALB) * ApplicationTargetGroup (ATG) aka Target Group We added a listener to the ALB. We added the Target Group to the listener. **It’s not clear how to get the IP addresses from the VPC endpoint. We want to add the IP addresses to the ATG aka Target Group using the targets property.** How to get the IP addresses of the Interface VPC Endpoint via CDK? A sample of resources we've used: * https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html * https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2-readme.html * https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer.html * https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationTargetGroup.html * https://stackoverflow.com/questions/57267594/how-to-get-privateipaddress-of-vpc-endpoint-in-cdk * https://medium.com/codex/aws-private-api-gateway-with-custom-domain-names-350fee48b406 - The approach we want in general. We're using the latest available as of this writing (AWS CDK 2.5.0)
1
answers
0
votes
8
views
FinneyCanHelp
asked 5 days ago

AWS Application Load Balancer and Http2 Persistent Connections ("keep alive")

I have some questions about the "AWS Application Load Balancer" in regard to http2 persistent connections: Does the "AWS Application Load Balancer" itself maintain its own internal http2-connection-pool? (or nah?) If the load balancer does indeed maintain its own http2-connection-pool for persistent http2 connections I have these follow-up questions: 1. I can't find anything in the AWS docs explaining how the size(s) of the http2-connection-pools (maintained by ALB) are configured (if at all). Can it maintain for example 2 million http2 connections open at the same time (for the sake of ultra low latency). At what cost (are there scaling costs)? Any links that elaborate on these aspects? 2. Does the ALB, by default, maintain a fixed-size http2-connection-pool between itself and the browsers (clients) or are these connection-pools dynamically sized? If they are fixed-size how big are they by default? If they are dynamic what rules govern their expansion/contraction and what's the max amount of persistent http2-connections that they can hold? 30k? 40k? 5million? 3. Let's assume we have 20k http2-clients that run single-page-applications (SPAs) with sessions lasting up to 30mins. These clients need to enjoy ultra-low latency for their semi-frequent http2-requests through AWS ALB (say 1 request per 4secs which translates to about 5k requests/second landing on the ALB):Does it make sense to configure the ALB to have a hefty http2-connection-pool so as to ensure that all these 20k http2-connections from our clients will indeed be kept alive throughout the lifetime of the client-session?Reasoning: In this way no http2-connection will be closed and reopened (guarantees lower jitter because reestablishing a new http2-connection involves some extra latency - at least that's my intuition about this and I'd be happy to stand corrected if I miss something)
1
answers
1
votes
9
views
Dominick Sidiropoulos
asked 6 days ago

Connections time out of a client request to a Network Load Balancer

I connected two AWS Accounts with a peering connection. All subnets on each side are allowed to talk with each other. If I try to communicate between the two sides with the IPs of the instances it works fine. I added a NLB on one side to avoid IPs and use a DNS name as a host. The ECS service registers the IP automatically to the NLB target group to achieve the goal. The client on one side tries to make a request through the NLB to the same target as before. The NLB is configured as internal and assigned to 3 AZ, the target group contains the IP of the target I want to reach. Each AZ contains a subnet with its own small range of IPs(1.0.x.0/20) but all the CIDR used for the rules are using the broader IP range(1.0.0.0/16) to cover them all. There are no overlappings between any IP ranges on both Accounts. The NLB has 3 private IPs(one for each AZ) registered on its DNS entry. I can do the request to the IP behind the NLB with success and the request to the NLB IP which is associated with the AZ on which the target IP is located. The request to the two other IPs of the NLB results in a timeout. There's one ACL for the whole Account which allows all traffic, the default security group allows the traffic of the CIDR of both Accounts and the routing tables contains an entry to route the traffic to the peering connection for the CIDR of the other side and one route for the local CIDR to "local". I also tried the Reachability Analyzer with the peer connection as sender and the NLB as a receiver and specify the IP of the target in the target group. This test succeeds because it uses the one NIC which is in the same AZ. I tried to use the peer connection as sender and the other two NICs of the NLB and set the IP of the target which fails with NO_PATH. To me, it looks like the NLB doesn't route the request to the other NIC. But I couldn't find any limitations to this kind of setup on the documentation.
1
answers
0
votes
5
views
AWS-User-5257795
asked 11 days ago

How to solve a "Connection refused" error on ECS task in awsvpc network mode?

Hi there, Even though `containerPort` as well as `hostPort` are set, we experience trouble when connecting to an ECS task from outside the container (even the host EC2 instance cannot access it). ``` sh-4.2$ # This is the EC2 host of the task's container sh-4.2$ curl -o /dev/null http://localhost/some/file.zip # Same with 127.0.0.1 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (7) Failed to connect to localhost port 80: Connection refused ``` Excerpt of the task definition: ```terraform network_mode = "awsvpc" // needed in order to use A records for service discovery network_configuration { subnets = [module.subnet_private.id] } ``` Excerpt of the container definition: ```terraform portMappings = [ { hostPort = 80, // must equal containerPort due to awsvpc networking mode containerPort = 80, // see nginx.conf protocol = "tcp" } ] ``` Full docker inspect: ``` [ { "Id": "f852e5f1f50154f3fab574eac406fd91038a2e5514053d777d21f81c5614dc79", "Created": "2022-01-03T18:52:30.356339157Z", "Path": "/docker-entrypoint.sh", "Args": [ "nginx", "-g", "daemon off;" ], "State": { "Status": "running", "Running": true, "Paused": false, "Restarting": false, "OOMKilled": false, "Dead": false, "Pid": 15694, "ExitCode": 0, "Error": "", "StartedAt": "2022-01-03T18:52:30.866257409Z", "FinishedAt": "0001-01-01T00:00:00Z" }, "NetworkMode": "container:389dbe8d2c45cbb0ddddbbf2a8f46e62483124023880b96ef04319b7050ff5c5", "PortBindings": {}, "RestartPolicy": { "Name": "", "MaximumRetryCount": 0 }, "AutoRemove": false, "VolumeDriver": "", "VolumesFrom": [], "CapAdd": [], "CapDrop": [], "CgroupnsMode": "host", "Dns": null, "DnsOptions": null, "DnsSearch": null, "ExtraHosts": null, "GroupAdd": null, "IpcMode": "shareable", "Cgroup": "", "Links": null, "OomScoreAdj": 0, "PidMode": "", "Privileged": false, "PublishAllPorts": false, "ReadonlyRootfs": false, "SecurityOpt": null, "UTSMode": "", "UsernsMode": "", "ShmSize": 67108864, "Runtime": "runc", "ConsoleSize": [ 0, 0 ], "Isolation": "", "CpuShares": 1024, "Memory": 1073741824, "NanoCpus": 0, "CgroupParent": "/ecs/acafdacf06b9475b83e080cbd637f0fc", "BlkioWeight": 0, "BlkioWeightDevice": null, "BlkioDeviceReadBps": null, "BlkioDeviceWriteBps": null, "BlkioDeviceReadIOps": null, "BlkioDeviceWriteIOps": null, "CpuPeriod": 0, "CpuQuota": 0, "CpuRealtimePeriod": 0, "CpuRealtimeRuntime": 0, "CpusetCpus": "", "CpusetMems": "", "Devices": null, "DeviceCgroupRules": null, "DeviceRequests": null, "KernelMemory": 0, "KernelMemoryTCP": 0, "MemoryReservation": 0, "MemorySwap": 2147483648, "MemorySwappiness": null, "OomKillDisable": false, "PidsLimit": null, "Ulimits": [ { "Name": "nofile", "Hard": 65536, "Soft": 32768 } ], "CpuCount": 0, "CpuPercent": 0, "IOMaximumIOps": 0, "IOMaximumBandwidth": 0, "MaskedPaths": [ "/proc/asound", "/proc/acpi", "/proc/kcore", "/proc/keys", "/proc/latency_stats", "/proc/timer_list", "/proc/timer_stats", "/proc/sched_debug", "/proc/scsi", "/sys/firmware" ], "ReadonlyPaths": [ "/proc/bus", "/proc/fs", "/proc/irq", "/proc/sys", "/proc/sysrq-trigger" ] }, "Config": { "Hostname": "[REDACTED]", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "ExposedPorts": { "80/tcp": {} }, "Cmd": [ "nginx", "-g", "daemon off;" ], "Image": "[REDACTED]", "Volumes": null, "WorkingDir": "", "Entrypoint": [ "/docker-entrypoint.sh" ], "OnBuild": null, "Labels": { "com.amazonaws.ecs.cluster": "Nginx_Build_agent_proxy", "com.amazonaws.ecs.container-name": "buildagent-proxy", "com.amazonaws.ecs.task-arn": "[REDACTED]", "com.amazonaws.ecs.task-definition-family": "buildagent-proxy", "com.amazonaws.ecs.task-definition-version": "20", "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>" }, "StopSignal": "SIGQUIT" }, "NetworkSettings": { "Bridge": "", "SandboxID": "", "HairpinMode": false, "LinkLocalIPv6Address": "", "LinkLocalIPv6PrefixLen": 0, "Ports": {}, "SandboxKey": "", "SecondaryIPAddresses": null, "SecondaryIPv6Addresses": null, "EndpointID": "", "Gateway": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "IPAddress": "", "IPPrefixLen": 0, "IPv6Gateway": "", "MacAddress": "", "Networks": {} } } ] ```
1
answers
1
votes
8
views
GenericAWSUser
asked 13 days ago

Users in parts of northern Italy blocked from website access, but no other worldwide locales are blocked

I am supporting a company which has a production EC2 instance in Asia-Pacific (Singapore) running a fairly simple web server. As of sometime Friday (European Central time) a company employee in the Milan area reported that the instance was unreachable. An attempt to connect times out. Company people in the US, Asia, and central Europe have no issues connecting to the web server. If the user in Milan switches to a TOR browser (therefore a different source IP somewhere in the world) he has no issues accessing our website. I gave our user a URL with the public IP address of our web server instead of the name in order to validate that this was not a DNS issue, and the result is the same. There is no connection being made at all between his system and our instance via public IP. A traceroute shows that the connection goes through AWS routers with public IP addresses and eventually just never connects. Our firewall ACLs for the instance in Singapore have no restrictions at all to destination port 443 from 0.0.0.0 (everywhere). There have been no changes made to our AWS configuration or the configuration of the web server on the instance at all for the last several months. It appears quite strongly that there is an internal network routing problem or blockage within AWS which is preventing our user in Milan from reaching our site in Singapore. We do not have a paid support account which would allow us to create a Tech Support ticket. Does anyone have any idea how to reach AWS about what appears to be a network infrastructure issue for them? Does anyone have any other ideas which I should pursue in order to identify what is causing this connection problem specific to the Milan area?
1
answers
0
votes
6
views
Rob Scott
asked a month ago

AWS Transit Gateway isolated routing with Shared Services

Hello, We are working with a client that has the following setup: 1 TGW that has 5 VPC attachments - non-prod a attachment - non-prod b attachment - prod-a attachment - prod-b attachment - shared-services attachment **Requirements:** The client would like to allow only for inter-communication of both the non-prod VPCs, as well as the prod VPCs. Additionally, the client would like for shared-services to be able to reach any of the VPCs. **My initial approach and the problem:** Initially, my thought was to create 3 isolated routing domains, which were represented by 3 separate TGW route tables. I was unable to achieve this because there is a limitation of only being able to associate 1 attachment with 1 TGW route table. If we were able to make more than one attachment for the same VPC, we could get around this issue, but unfortunately that is not possible. **Looking for recommendations on the best way to address the above requirements.** The only other option I can think of to accomplish these requirements is to use 1 TGW route table, associate all of the attachments with it, and then ultimately use NACLs in the individual VPCs to restrict traffic. To me, this seems like a pain to maintain, so I wanted to see if there are any other ways to address this problem. ---------- **More Information on what I've already tried** My initial idea was to have 3 TGW route tables (one for each "routing domain"): - non-prod (associated with the non-prod-* attachments) - prod (associated with the prod-* attachments) - shared (associated with all attachments) The problem with this approach is the **shared** TGW route table because as I mentioned above, you can't associate an attachment with more than one route table. In essence this is a "flat" routing architecture rather than isolated and directly contradicts with what I'm trying to do causing this problem. Thanks in advance!
1
answers
0
votes
1
views
Chris_S
asked 2 years ago
  • 1
  • 90 / page