Welcome to the first in a series of blog posts about AWS! Throughout this series, I’ll be covering various AWS topics as I prepare for the AWS Solutions Architect exam. I thought what better place to start than with one of the most fundamental steps when beginning with AWS: creating an account. In this post, I’ll discuss the root user that’s created with your AWS account and how it differs from IAM users. ...
In the previous post, we talked briefly about EC2. In this post, we’ll explore it in a bit more detail. We’ll launch an instance and use it to run an nginx web server which will be accessible from anywhere using a URL. So without further ado, let’s get started :) Search for “EC2” in the AWS search bar. From there click the “Launch Instance” button. Now you would see a screen to choose an AMI. AMIs (Amazon Machine Images) are nothing but virtual machine images. For this blog, we’re going to select the “Amazon Linux 2 AMI (HVM), SSD Volume Type” with the x86 option. On the “Instance Type” screen we select the kind of hardware we want to be allocated to our VM. This is basically like choosing the configuration (CPU, RAM, etc) for our computer which would act as the server. Let’s go with “t2.micro” here. From here click on “Review and Launch” and finally on the next screen click on “Launch”. ...
This article is going to introduce you to the Infrastructure as a Service side of AWS. We’ll start from the basics of how accounts in AWS work and cover some fundamentals in this article. Then in the next post, we’re going to do something a bit more hands-on and see EC2 and S3 in action. AWS Accounts? So let’s talk a bit about AWS accounts first. If you just have a username and password for your account then you have what is called a root account. If you were sent a username, password, account id, and/or a special link to log in then you have an IAM user account. ...
Hey folks, in this post we’ll see how you can use Kyverno to enforce some best practices for your EKS cluster. For those not familiar, Kyverno is a Kubernetes native policy engine that aims to make your life easy when managing clusters. To know more you can read my previous post on Kyverno where we discuss the project and its internals in detail. With that out of the way, let’s get started! EKS best practices recommend the use of separate IAM roles for different use cases. For example, for dev and prod environments you should prefer to have separate IAM roles which can configure objects in those environments. Now the problem that arises with this is how do you make sure that the IAM role which has permission for the dev environment doesn’t accidentally create objects in the production environment? If you have the roles configured properly it would obviously not allow this to happen but with Kyverno not only can you fool-proof this but also make sure that if someone does try this, then it gets reported. ...