AWS Identity and Access Management Reviews

When attempting to access Windows UNC paths from MoveIt, it will request user ID and access. For instance, if ITS-MoveIt is the local user utilized during installation, that particular user should have read, write, execute, and modify permissions on that particular path. Similarly, when creating the AWS Identity and Access Management role, we provide it to S3 bucket owners and request them to update the KMS key policies and S3 bucket policies. In the policies section, they have actions, bucket details, put bucket detail, and alter some permissions. These are all action items they will have in the AWS Identity and Access Management role.

Temporary access is not generally used with AWS Identity and Access Management. When setting up the MoveIt task to access S3 buckets, it becomes a permanent configuration where the AWS Identity and Access Management role is created and shared with S3 bucket owners. They will add the KMS key policy and update the S3 bucket policy accordingly. If there is a business reason to decommission or disable this task, they will remove or revoke that access by removing the AWS Identity and Access Management role from their S3 bucket policy.

In our company, creating users and groups is not encouraged. Everything is managed through AWS Identity and Access Management roles. As a member of the prod support team, permissions are limited to updating or creating AWS Identity and Access Management roles and restarting EC2 instances. Deletion of EC2 instances is handled by the security operations team, even if one owns that instance.

A notable issue exists in storage gateway when creating SMB file shares and AWS Identity and Access Management roles. When creating subsequent SMB file shares, the KMS key details from the first share appear by default. This requires manual updating of the KMS key through CloudShell in the AWS console, as it does not automatically update while creating AWS Identity and Access Management roles or SMB file shares.

The most valuable feature is its hybrid network capability. With MoveIt server in the cloud and some file locations on-premise, the hybrid bridge is utilized through storage gateways. While MoveIt has direct S3 connectors using access key and secret key, many companies are hesitant to share these credentials. The alternative method using AWS Identity and Access Management role provides least privilege access to S3 buckets, allowing precise control over permissions.

A significant advantage is that unlike access keys and secret keys that require regular changes every 30-90 days based on organizational policy, AWS Identity and Access Management roles, once set up, do not require periodic changes. Additionally, AWS Identity and Access Management roles are global and not restricted to specific regions, making them usable across East or West 2 regions. The least privilege access feature ensures users only have the specific permissions they need, rather than full access to entire S3 buckets.

In AWS Identity and Access Management solutions, CloudFormation tools are used to create templates. Having predefined templates available from the AWS team would be beneficial. Currently, security teams work on policies and scripts for creating generic AWS Identity and Access Management roles. If AWS could provide an option to automatically create templates based on desired access requirements, it would be extremely beneficial, especially for documentation and troubleshooting purposes.

Storage gateway creation has limitations, allowing maximum of 50 SMB file shares per gateway. While it is costly to access S3 buckets via AWS Identity and Access Management role through storage gateway, companies invest in this for enhanced data security, particularly in financial sectors where data integrity is crucial.

There is an ongoing issue where files are sometimes sent twice to S3 buckets, despite MoveIt logs showing single transmission. As a workaround, Lambda functions are implemented with a five-minute delay before processing files to downstream applications.

I have been working with AWS Identity and Access Management for approximately one and a half years.

AWS Identity and Access Management has proven to be very stable.

AWS has captured approximately 60 to 65% of the entire cloud market. Scalability in AWS is significantly easier compared to on-premise solutions. EC2 instances can be scaled up or down with a single click. The infrastructure provides good AWS support and disaster recovery capabilities with production servers running on East-1 and DR servers on West-2.

Most companies are adopting cloud-based solutions due to scalability, robustness, and flexibility. It is advisable to migrate on-premise applications to AWS as soon as possible to maintain competitive advantage, as many clients are already cloud-based.

The technical support of AWS deserves a rating of seven to eight on a scale of one to ten.

Positive

Prior to AWS Identity and Access Management, we used the tool itself to access resources via the local MoveIt user. Most software was running on on-premise solutions, and we were not utilizing any AWS services.

The initial setup of AWS Identity and Access Management is straightforward. The main consideration involves firewall configuration, checking VPCs, identifying application IP addresses, and implementing whitelisting. Once this initial setup is complete, creating AWS Identity and Access Management roles, accessing S3 buckets, and managing policies becomes straightforward.

