We are working on SNS to HTTPS API integration between 2 teams. So, another team has SNS topic configured in us-east-1 region and our HTTPS API is running in us-west-2 region.
Just wanted to check if we can process SNS messages generated from us-east-1 and a different AWS account in us-west-2 region.
I read somewhere (can't remember the blog post link now), that if SNS messages are generated in us-east-1, they have to be processed in us-east-1 only. If we try to process in us-east-2, message signature verification will fail and throws an invalid TopicArn exception.
Please guide if this is correct.
So, another team has SNS topic configured in us-east-1 region and our HTTPS API is running in us-west-2 region.
When SNS is publishing to an HTTPS endpoint, the endpoint can be anywhere on the Internet. It doesn't even need to be in AWS at all. As long as your HTTPS endpoint is accessible from the Internet and has a valid SSL certificate (matches the hostname, not expired, signed by an accredited certificate authority, not self-signed), that is all SNS will require.
The destination region and destination AWS account lose all meaningfulness in such a setup. There is no constraint, here.
If the topic is in us-east-1 then all requests sent to SNS must be sent to the us-east-1 endpoint (e.g. Subscribe or Publish) but even then, they can be sent from anywhere on the Internet.
SNS can be configured across regions via HTTPS endpoint of lambda by attaching the API Gateway to that lambda and copying the HTTPS URL of same.
After getting the HTTPS URL of the lambda may be whichever region. It may be that you just add in SNS service subscription part in SNS service by creating the subscription in the service.
After that, just publish a message. You will see entries in your Cloudwatch logs if you print an event in lambda. You will see something like "Subscribe URL". Copy that URL and paste it in the SNS service where you will be able to see "Pending on Subscription". This will work with latest amazon SNS service.
I tried and tested it to verify that this works.
Related
I have an docker image with an API that publishes provided request body to a SNS topic. Now I am able to perform this operation locally, but when I deploy this image to ECS through ECR, I get following error form AWS Go SDK(v2) after ~1 min of request initiation.
https response error StatusCode: 0, RequestID: , canceled, context canceled
I have verified following things:
ECS service (as well as EC2 as I am using EC2 launch type) has a role that grants full access to SNS
SNS access policy allows all requests from current AWS account.
I am able to publish to same topic after logging into EC2 instance.
API request has 5 min timeout.
I am using default VPC.
For the sake of experiment, I am not using HTTPS and attached security group allows all traffic on port 80. I tried everything but didn't find what's wrong. I would appreciate your great help, thanks.
quick question. I am planning to minimize use of resources by passing SNS topic as a source to EventBridge instead of passing it thru Lambda, then from EventBridge to Firehose. I tried but it is not working. Is it possible, or Lambda is the only way to make it as a source?
Its not possible. The only valid subscriptions to a SNS topic are:
For the http protocol, the (public) endpoint is a URL beginning with http://.
For the https protocol, the (public) endpoint is a URL beginning with https://.
For the email protocol, the endpoint is an email address.
For the email-json protocol, the endpoint is an email address.
For the sms protocol, the endpoint is a phone number of an SMS-enabled device.
For the sqs protocol, the endpoint is the ARN of an Amazon SQS queue.
For the application protocol, the endpoint is the EndpointArn of a mobile app and device.
For the lambda protocol, the endpoint is the ARN of an AWS Lambda function.
For the firehose protocol, the endpoint is the ARN of an Amazon Kinesis Data Firehose delivery stream.
But SNS can push directly to Firehose, so maybe just do this.
Has something changed since the last answer? Now it is possible to set aws.sns as source for an EventBridge rule (as shown in the below picture), but it does not seem to trigger the rule anyway... The question is, why do the AWS team let the users select aws.sns as source if it cannot work?
On my current project we configured forwarding of Cloudwatch alarms to Slack channel. For that we use AWS SNS topic + API Gateway which is subscribed on that topic and forwarded alarms to Slack webhook.
The issue I'm trying to solve - currently the REST resource of the mentioned API Gateway is public (it don't require any auth and is available from Internet). How can I configure API Gateway that it could be available only as SNS subscription endpoint?
You need to create the API gateway with the Endpoint type : Private
And you need to create a VPC end point for SNS to access the end point internally.
More Info: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-vpc-endpoint-policies.html
I would like to send SNS notifications to a Lambda function from one account to another exposing the lambda through and API gateway. But I'm having an Issue. I first tried with the API Gateway in the same account of the SNS topic and everything worked like a charm but when i try with a topic from other account all I got is a Bad Request Error. Do I need to configure any permission?
You need to enable permissions for the TOPIC in another account.
You can find an example in the AWS documentation, section
Allowing Any AWS Resource to Publish to a Topic
Is it at all possible to invoke an AWS service whose endpoint is in a region other than the one hosting my account?
For instance, my account is in us-west-1 and SES has been removed from that region. Can I somehow invoke the SES service from us-west-2? When creating a request to send an email I cannot seem to find a way to set the service endpoint region that does not also set the signing region.
Apparently, yes. The class EndpointConfiguration allows that.
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/client/builder/AwsClientBuilder.EndpointConfiguration.html