AWS Identity & Access Management (IAM) Posts

AWS Identity and Access Management, or IAM, is a critical AWS component controlling access to your AWS resources. The IAM user and the IAM role are two crucial IAM concepts with similar features. So, sometimes, it can be difficult to tell the difference between them. In this post, we will discuss the similarities between AWS IAM users and IAM roles and how they differ. Read more at AWS IAM Users vs. Roles: Which to access your AWS resources? post.

You started using AWS CodeCommit as your remote private Git repository and liked its cost-effective, easy to manage, and serverless nature. Now you would like to invite other developers to your project and collaborate with them. How can you achieve this?

In this post, I will talk about the steps you need to make your repository accessible to other developers. Let’s start!

Where do you keep your DB credentials in your AWS Lambda functions that you use to access your Amazon RDS databases? Hardcoded? No! Environment variables? Well, you might be using AWS Secrets Manager, right? It would be great! But did you know that you can also use the IAM role of your AWS Lambda function and its temporary credentials to do this?

Yes, there are different ways to manage your database credentials in your AWS Lambda functions. In this post, I will talk about one of the most secure methods, using IAM authentication of Amazon RDS, with an example of an AWS Lambda function developed in Python. I will use an Amazon RDS - MySQL DB instance, but IAM authentication is also supported on PostgreSQL DB instances as well. Read more at AWS Lambda IAM Authentication for Amazon RDS With Python: Secure, But Limited post.

If you recall, in a previous blog post I discussed AWS Step Functions as a great service for orchestrating your AWS Lambda functions by giving an example. Today, I will show you how you can integrate your API Gateway resource methods with your AWS Step Functions state machines so that you can trigger your state machines with API calls.

Actually the benefits are obvious. Instead of serving our Lambda functions as separate endpoints and orchestrating which one to call and when in our front end; we can use a single endpoint and pass all logic to the back end. Then our back end, in this case our state machine, will execute the functions in sequential or parallel. This method especially suits well to cases when all these function calls are necessary to complete a single business action.

AWS Identity and Access Management (IAM) is the foundation service to manage security of your resources on AWS. Custom IAM policies feature allows us to define our own policies according to our needs instead of using AWS Managed Policies. Normally, it is a best practice to use managed policies whenever possible, because AWS updates them automatically when a new service is launched. However, assigning least privileges is the most important principle in terms of security and sometimes it is better to prepare custom policies.

Conditions in IAM policies allow us to tailor permissions and grant access to users if the resource meets specific conditions. In this post, I will show you how to use conditions in an IAM policy to grant users permissions to start/stop EC2 instances if the instance is in a specific availability zone. Read more at AWS IAM Policy Conditions and Restricting Access by Availability Zones post.