The AWS Identity and Access Management Access Analyzer is not utilized in our implementation. The policy simulator feature is also not being used. Information about the pricing aspect of AWS Identity and Access Management solution is not available.

Okta is used for single sign-on authentication to access multiple services, including AWS console. After mobile phone verification and code authentication, the page opens automatically for AWS console access.

This solution receives a rating of 9 out of 10.

The main use cases for the AWS Identity and Access Management solution usually consist of two parts. First, when building our infrastructures, they usually consist of multiple AWS resources that reside in an AWS account, so we create IAM roles and permissions so different resources can interact with each other and have proper access.

The second use case is data access management, especially regarding cross account permissions, when the data are in the buckets in one account, and Glue tables are in one account, but the consumer is using another account and needs to have access.

What I appreciate about AWS Identity and Access Management is a complex question because to be honest, it is something I am still learning. I think that it is sometimes not always clear how to work with it, so this is not necessarily what I appreciate about it, but I think it is a matter of experience because when you have experience, it is quite intuitive.

One thing which is quite paradoxical is that the more complicated the use case, for example, cross-account access, the much easier it is to understand IAM and how it works. AWS Identity and Access Management is somewhat problematic to understand when working with one AWS account because then you do not understand why you have to put some permissions in two places, not in one. But when it comes to cross-account, a more complex case, then it becomes obvious why you do it this way.

I would say that AWS Identity and Access Management can be intuitive, and it has pretty good documentation, at least in terms of actions. These are called, for example, S3 colon, Get Object, and so on. This list of actions is very easy to find. Constructing permissions is easy and very robust; you have a lot of flexibility with IAM permissions, how you can define them, using wildcards, and you can have explicit deny, explicit allow, and different conditions that certain conditions have to be met that this IAM policy will be executed or respected.

Regarding the areas of AWS Identity and Access Management that I would to see improved or enhanced in the future, to be fair, I do not see any. I think after initial hurdles with IAM and questioning why certain approaches were taken by AWS, now I understand how they did it, so I cannot come up with any certain ideas now how it could be improved.

AWS Identity and Access Management itself is a really huge service, and of course, I could say maybe it could be made easier or smaller, not so bloated, but I do not know how they would make it. I am happy with what we have now. It might be also a matter of habit that I am fine with what we have at the moment, so I do not have any expectations from that.

I have been working with the AWS Identity and Access Management solution for approximately two years.

I have not escalated any questions to the tech support regarding the AWS Identity and Access Management solution. We have our operations enablement team who is very experienced with IAM, and they can give us answers very quickly. We never had to reach AWS tech support in order to help us with that.

Positive

For advice or recommendations I can give to other organizations considering AWS Identity and Access Management for their environment, first of all, even before IAM, they should consider using AWS Organizations and separate different domains within a company to separate AWS accounts. This gives a clear separation of domains straight from the beginning. In this situation, it is very difficult to make a mistake of sharing unwanted data with other team members because that would increase the risk of horizontal permissions to data in case of breach.

As a follow up to that, if they would have multiple AWS accounts, one for development, one for production, then for different team domains, they should try to exercise cross-account permissions with IAM right from the beginning. This makes it very easy to get the intuition of how IAM works. My two pieces of advice working with IAM or trying IAM in general at the beginning are: do not use one AWS account, but at least two, because then it is much easier to get the intuition of how IAM works.

I rate AWS Identity and Access Management an 8 out of 10.

I am familiar with most of the AWS Identity and Access Management solutions and services, including Identity and Access Management (IAM), Lambda, CI/CD pipelines, IMRDS, and database migrations. I have been working with Identity and Access Management for security purposes, managing individual authorizations, roles, and responsibilities within an organization.

The most beneficial aspect of AWS Identity and Access Management is the ability to manage security. It allows me to create users, assign permissions, and establish responsibilities for employees. The solution enables differentiation in tasks, such as managing cross-account access, setting service roles, and integrating corporate directories for temporary AWS access.

