Questions tagged with Networking & Content Delivery

Content language: English

Sort by most recent

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

CloudFront - API Gateway as Reverse HTTP Proxy to CloudFront - ALB - EC2

I'm trying to set up an API Gateway as a simple proxy, using the Proxy option. The back-end is a endpoint hosted by an Cloudfront as reverse proxy for ALB + application running on EC2. User -> Cloudfront -> API Gateway Proxy Integration -> CLoudFront -> ALB -> Internal APIs hosted by EC2s. Cloudfront and API gw proxy located is in AWS account A and CloudFront + ALB + EC2 is located in account B. When I use API gateway console to test method, request hits the targeted internal api without any problem. Test execution log: ``` Execution log for request 849015fb-12c9-4619-bc96-363ecb6e9e94 Fri Nov 18 17:33:08 UTC 2022 : Starting execution for request: 849015fb-12c9-4619-bc96-363ecb6e9e94 Fri Nov 18 17:33:08 UTC 2022 : HTTP Method: POST, Resource Path: /api/v2/test/apply Fri Nov 18 17:33:08 UTC 2022 : Method request path: {} Fri Nov 18 17:33:08 UTC 2022 : Method request query string: {} Fri Nov 18 17:33:08 UTC 2022 : Method request headers: {} Fri Nov 18 17:33:08 UTC 2022 : Method request body before transformations: Fri Nov 18 17:33:08 UTC 2022 : Endpoint request URI: https://example.com/ext/v2/test/apply Fri Nov 18 17:33:08 UTC 2022 : Endpoint request headers: {x-amzn-apigateway-api-id=u041f78dig, User-Agent=AmazonAPIGateway_u041f78dig, X-Custom-Header=xxx} Fri Nov 18 17:33:08 UTC 2022 : Endpoint request body after transformations: Fri Nov 18 17:33:08 UTC 2022 : Sending request to https://example.com/ext/v2/test/apply Fri Nov 18 17:33:08 UTC 2022 : Received response. Status: 400, Integration latency: 55 ms Fri Nov 18 17:33:08 UTC 2022 : Endpoint response headers: {Content-Length=0, Connection=keep-alive, Date=Fri, 18 Nov 2022 17:33:08 GMT, Server=nginx, X-Custom-Header=4100adeb, X-Cache=Error from cloudfront, Via=1.1 c022ca80d7b946eb138dfd2e55c98980.cloudfront.net (CloudFront), X-Amz-Cf-Pop=IAD12-P4, X-Amz-Cf-Id=xxx} Fri Nov 18 17:33:08 UTC 2022 : Endpoint response body before transformations: Fri Nov 18 17:33:08 UTC 2022 : Method response body after transformations: Fri Nov 18 17:33:08 UTC 2022 : Method response headers: {Content-Length=0, Connection=keep-alive, Date=Fri, 18 Nov 2022 17:33:08 GMT, Server=nginx, X-Custom-Header=4100adeb, X-Cache=Error from cloudfront, Via=1.1 c022ca80d7b946eb138dfd2e55c98980.cloudfront.net (CloudFront), X-Amz-Cf-Pop=IAD12-P4, X-Amz-Cf-Id=xxx} Fri Nov 18 17:33:08 UTC 2022 : Successfully completed execution Fri Nov 18 17:33:08 UTC 2022 : Method completed with status: 400 ``` You can count 400 as success, because it returned from internal api running on EC2. When I'm trying to invoke cloudfront-account-a.com/api/v2/test/apply I'm getting 403 error from CF with the following headers: ``` access-control-allow-origin: * access-control-expose-headers: * content-length: 915 content-type: text/html date: Fri, 18 Nov 2022 17:11:43 GMT referrer-policy: strict-origin-when-cross-origin strict-transport-security: max-age=31536000 via: 1.1 a27022837959b6f70545c8d6d0de9d04.cloudfront.net (CloudFront), 1.1 f0f1092b2ad1f0e573a4fcbefe4fb620.cloudfront.net (CloudFront), 1.1 6bc1c280aeef9bbdeb102c7f4e4f773e.cloudfront.net (CloudFront) x-amz-apigw-id: xxx x-amz-cf-id: xxx x-amz-cf-pop: IAD12-P4 x-amz-cf-pop: IAD79-C1 x-amz-cf-pop: IAD89-C1 x-amzn-remapped-connection: keep-alive x-amzn-remapped-content-length: 915 x-amzn-remapped-date: Fri, 18 Nov 2022 17:11:43 GMT x-amzn-remapped-server: CloudFront x-amzn-requestid: 4d928828-e650-492f-b165-0654c97acab5 x-cache: Error from cloudfront x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block ``` What I'm doing wrong? Is it even possible to proxy request in the way I'm trying to do?
1
answers
0
votes
45
views
IP
asked 18 days ago

