All Posts

AWS API Gateway provides us to develop our own RESTful APIs and trigger AWS Lambda functions upon HTTP requests. I often use this architecture in my serverless applications and developed many APIs for my clients. With the help of API Keys and Usage Plans, we can define maximum request quotas and manage request rates while sharing our API with others.

Although API keys can never be considered as a full security measure as we often store these keys in client applications calling the API, usage plans can provide us to limit the API access and be sure that usage does not exceed tresholds we define. Read more at Controlling API Usage with API Keys and Usage Plans on AWS API Gateway post.

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.

AWS Lambda allows us running code without maintaining servers and paying only for the resources allocated during the code run. In most cases, we do not need to run our Lambda function in a VPC and it is recommended not to run in a VPC in these situations as a best practice. Some of examples to these are sending emails using Amazon SES or accessing a DynamoDB table.

However, to access an RDS database in your Lambda function you have to run your function in the same VPC or in a VPC that has a peering connection to the VPC of your RDS instance. In this blog post I would like to discuss about running AWS Lambda functions in a VPC and accessing a RDS MySQL database. Read more at Running AWS Lambda Functions in a VPC and Accessing RDS post.

When you decide to distribute your content stored in your Amazon S3 bucket with Amazon CloudFront, you most probably would like to avoid your users bypassing CloudFront and accessing them directly from Amazon S3.

In this blog post, I will demonstrate how you can utilize Origin Access Identities to restrict access to your S3 bucket on your Amazon CloudFront distributions. Read more at Restricting Amazon S3 Bucket Access on CloudFront Distributions post.

If you deploy any type of application on AWS, such as a Ruby on Rails web app; then your application will generate large amounts of logs. Hence, you will need to store and monitor these logs somewhere to understand what is going on when an unexpected event occurs. A central log server may be a choice; however, Amazon CloudWatch offers an alternative way without maintaining your log servers and with lots of capabilities.

In today’s blog post, I will describe how you can start storing your application logs on Amazon CloudWatch by using a Ruby on Rails web application as an example. The same principles here would apply to other types of application logs as well. Read more at Storing and Monitoring Rails Logs on Amazon CloudWatch post.