Currently, AWS Identity and Access Management needs improvement in the prevention of unauthorized access to sensitive data and models. Further enhancements are needed for cost optimization and better scalability of Identity and Access Management roles, including the integration of new AI services. The accessibility and inclusion of more AI features would greatly enhance the program.

I have been working with Identity and Access Management for about a year.

There have been some performance issues, including downtime or lagging, with clients. It was initially tough to identify the cause, yet by simplifying user management and utilizing group roles, I have managed to solve these issues.

Managing the policies and scalability of permissions was challenging for my clients, who faced issues with handling centralized permissions in multiple branches. I implemented centralized and scalable solutions to improve larger setups.

In terms of customer service, I have dealt with handling multiple client issues in a ticketing system. AWS technical support typically involves documentation and forums. Responses from AWS engineers aren't always direct, so when urgent issues occur, I manage them immediately and prioritize solutions.

Positive

Before AWS, I worked with Oracle and Microsoft SQL Server earlier in my career. For user authentication and permissions, Microsoft SQL Server was popular, and I find a comparison with AWS Identity and Access Management is apt given its robust capability in managing such tasks.

The initial setup was straightforward despite my initial confusion. Basic setup takes one to two hours, intermediate configuration takes four to eight hours, and advanced deployment one to three days, depending on the integration complexity.

I believe AWS provides significant ROI by reducing infrastructure costs and improving scalability and business agility. The use of pay-as-you-go pricing prevents additional capital expenditures and necessary scaling features for peak traffic times contribute to cost savings.

While AWS charges for its services, it offers a pay-as-you-go model which provides a flexible financial approach. Initial setups do not require significant capital expenditures, making it advantageous for organizations to utilize AWS services.

Using AWS Identity and Access Management is crucial for precise access control and security audits within a database. 

However, in scenarios involving automation or temporary access, IAM roles and identity federation alternatives may be more suitable.

I'd rate the solution nine out of ten.

As a DevOps engineer, I primarily use AWS services like EC2 instances, S3, Auto Scaling Group, CLB, Route 53, and database services. I also use KMS Key for encryption, and these are the services I use daily.

The use of AWS Identity and Access Management offers additional layers of security. By enabling multi-factor authentication (MFA) and creating user groups, we can segregate access and permissions among developers, which has significantly improved security.

One of the most valuable features is the ability to create IAM users and add them to specific user groups to manage access permissions at a group level. It also provides MFA, which adds an additional layer of security. 

The solution supports role-based access control, allowing specific roles to be attached to AWS services like EC2, enabling automatic access to resources such as S3 buckets.

Currently, the IAM solution does not allow one user to create multiple access and secret keys, which can be distributed in a diverse manner. This feature would be beneficial.

I have around four years of experience working with AWS Identity and Access Management.

The performance is very good, and I have not experienced any performance lags or issues.

The solution is scalable. We can easily add multiple users and create new roles as needed, and changes are reflected immediately.

The service is straightforward, and I haven't encountered much complexity. Therefore, I haven't needed to escalate any issues with IAM technical support.

Positive

I am currently exploring Azure. I have not worked extensively with it yet.

The initial setup was straightforward. We create the required resources or roles and can integrate them using CLI, which makes the process easy.

Pricing is a significant factor in choosing between AWS and Azure. AWS has brand value and offers numerous features, however, Azure is often chosen for cost-efficiency. The pricing and cost structure differ, impacting our choice between them.

I am currently exploring Azure.

I rate AWS Identity and Access Management ten out of ten. 

It is easy to use and a crucial service for security in AWS. Without security, deploying applications or managing users in AWS accounts would not be feasible.

I manage AWS Identity and Access Management. I create users and control permissions so that developers in my organization can use specific services like Lambda, S3 and EC2 when needed. This ensures they have access to the necessary tools while restricting permissions to only those services required, enhancing our security.

AWS Identity and Access Management enhances security measures, allowing only authorized individuals to perform specific tasks. It also improves cost management, as only necessary users access certain services, preventing unnecessary spend on unused services. The role-based access control is instrumental in managing access to critical service features.