[AWS BUG?] NLB stops working during blue/green deployment with code-deploy.

I have a Fargate + ECS service, with an NLB with a TCP listener in 443 port and a TCP test listener in port 9443. We use NLB with TCP to do TLS termination the hosts (containers). I also have a second Target Group for blue/green deployments. All target types are setup to IPv4, and the service is working as expected outside deployments. I've run the following experiments: 1. When I run my integration tests outside of a deployment (both listeners are pointing to the same target group) all tests pass against both listeners (443 and 9443). 2. When I run them in the context of a deployment, in the AfterAllowTraffic hook (both listeners pointing to the replacement target group), all tests pass against both listeners (443 and 9443). 3. When I run the tests in the context of a deployment, in the AfterAllowTestTraffic hook, after I checked that listener 443 points to the blue target group, and the listener 9443 points to the green target group with a healthy container, neither of them pass, they fail to establish connection. However, If I run the tests directly against the container instances by targeting their IP, then all tests pass. 4. If I manually replicate the blue/green deployment setup, and point the test listener to other target group, so listener in 443 keeps pointing at a target group and then listener 9443 points to another target group, then both listeners STOP WORKING! 5. If in the experiment #4, I delete the listener on 9443, so there is only one listener in 443 targeting the blue target group, then it starts working again. Is this a misconfiguration on my side? It seems likely this is a problem in AWS-NLB side?
1
answers
0
votes
37
views
asked 20 days ago

CloudFront: How to use Lambda@Edge to change the S3 origin region with Origin Access Control enabled

I'm using a CloudFront with an origin-request Lambda@Edge function to switch between S3 origins in different regions, much like the "[Using an origin-request trigger to change the Amazon S3 origin Region](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-content-based-routing-examples)" example in the AWS CloudFront Developer Guide. This works very well with OAI (Origin Access *Identity*) enabled, to ensure content in S3 is only accessible through CloudFront. A few months ago [CloudFront introduced OAC (Origin Access *Control*)](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-introduces-origin-access-control-oac/), which has several advantages over OAI. **My question is:** How to use an origin-request Lambda@Edge function to switch between S3 origins in different regions, with OA**C** enabled? (if that is currently possible) --- For testing purposes, my origin-request lambda function (nodejs16) is as below. CloudFront OAC is configured to "always sign" requests. The bucket policy for both the default S3 origin bucket in `eu-central-1`, and the alternative S3 origin bucket in `ap-northeast-1`, is configured to allow `s3:GetObject` from the `cloudfront.amazonaws.com` service principle with `AWS:SourceArn` of the CloudFront distribution's ARN. **Origin Request Edge Lambda**: ``` exports.handler = (event, context, callback) => { const request = event.Records[0].cf.request; request.origin.s3.region = 'ap-northeast-1'; request.origin.s3.domainName = 'bucket-in-ap-northeast-1-example-origin.s3-ap-northeast-1.amazonaws.com'; request.headers['host'] = [{ 'value': request.origin.s3.domainName }]; console.log(event); console.log(request); callback(null, request); }; ``` **I see this error**, which seems to indicate that the origin-request Lambda is correctly directing the request to the alternate bucket in `ap-northeast-1`, however the authorization header added by OAC is still generated using the default S3 bucket's region (`eu-central-1`), and so is not valid for the alternate bucket in Tokyo. ``` $ curl -isS https://xxxxxxxxxxxxx.cloudfront.net/ HTTP/1.1 400 Bad Request Content-Type: application/xml Transfer-Encoding: chunked Connection: keep-alive x-amz-bucket-region: ap-northeast-1 Date: Tue, 15 Nov 2022 13:38:14 GMT Server: AmazonS3 X-Cache: Error from cloudfront Via: 1.1 0e2886f2f2f8b98f7eaf91c8c6ee8644.cloudfront.net (CloudFront) X-Amz-Cf-Pop: TPE51-C1 X-Amz-Cf-Id: jMQB5Qz7D21Uh2Ew9pPHQj1ReHhSAbhRQecoPCspMB9LQAhvyFvr1g== <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>AuthorizationHeaderMalformed</Code> <Message>The authorization header is malformed; the region 'eu-central-1' is wrong; expecting 'ap-northeast-1'</Message> <Region>ap-northeast-1</Region> <RequestId>JZ26WY2ZGXPD8EH9</RequestId> <HostId>v4iIZa5+x3J3mogFRkpGBMnUiC4nLFI1G11ijPrgPadZ9v2hjp+xSIEdbMROWembA5tevIfPyfs=</HostId> </Error> ```
0
answers
0
votes
35
views
profile picture
asked 21 days ago