Browse through the questions and answers listed below or filter and sort to narrow down your results.
AWS Global Accelerator Response IP does not Match Accelerator IP
I have a Global Accelerator (52.223.XXX.XXX) with an Endpoint targeting my EC2 instance (3.134.XXX.XXX). When clients send UDP traffic via the Global Accelerator, the response IP is that of the EC2 instance rather than the Global Accelerator. Since the client application expects the response IP to match the request IP, it does not work correctly. I have no control over the client application. Is there some way to configure the services to behave how I need it to? To be clear: * Current behavior: Client sends UDP traffic to 52.223.XXX.XXX (Global Accelerator) and receives a response from 3.134.XXX.XXX (EC2 instance). * Wanted behavior: Client sends UDP traffic to 52.223.XXX.XXX (Global Accelerator) and receives a response from 52.223.XXX.XXX (Global Accelerator).
LimitExceededException when creating a Global Accelerator on brand new account
I just created a new AWS account under our existing organization and am attempting to deploy our infrastructure to it (using Pulumi). It includes a Global Accelerator which is unable to be provisioned and throws the following exception: ``` LimitExceededException: Limit Exceeded for the number of Accelerators that can be created for account XXXXXXXXX ``` The account is empty and has 0 accelerators associated with it. I also tried to create one from the AWS web UI and experienced the same result.
Alias a dual-stack Global Accelerator in Route 53
Now AWS Global Accelerator finally can be configured as dual-stack it would be a good option that you can 'alias' a dual-stack global accelerator as AAAA record in Route 53. You can now only use this dual-stack configuration in Route 53 by entering the IPv6 addresses manually.
AWS Global Accelerator IP Subnet Range not up to date in ip-ranges.json
I have a public ALB with a WAF firewall attached to it and a Global Accelerator endpoint which forwards traffic to this ALB. Now, I'd like to limit direct access to the ALB to IP Range of the AWS Global Accelerator range - so to start with, none can access directly the ALB if not via the GA endpoint. I have created an AWS Lambda as per https://aws.amazon.com/blogs/security/automatically-update-aws-waf-ip-sets-with-aws-ip-ranges/ which downloads the https://ip-ranges.amazonaws.com/ip-ranges.json file and adds automatically all the IP Subnets that matches "service": "GLOBALACCELERATOR" to the WAF IPset for both IPv4 and IPv6. The process works and the Lambda can successfully add the IP address range to the WAF IPSet, though when I configure a rule to Match/Count this IPSet, I'm not seeing any hits that matches these subnets. The only way I got this to match was to add all the IP ranges which matches "service": "AMAZON" rather then "service": "GLOBALACCELERATOR". This makes me believe that the https://ip-ranges.amazonaws.com/ip-ranges.json list is not updated with the correct IP Ranges for the GLOBALACCELERATOR.
How to remove Global Accelerator Endpoint from Group programmatically?
I can add an endpoint to a group using `aws globalaccelerator update-endpoint-group`, but how do I remove an endpoint from an endpoint group?? Closest thing I can find is `remove-custom-routing-endpoints` but I'm using a Standard GA, not an custom one.
Host S3 website with on-premises DNS server without Route53
I have an S3 bucket set up for "Static Website Hosting", a CloudFront distribution with our own SSL certificate and allowing Host header, a Global Accelerator IP address attached to an Application Load Balancer. The Application Load Balancer does a 301 redirect to the S3 bucket. I know that you can set an EC2 instance as a target group and forward to that to preserve the original URL. Can you also preserve the original URL using this method of 301 redirect to a Cloudfront distribution tied to an S3 bucket?
Integration of Global Accelerator with Cognito
Currently AWS Cognito stores users in one region. This causes all of client network requests go to this specific region, which can cause significant latency. (Imagine a scenario when Cognito region is US-east and client is in Australia) Global solve issues like that (Backend service operate in region A, but clients can connect to GlobalAccelelator locations which reduce latency) **It there any simple way** of integrating Cognito and Global Accelerator in such a way that GlobalAccelelator will just 'proxy' all traffic to Cognito region?
AWS Zone Apex challenge with older DNS server
The University that I work for has its own DNS servers. They are older and need an IP address to point to for the zone apex record. DNS migration is not an option. We have a site in AWS Amplify. We want to use the Amplify website for our root domain, "example.edu". RFC 1034 says that the zone apex must be an A Record, and not a CNAME. According to the article at https://aws.amazon.com/blogs/networking-and-content-delivery/solving-dns-zone-apex-challenges-with-third-party-dns-providers-using-aws/, there are three options: Route53, Elastic IPs with EC2 instances, and Global Accelerator. Since we are using AWS Amplify, we can't do the EC2 option. The Route53 option won't work with our old DNS server, which only works with IP addresses. The third option is to use AWS Global Accelerator and an Application Load Balancer (ALB) which does a 301 redirect to our Cloudfront distribution that has the custom SSL cert for our Amplify instance. When we point our DNS at the IP associated with AWS Global Accelerator, the redirect is working, but the URL is showing the Cloudfront distribution instead of example.com. I was told that whitelisting the Host header would fix this, but it just returns a 403 error saying that the request could not be satisfied. I am not sure if I am on the right track and need some adjustment somewhere, or if I need to do something completely different.
Multi region Active active APIGateway
We are building a global application that consists of regional API Gateways that should be accessible from a global.example.com domain with Active-active failover between regions. We are constrained to follow a pattern of using a different account per region and can possibly need to use the same regions (For eg uswest-2 in AccA, uswest-2 in accB and useast2 in acc C). Two approaches we are considering for the failover is: 1. In region/account A, Make the APIGateways private with vpc endpoint and front them with an ALB. We can use a Global Accelerator pointing to this to get static IPs and finally create global.example.com pointing to this accelerator. However, for region/account B, we cannot use the accelerator in A to add an endpoint in region/account B since cross acccount resouces isn't supported. Is there a workaround for this? 2. Another approach is to use the same custom domain in both regions like above, but keep the APIgateway public and use a route53 record to point global.example.com to use CNAMEs of the public APIGateway in multiple regions/accounts. Will this work as described? Which approach would be the recommended one given our priority is to maximize the Availability and minimize time for failure routing.
At the Business Support Plan tier, how do you escalate?
We're on the Business support tier because "Enterprise On-Ramp" would be about a 50% increase in our monthly costs. And we've had a support ticket open for 6 months (related to Global Accelerator). They've agreed it's a problem, but it's "engineering is working on it". Support said that engineering would provide an estimated timeline and ETA last week, but that didn't happen. First level support seems to be trying, but they apparently can't get anything done either. Meanwhile I have a customer eagerly awaiting the fix. So the question is, do we have any recourse such as talking to some sort of account rep or some such? Or is it simply, "sorry no additional help for you without more money"? (Not that I know that an account rep could make engineering fix the problem but in my experience in past jobs with dealing with large vendors, the account managers were generally of some help with at least finding a real status on such problems.)