AWS Identity and Access Management has an intuitive user interface that is simple to use. Its role-based access control enhances security by allowing me to assign specific permissions to users, which helps in managing access and maintaining cost control. The ability to reset passwords at any time further strengthens our security posture.

The user activity tracking in AWS Identity and Access Management should be enhanced to provide detailed descriptions of user activities. The current IAM role does not track specific service usage sufficiently. 

Additionally, there's a limitation on the number of policies attached to users; having no limits could enhance flexibility.

For the past year, I have been actively using AWS Identity and Access Management.

AWS Identity and Access Management is very stable. I have not faced any major issues besides changes in the user interface, which occur frequently. Familiarity with the interface changes is necessary to maintain efficiency.

So far, I find AWS Identity and Access Management scalable - aside from the limitation on the number of policies that can be attached to a user. It fits well with our current organizational size requirements.

I have not explored tech support for AWS Identity and Access Management, however, I have used tech support for other AWS services. It is a paid service, not available from AWS Identity and Access Management specifically.

Neutral

AWS Identity and Access Management is the only identity and access management solution I have used.

The implementation process was straightforward. A colleague had already set it up before I took over, so my role involves managing users and permissions, which I found easy due to the intuitive user interface.

AWS Identity and Access Management ensures security and allows for scalable application deployment. However, the costs are high, and its inability to provide detailed user activity information is a drawback.

The pricing is included in our monthly AWS billing. While it offers good value for money, a reduction in costs would be appreciated by any organization.

I would definitely recommend AWS Identity and Access Management but caution that it may require more effort to manage with large numbers of users. For organizations with fewer users like mine, it is manageable, albeit potentially cumbersome with larger numbers. 

On a scale of one to ten, I give it a seven.

Positive

I am working with Identity and Access Management. We have a team of 30 people, and we need to provide some developer access, quality access, manager access, and team access. Whenever we need to create any infrastructure using the console, we create it using access.

AWS IAM is useful since it restricts unauthorized use of the AWS console. For example, if a new member joins my team, only that person can access specific services. IAM helps manage compliance-related challenges by ensuring that all EC2 machines are working fine, addressing security issues raised by the security team, and making sure that the compliance report is up to date.

Identity and Access Management is a very useful service because it allows us to restrict unauthorized use of the AWS console. For example, if a new member joins my team, only that person can access specific services. 

We have monthly security checks to ensure access is provided only to authorized users. IAM enables us to save time with features like OTP-based access and temporary access concepts.

To manage IAM more effectively, permissions could be set for specific groups. For instance, if we have different accounts, we can set permissions for specific people. Workload management could be improved by providing temporary access.

I have been working with AWS IAM for the last two years.

IAM is a very useful service for our security needs, and we have not faced any performance issues with it.

There are no scalability issues with IAM. AWS has not faced any scalability issues, with IAM serving as a security feature, similar to a password.

Setting up IAM is straightforward and can be done within an hour for one security policy against an EC2 machine. It can be configured via the console or through code using Terraform and offers multi-factor authentication and OTP-based access.

In my project, forty people are responsible for managing IAM and ensuring security.

AWS IAM helps save much time once the initial setup issues are resolved. It provides automation for granting access to developers and enhances efficiency through features like OTP-based access.

IAM is free to use and does not incur any associated costs. The IAM policies come by default when creating any server, such as EC2.

I recommend using IAM because it is free, can manage unauthorized access, and is easy to install. Before using IAM, test with temporary security challenges or credentials, like 12-hour or 24-hour access before proceeding to full access.

I used AWS Identity and Access Management for creating, modifying, and deleting users and integrating with one or more other directories. It is used to synchronize with other directories and create new identities for users who need specialized access to organizational tools. 

Additionally, while creating users, we provide specific permissions.

AWS Identity and Access Management allows for creating, modifying, and deleting users or integrating with directories. Identity management can create new identities for users needing access to organizational tools. Specific permissions can be given to users, allowing tailored access to instances and S3 buckets. The use of MFA provides added security for user logins.

I would like to see scalability improvements in AWS Identity and Access Management, such as better integration with existing systems and applications. It would also be helpful to enhance features like Role-Based Access Control, auto-scaling, and the ability to handle higher user demands better.

