I am trying to set up different user groups in the AWS user pool and grant them access to AWS resources based on the group they belong to I have two options.
Create two user groups in the user pool and associate respective roles to it. I can assume role using STS and get access to given AWS resources, something like this.
https://aws.amazon.com/premiumsupport/knowledge-center/cognito-user-pool-group/
Another option is two use Amazon Identity Pool for the same which internally uses STS.
what advantages I will get if I use the identity pool, given that sts is free and identify pool has a price associated with it.
I am confused about what should be the right approach to solve it?
Cognito is prices based on your monthly active users. Since you are going to be using user pool in both cases you will be charged the same regardless of what approach you take. But the first 50,000 monthly active users are free so you might get away with it on a smaller application.
Since pricing isn't a concern, you should just go with Identity pool since they have been made to work well with each other.
Related
I want my website to offer premium services to authenticated Cognito users, and so I want to be able to bill each user for the AWS resources they use. How can I track my monthly AWS spend back to the individual Cognito user? I see that I can assign cost allocation tags to user pools, but I'm looking for something at the user level, not the user pool level. I also see that I can use "Attribute-Based Access Control" in an identity pool, and that I can get tags called "Tag key for Principal" that can be referenced in IAM policies, but I'm not seeing a way to get those tags to map to cost allocation tags in the billing console.
The main resources I'm thinking about tracking initially are S3 storage and Lambda compute.
The only option I know of is the following:
https://aws.amazon.com/es/aws-cost-management/aws-cost-and-usage-reporting/
It may be what you need.
I am reading about multi-region architecture considerations.
Our reasons for moving to a multi-region architecture are pretty much the same as everyone else's:
Reducing latency for customers that are in different continents (EU, US, Asia, Africa)
Being in compliance with their data storage needs
Enable regional failover
We will be using Cognito pools and dynamo DB for data storage. Global Cognito pools do not seem to be a thing as Global DynamoDB tables. For a multi-tenant system SAAS system with tenants in different continents, Should the user pool be generated per region or per tenant? In this video here, https://www.youtube.com/watch?v=kmVUbngCyOw&feature=emb_logo&ab_channel=AmazonWebServices , it is recommended to have a pool per tenant. I fail to see many advantages for it though.
Is it instead a good idea to have a user pool per region instead?
The video also suggests having identity pools in addition to user pools. Why should that be the case in a multi-tenant system?
if I was to ensure data residency in the same region as the tenants in dynamodb as well, how should that be handled? and how should active-active architecture
We also need to host the application URLs like tenant1.companydomain.com for all of the tenants. what's the best way to go about it?
This question is too large, but anyway.
1. Reducing Latency
Unless you are calling Cognito APIs often Authentication is really the main concern here, but if you are using a long lived refresh token they shouldn't have to authenticate all the time so it wont be a massive problem. However a bigger problem is if you only use the one pool, you will have to consider that you sometimes need some Cognito Integration to be in the same region, such as a Cognito Authorizer on an API gateway. But you could write your own Lambda Authorizer to get around this.
2. Being in compliance with their data storage needs
This may force your hand in the User Pool decision, although you can always do the option of keeping your identity and your details in separate storage, making use of Lambda Triggers in the User Pool to sync data.
3. regional failover
I don't understand this in regards to your question about how many User Pools to use. If you use one in each region, then you will need to duplicate it in another region if you wanted to add your own failover capability. If you had only 1 User Pool you would have to duplicate only 1. I've never heard of anybody duplicating a User Pool to another region, this conflicts with what you wanted in 2.. If you've used integrations too, you cannot default to another User Pool you'd have to default to a whole new instance of the website, not just the User Pool. You'd have to also create your own Triggers which would do this for you.
Should the user pool be generated per region or per tenant?
This honestly is a large question in itself, we build a multi-tenant SAAS platform and I can honestly say User Pool per tenant would be a nightmare. 1 User Pool is easiest (as for example with the API GW Integration you cannot select multi user pools). You can use an app client per tenant and customize the signin for that tenant and give each tenant their own sub-domain.
4. Is it instead a good idea to have a user pool per region instead?
Other more meaningful questions are maybe? Do I want users to have the same identity in different regions? Do I want a user to be able to use more than on region? etc. Think about different websites that have this feature. For example Amazon you have a global identity and you can switch your store you are visiting, you need to specify requirements.
5. The video
Sorry not going to watch the video, but you can have an identity pool select permissions from the token (i.e. the group permissions for that user in Cognito). That covers 99% of use cases start from there.
6. if I was to ensure data residency...
Out of the box this is how the cloud is unless you specify a global resource everything is per region so you do nothing. You cannot have both data residency and regional failover at the same time.
I have an AWS account. There are multiple users being managed by IaM service.
Each user has access key and is at liberty to perform various actions such as files upload.
Is there any means to monitor cloud costs and usage by user?
I utilize cost explorer AWS service and intend filtering and grouping costs/usages by user. Unfortunately haven't come up with any way to nail it in the most graceful way.
One common way to do this is to use Cost Allocation Tags.
You can define these tags and enforce them, e.g. using AWS Config and/or tag policies.
AWS does not track costs by user.
When an IAM User makes a request to AWS to create resources (eg an EC2 instance or an RDS database), the user's permissions are checked to confirm that they are permitted to make that API call. If they are permitted, then the API call is allowed and the resources are created.
Resources created in an AWS Account are owned by the AWS Account, not an individual user. Thus, there is no relationship between resources and the credentials used to create the resource.
The closest link between users and resources would be the audit trail of API calls kept by AWS CloudTrail. CloudTrail stores information about the API call and the user that made the call, but it does not directly link to the resources that were created. This would take some effort to back-trace resources to users.
Typically, cost management is done by tagging resources. Such tags would identify cost centers or project codes that can be used to charge-back the cost of systems. Enforcing tagging is difficult. Only some services allow tagging to be enforced when services are launched. For others, it would be a matter of identifying resources that do not meet tagging requirements. See: Using AWS Config Rules to Manage Resource Tag Compliance | Sumo Logic
You can monitor every IAM user action through cloud trails logs. So you could imagine a solution based on those logs to calculate the cost of all actions from one IAM user
I allways recomend to have an account per user type or subscription type in your system (free or premium for exmaple). Depending on the user who use your services, you will login that use with this account. Then, using the AWS Cost Categories, you can to see the cost by users type, and then, knowing your number of users for each tipe or subscription you could know your price per user.
I am wanting to share a Lambda Layer with someone and by doing so I will give them it's ARN which will contain my AWS accounts 12 digit ID.
Is there any risk associated with this?
I'm assuming you trust the party you're sharing the Lamda ARN with.
The risk of sharing your account ID is limited to what permissions you have granted for services.
The AWS Account Identifiers documentation states that:
The AWS account ID is a 12-digit number, such as 123456789012, that you use to construct Amazon Resource Names (ARNs). When you refer to resources, such as an IAM user or an Glacier vault, the account ID distinguishes your resources from resources in other AWS accounts.
Someone you've shared the account ID with could manipulate ARN's but without permission to access that resource there is no issue.
Bottom line, if you have tight controls that limit external access to resources (in your case the Lambda layer) you should be fine.
While it is generally not recommended to publish your Account ID (eg in StackOverflow questions), it is not terrible if other people know it.
The security of your AWS services is tied to credentials, not the account ID.
Knowing your account ID simply makes it easier for attacks to attempt to probe your account, especially if they know some of the services you are using. For example, they could look for publicly accessible Amazon SQS queues, knowing that they belong to your account.
If you are intentionally working with other people who wish to tie-in to your account, you can certainly share the ARN.
I am in the early stages of writing an AWS app for our users that will run our research algorithms using their AWS resources. For example, our code will need to spin up EC2 instances running our 'worker' app, access RDS databases, and create access SQS queues. The AWS Java SDK examples (we are writing this in Java) use a AwsCredentials.properties file to store the Access Key ID and Secret Access Key, which is fine for examples, but obviously not acceptable for our users, who are would be in essence giving us access to all their resources. What is a clean way to go about running our system on their behalf? I discovered AWS Identity and Access Management (IAM) which seems to be for this purpose (I haven't got my head around it yet), esp. Cross-account access between AWS accounts. This post makes it sound straightforward:
Use the amazon IAM service to create a set of keys that only has
permission to perform the tasks that you require for your script.
http://aws.amazon.com/iam/
However, other posts (e.g., Within IAM, can I restrict a group of users to access/launch/terminate only certain EC2 AMIs or instances?) suggest there are limitations to using IAM with EC2 in particular.
Any advice would be really helpful!
The key limitation with regards to RDS and EC2 is that while you can restrict access to certain API actions there are no resource level constraints. For example with an IAM S3 policy you can restrict a user to only being able to perform certain actions on certain buckets. You can write a policy for EC2 that says that user is allowed to stop instances, but not one that says you can only stop certain instances.
Another option is for them to provide you with temporary credentials via the Security Token Service. Another variant on that is to use the new IAM roles service. With this an instance has a set of policies associated with it. You don't need to provide an AwsCredentials.proprties file because the SDK can fetch credentials from the metadata service.
Finally one last option might be consolidated billing. If the reason you are using their AWS resources is just because of the billing, then setup a new account which is billed from their account. The accounts are isolated from each other so you can't for example delete their instances by accident. Equally you can't access their RDS snapshots and things like that (access to an RDS instance via mysql (as opposed to the AWS api) would depend on the instance's security group). You can of course combine this with the previous options - they could provide you with credentials that only allow you to perform certain actions within that isolated account.