AWS Cognito using another region to send SMS - amazon-web-services

I have got an interesting issue with Cognito Userpool in AWS. I have created user pool for managing Users' signup/signin process in Mumbai region. Cognito was able to send otp via sms during signup process successfully from Mumbai region until we hit service limit exception. Hence we requested for service limit increase via support case and they increased to amount we requested. Soon after this, all the SMSes are starting to originate from Singapore region even thought cognito user pool resides in Mumbai region. I created a support case with AWS, unfortunately they asked to go with Premium plan to help on this. I have read about this issue at multiple forums and aws doesnt seem to be giving right answer. I can simply increase service limit in Singapore region and my issue will be resolved. But I believe that issue is with AWS and they had to fix it. Anyone else faced such situation and what was your approach ?

SMS messages from Amazon Cognito user pools are routed through Amazon SNS in the same region unless noted in the following table.
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-email-phone-verification.html
There is no way to change this internal mapping. Ideally the easiest way is to increase the SNS spending limit in the region Cognito is using.
Another option is to use this new feature:
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-custom-sms-sender.html
It is a new Lambda trigger which is not available in the console but can be added in the CLI. You could use the AWS SDK to send the CODEs via SNS in the given region. I have not done this myself but should satisfy your usecase.

Related

Is it possible to integrate the AWS cognito hosted UI with the Amazon Pinpoint for analytics?

We are looking for a way to integrate the AWS Cognito hosted UI with the Amazon Pinpoint for analytics. We have also set up the Pinpoint for Cognito with the corresponding region, but nothing shows up in the dashboard.
There is already an integration present for AWS congnito and Pinpoint.
Although, your question is a little bit vague. Because you have not added other details.
Till which part you are done.
Still, let me add some some steps, let's see if it helps you.
One possible reason could be wrong mapping of regions in aws.
Please use this link to check mapping:
AWS Region mapping for cognito and Pinpoint
Sign in to the Amazon Cognito console
.
In the navigation pane, Manage User Pools, and choose the user pool you want to edit.
Choose the Analytics tab.
Choose Add analytics and campaigns.
Choose a Cognito app client from the list.
To map your Amazon Cognito app to an Amazon Pinpoint project, choose
the Amazon Pinpoint project from the list.
Choose Share user attribute data with Amazon Pinpoint if you want Amazon Cognito to send email addresses and phone numbers to Amazon Pinpoint in order to create additional endpoints for users.

How can I be notified [eg via email] for any change in my AWS account?

I have an AWS account that use multiple devs and teams [dev/qa/mobile].
I would like to be notified when any change takes place in my AWS account.
For example a dev launches a new instance , or a new open port is added in a security group etc and he forgets to announce it to me or the rest of the team.
I want to be fully informed for these changes in order to apply specific architecture and/or security and people tend to mess with them.
Is there any dashboard or service inside AWS that I can customise it?
Someone suggested that I should take a look in CloudTrail.
Has anyone done something like this?
The easiest way to go is to use cloudtrail with cloudwatch logs. In AWS FAQ:
Q:What are the benefits of CloudTrail integration with CloudWatch Logs?
This integration enables you to receive SNS notifications of API activity captured by CloudTrail. For example, you can create CloudWatch alarms to monitor API calls that create, modify and delete Security Groups and Network ACL’s. For examples, go to the examples section of the user guide.
Based on SNS, you can then send email through SES
I think the easier way is to use Amazon Cloudtrail service.
Cloudtrail logs any API call which is made on your AWS account. Every operation done on AWS is and API call (including instances operations as you have requested)
Here you can find more information about it
http://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-cloudtrail-to-send-notifications.html
I hope this helps somehow.
You can find logs of your AWS account in S3,
Find below path in S3:
s3://security-logging/AWS_/AWSLogs/AWS Account no./CloudTrail/your region/year
You can also integrate CloudTrail with SQS to send notifications.

Create SNS Topic As Cognito Identity