I have two years of experience working with AWS Identity and Access Management.

During normal user operations, some instability issues were encountered due to random PC problems. AWS Identity and Access Management is designed to keep networks secure by ensuring only authorized users can access necessary data.

Scalability improvements are needed, especially concerning auto-scaling and handling user demands. The system's scalability could be enhanced to support larger organizations and better integrate with existing applications.

I have not had the opportunity to deal with AWS technical support directly. However, if there are issues, my responsibilities include acknowledging them and reviewing the nature of the problems.

Positive

In my organization, everything was stable with AWS, and I have not had the opportunity to work with other identity and access management solutions.

I do not know about the pricing or licensing cost of AWS Identity and Access Management. Cost depends on customer requirements, such as instance type and memory usage.

From my experience, AWS Identity and Access Management is a strong solution. It manages users and roles efficiently and provides necessary access permissions. I recommend it to those looking for an identity management solution, as it involves human users accessing workloads with temporary credentials.

I'd rate the solution eight out of ten.

We mainly use Identity and Access Management to grant access policies to our server. It allows us to create individual user accounts with access permissions and manage them in groups. We also create separate roles and policies for policy-based access. This solution helps secure access through multi-factor authentication during login.

Identity and Access Management ensures the right group of people get access to appropriate environments, like development and testing. It also prevents access to personally identifiable information, enhancing compliance with data protection regulations.

Identity and Access Management allows organizing policy users into groups and defining policies and roles. It ensures the appropriate access is given to specific groups, such as those needing access to development or test environments. Identity and Access Management also prevents access to personally identifiable information, ensuring secure access to stored data.

The documentation and policies could be more straightforward. It is currently a bit confusing on how to grant different policy-based access, which could be simplified.

I have been using Identity and Access Management for six years.

In terms of stability, I would rate it ten out of ten. We have not faced any significant issues affecting access to the server.

In terms of scalability, I would rate it ten out of ten. We utilized Cognito user pools, making it easy to export user sets and migrate them. The AWS CLI command facilitated migration to Google.

I haven't had to contact technical support for Identity and Access Management issues, but I have a good impression of the tech support overall.

Positive

Before Identity and Access Management, I did not use another solution for these use cases.

The initial setup process was rated seven out of ten in terms of easiness. It took almost a day for deployment as part of a combined strategy, integrating with other solutions.

Deployment required one person from the DevOps team to manage it.

We were able to offer the product as a SaaS product, limiting access to specific authorized individuals, adding value to the organization.

I would rate the pricing five out of ten. While I don't have a detailed view on the cost part, it seems to be value for money given the functionalities.

Before choosing Identity and Access Management, I did not evaluate other options.

For new users, it's recommended to refer to the documentation for better understanding. Contacting tech support can also help if you face any issues. I rate the overall solution nine out of ten.

I am a cloud engineer and DevOps engineer. I mainly use AWS Identity and Access Management (IAM) for setting some policies for developers, such as granting limited access to specific resources as part of managing permissions. 

Additionally, roles, policy management, and monitoring and logging are essential, and integration with services like EC2, Lambda, S3, and others.

AWS IAM centralizes security management and helps us manage all permissions in a centralized way, allowing for temporary credentials and multi-factor authentication, enhancing user security.

AWS IAM is beneficial as it provides standard access and identity management policies and roles for monitoring and logging. It integrates IAM with other AWS services, which simplifies permission management.

AWS IAM could be improved by providing a graphical user interface which would simplify permissions management, making it easier for beginners to quickly understand and manage permissions.

I have been working with AWS CloudFormation for over two years, and I have used AWS IAM for approximately four plus years.

AWS IAM is stable with no performance issues. When rules are set for users or groups, they reflect instantly.

I have not faced any scalability issues with AWS IAM.

I prefer Stack Overflow and Googling for support and currently use QuestInfo GPT, so I have not asked any questions to AWS Access support.

The initial setup was a bit complex and challenging, however, over time and with experience, it becomes easier for users to manage IAM policies.

I definitely recommend AWS IAM as it provides 750 free hours for practice, which is beneficial, especially considering the cost for beginners.

I'd rate the solution ten out of ten.