We have started a PHP beanstalk application, first we tested the API as public and it was working, then we tried to make the API private to be called through a VPC Endpoint following the tutorial and instructions but no luck.
We have created the Endpoint and resource policy to income the API
We have attached the Resource policy to the API
While troubleshooting, API can be invoked from the same EC2 instance (curl -X GET https://*** ) and it was successful, but the issue is from beanstalk application it never hits the API, there are no CloudWatch logs either
Here is the code we use to invoke the API from cloud watch "https://API-ID-vpce-*****.execute-api.eu-west-1.amazonaws.com/Pro/calc/?test="
We already allowed the HTTPS inbound and outbound on security groups
Honestly we have tried everything since 10 days with no luck
Appreciate your support into this
Kind Regards
Based on the comments.
The cause of the issue remains undetermined. In this case a support ticket will be placed with AWS support for assistance.
Related
I have a service to service set up that I completed using the google cloud tutorial (https://cloud.google.com/run/docs/authenticating/service-to-service#nodejs)
Changed the cloudrun Service account to have roles/run.invoker (they both share the same role)
Make a request to get the access token: http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://XXXX-XXXX-XXXX-xx.a.run.app'
(failing) Use that access token to make a request at https://XXXX-XXXX-XXXX-xx.a.run.app/my-endpoint with the access token: axios.post('https://XXXX-XXXX-XXXX-xx.a.run.app/my-endpoint', {myData}, {headers: {Authorization: 'Bearer eyJhbGciOiJSUz.....'}})
However, on step 3, making the call to my service, I receive a 403 error, any thoughts on what I missed?
Note: I have tried deploying my invoked service with --allow-unauthenticated and without it. I am not using a custom domain, I am using the CloudRun created url.
PS: If I change the ingress from internal and load balancer to all it works, however I'm not sure if this is correct to do.
The HTTP 403 Forbidden error message when accessing your Cloud Run service means that your client is not authorized to invoke this service.
You have not granted the service account permission to call the receiving service. Your question states that you added roles/run.invoker but the error message indicates you did not complete this step correctly.
Go to the Google Cloud Console.
Select the receiving service (this is the Cloud Run service you are calling).
Click Show Info Panel in the top right corner to show the Permissions tab.
In the Add members field, enter the identity of the calling service.
Select the Cloud Run Invoker role from the Select a role drop-down menu.
Click Add.
Note: When requesting the Identity Token, do not specify the custom domain. Your question's wording is confusing on that point.
[UPDATE]
The OP has enabled internal and load balancer. This requires setting up Serverless VPC Access.
Connecting to a VPC network
Solution was to add a VPC Connector and route all traffic through it. I added this to the deploy script --vpc-egress all-traffic. Originally I had --vpc-egress private-ranges-only to connect to redis MemoryStore, however this was insufficient to connect to my other service (internal only ingress).
Credit to excellent insight from #JohnHanley and #GuillaumeBlaquiere
Interesting Note About NodeJS: My container wouldn't start when I switched the --vpc-egress to all-traffic, and I had no idea why because there were no logs. It turns out running node v16.2 caused some weird issues with --vpc-egress all-traffic that I couldn't debug, so downgrading to 14.7 allowed the container to start.
I've got a Django app setup to use django-allauth to connect to Twitter. The flow is all working locally and I've followed the same setup steps on Lambda to add my tokens, site, etc.
When I try to access the login url (/accounts/twitter/login/) the request eventually times out with this message from AWS Lambda:
{"message": "Endpoint request timed out"}
The last message from zappa tail before the timeout event is:
[1619019159940] [DEBUG] 2021-04-21T15:32:39.939Z 7f66a0e3-58de-4612-82c0-54590d69676f Starting new HTTPS connection (1): api.twitter.com:443
I've seen that the gateways have a 30 second timeout but I don't think it should be taking this long anyway. Locally, it's taking a couple of seconds.
Does anyone with knowledge of these platforms have an idea where the bottleneck might be and where the issue could be? Or have any pointed questions to help debug?
Things I've already checked and (tentatively) ruled out:
The database backend is AWS Aurora Serverless, and I did worry that the double-serverless setup might be causing the slow speeds. However, a simple call of the Django management command (zappa manage dev migrate returns takes less than a second so I've ruled that out for now. Plus the Admin dashboard loads fine which is also accessing the DB.
I've got both the dev and live URLs added into Twitter's dashboard as valid OAuth callback URLs.
Leaving this answer to help future searches, although it's not the route I'll take.
Thanks to #Jens in the comments for pointing towards the VPC issue. You need to add a NAT Gateway service to the Lambda to add public internet access to a private VPC.
"To grant internet access to your function, its associated VPC must have a NAT gateway (or NAT instance) in a public subnet."
Source: https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/
This is a per-hour billed extra so might defeat the point of using serverless (if you're using it for small fees and simplicity rather than scale like I was).
We have implemented Dynatrace and we need to add our AWS account to pull CloudWatch logs.
The problem: We have a corporate proxy and firewall which is super locked down and seems to block whichever requests Dynatrace is trying to make to AWS to authenticate with the key and secret.
The infra guys has allowed a bunch of AWS domains per region to read CloudWatch logs, but we still can't authenticate (see image below).
I have set up a Dynatrace security gateway in AWS which our local gateways are able to access. We are successfully getting logs form OneAgents through the SGW. The problem is getting the CloudWatch logs/integration going.
The error in the image below leads me to believe that Dynatrace is not able to communicate to the AWS auth servers at all.
Any advice would be appreciated.
I'm just a dev
We are not allowed to open the amazon domain.
#corporate-devlife
I've recently gotten into AWS Serverless Architecture with .NET Core 1.0. In my application we use Elasticsearch on its own machine in order to maintain it. What I am trying to do is use AWS Elasticsearch Service from AWS API Gateway which is being proxied by AWS Lambda. (I believe I have typed this correctly)
When ever my code accesses my Elasticsearch domain I receive a timeout error. As of right now, my Elasticsearch domain is left wide open so anyone can access the information. I would like to lock it down for only the API Gateway and Lamda function.
I've tried messing with the policies and roles to no success. Has anyone tried to do what I am trying to do, if so, how were they able to connect it? Or is there a better way?
The simple solution is to put all of your services out of the VPC they are in right now (I believe they are not in the same one, as your IO calls get timed out).
My answer here would give you a nice background on AWS Lambda with VPC and why external IO calls time out.
AWS lambda invoke not calling another lambda function - Node.js
note: the answer is not related to NodeJS.
I am fairly new to AWS Lambda but sure can see the benefits of it and stumbled upon the superb framework Serverless to help me built solutions on Lambda.
I started out building solutions using AWS API Gateway but really need "internal" VPC API's and not public Internet facing API's like API GW creates.
I found that Servless indeed can expose a HTTP endpoint but I can't figure out how this is done and how the URL is created.
When I deploy the Lambda from Serverless it gives me the URL, e.g.:
https://uxezd6ry8z.execute-api.eu-west-1.amazonaws.com/dev/ping
I would like to be able to find (or create) this same http listener for already existing Lambdas so my question is how is the URL created and where is teh actual HTTP listener deployed?
You might be looking for the invoke url,
1. go to https://console.aws.amazon.com/apigateway
2. select api link (which you have deployed on aws lambda).
3. select stages in left side panel and
see the invoke url.
Adding a http listener can be done by going to your lambda function, selecting the 'triggers' tab and 'add trigger', finally selecting API Gateway - but as others mentioned this does create a public facing url.
Duh, I was in the wrong AWS logon previously so the API GW was not showing any matching Serverless API and that was why I couldn't understand how they did it...
Once I logged into the AWS account that hosts the Serverless structure I can see the API GW GET API's for the Serverless HTTP listener.