All Posts on Shikisoft Blog - Page 12

AWS API Gateway lets us develop our own RESTful APIs and trigger AWS Lambda functions upon HTTP requests. I often use this architecture in 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.

API keys can never be considered a complete security measure as we often store these keys in client applications calling the API. Still, usage plans can help us limit the API access and ensure that usage does not exceed the thresholds we define.

Continue reading the Controlling API Usage with API Keys and Usage Plans on AWS API Gateway blog 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.

Continue reading the AWS IAM Policy Conditions and Restricting Access by Availability Zones blog 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.

Continue reading the Running AWS Lambda Functions in a VPC and Accessing RDS blog 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.

Continue reading the Restricting Amazon S3 Bucket Access on CloudFront Distributions blog 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.

Continue reading the Storing and Monitoring Rails Logs on Amazon CloudWatch blog post.