Playing around with AWS in Golang.
At the moment I use the AWS SDK front-end with Facebook as a Credentials Provider to create Identities in AWS Cognito. This works great.
I use SNS to send Push Notifications to iOS and Android, this also works great.
But I read that SNS only allows 3000 topics per User. If I understand how Cognito and SNS work (and with what I see in logs/dashboard) All Topics are created by the Role that the Cognito Identities assume. So they are all created by the same "User". So I will hit 3000 very quickly with the service in mind.
Ideally I would send AWS Credentials to my Golang back-end and there I would create Topics per Identity and confirm subscriptions.
Is it possible to create Topics per Cognito Identity, make the individual Identities the Owner of the Topic?
If so, is this a specific API call?
Or is this something that has to be set with a specific Role?
AWS doesn't typically limit things by "user" like that. The 3,000 SNS topics limit is per AWS account. This is a soft limit. You can fill out a request to have the limit raised.
Also, I'm not sure 3,000 is the default limit anymore. I can't seem to find that in any of the official documentation at this time. This is the only thing I can find, which lists a limit of 100,000 SNS topics: http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_sns

Amazon SES Verified Identities Limit

I'm using Amazon SES and found that there's a limit on verifying identities i.e. 1000 emails (senders) per account.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/limits.html#limits-sender-recipient
My application is sending around million emails everyday, and I am creating email identites, but now I am coming near to 1000.
What's the best work around to solve this issue? Or is there any chance Amazon will increase it?
Amazon will not increase that for now. You can:
1.- Use 1.000 Verified Senders for each SES region, which totals: 3.000, the more regions Amazon adds to SES, the more Verified Senders you'll have. Today Amazon has SES available on the following regions: Virginia, Oregon, Ireland.
2.- Create another Amazon AWS account, so you have 3.000 more Verified Senders available.
3.- Best approach, not yet available from AWS: create separate AWS accounts for each of your users using AWS API, and then create a user for that AWS account with a Policy which enables that user to use the SES API.
Be careful when allowing so many senders use your SES account. If any of them does malpractice, Amazon AWS team, will right away cancel your AWS account or limit your SES sending capabilities.
Don't do this!
First of all, SES is designed to be a "few senders to many recipients" service, not a "many (untrusted) senders to many recipients".
Second, sending emails on behalf of others is not a good practice; instead, use your own verified sender and add the user as a Reply-To: address. In this way, hitting the Reply will send the email to the correct person and you can actually use email signing (DKIM, etc.).
For example:
From: <mailer#yourdomain.com>
Reply-To: <user#domain.org>
Subject: ...
Not sure if sendgrid sets a limitation on sender addresses, I couldn't find anything on any limits for that. They may be a good alternative for your use case. https://sendgrid.com/docs/API_Reference/Marketing_Emails_API/sender_address.html

How to get notifications of AWS VPC outages

Our CTO received the following notification email from AWS:
You're receiving this message because you have at least one VPN Connection in the us-west-1 region. On May 27, 2014 at 16:00 UTC, we
will be performing 4 hours of emergent maintenance on the VPN endpoint
that has IP address 204.246.163.95. This will affect the following VPN
Connections of yours:
[id's expurgated]
If you have configured your VPN router to use both tunnels, then your
VPN Connection to VPC will switch over to the other tunnel for the
duration of the maintenance. If you have not configured your VPN
router to use both tunnels, then your VPN Connection to VPC will be
interrupted for the duration of the maintenance. We encourage you to
configure... etc. etc. etc.
Our CTO got this message because he was the one that originally set up the AWS account. He is not, however, the appropriate person to receive this message. I've done some rooting around AWS, and I have not yet figured out how to get these specific kinds of messages routed to the appropriate person. It's a little annoying that every single different AWS service has different ways of doing things... [sigh]. Anyway, can someone tell me how to specify which IAM user or group gets outage notifications or, if indeed, this is possible?
Note that I'm looking for a CLI-style solution that can be called from the AWS SDK. Get me in the ballpark, and I can make the appropriate calls through the .Net API.
AWS announced the Personal Health Dashboard in Dec. 2016.
As part of this service, you can now use Cloudwatch Events to subscribe to these notices.
So to get an email whenever something in your account needs attention:
Create an SNS topic
Add the email as a subscription to the topic
From the cloudwatch console, select Events, then add a rule
Pick event pattern, service name should be Health, and pick appropriate event type
Add your SNS topic to the list of targets
Ensure that the root credentials on the AWS Account have the correct contact details. This is the login that has full access on the Account (as opposed to an Identity and Access Management (IAM) login).
It is a good idea to keep the account contact details current, in case there are any issues with your Account (eg regaining access after forgetting a password, or receiving such notifications).