Getting your head around any new technology stack requires a lot of research and with that, you're introduced to all the acronyms, terminology and how all its pieces fit together. The exact same happened to me when I started learning Kubernetes. One of the first questions I had, was “what's the difference between a DaemonSet and a ReplicaSet?". A ReplicaSet is probably one of the first concepts that you'll learn, cause it's such an important part of what you can achieve with Kubernetes, but shouldn't be confused with a DaemonSet; also a critical feature.
It would seem that customers of public cloud providers are just loving life right now. And I would classify myself in the same group. We’re like kids in a candy store with the flexibility that goes along with “anything-as-a-service”. We’re spinning up resources, building clusters, decoupling application functionality by adding load-balancers in-between - and all of this without the lengthy and expensive procurement process. With public clouds’ billing on a pay-as-you-go basis, reserved instances aside, this of course means that there are no upfront expenses to worry about, and companies (especially enterprises) are jumping for joy to convert their operational IT costs that the public cloud brings.
Ever needed to give a user or a group of users permission to only control the EC2 instances that you want them to control? Of course, you have! Access control is a critical aspect of managing any environment. But, if managing IAM policies in your company's AWS environment falls within your realm of responsibilities, this is something that should not be taken lightly. OK, so let's say that your company has recently hired a bunch of interns to perform some application testing for you.
Post Updated: 2019-10-08 Description: Notification via SNS Topic We recently completed an audit of a customer's AWS environment. I tend to either dive into the customer's IAM policies as the first item on the list or I leave it for last. I find that the reason behind this, for me, is it depends on the complexity of the environment. At a high-level, it's a fairly simple component (/service) to audit, so getting this out of the way first clears the ‘to-do’ list for the more complex stuff… And as for this recent audit, I worked through the customer's IAM policies as the first item on the ever-growing to-do list.
I'm a massive believer in anything automated. I look back on my career, and I'm starting to think it is ingrained in me. I've been tinkering with Excel macros, when I was writing reports in my early career, then getting into SysAdmin I wrote simple monitoring scripts to check the output of commands on remote systems and send me an email with the results. Script patching updates, and automate the roll-out of applications.
During a recent audit we did for a customer's AWS environment, I was looking for an efficient way to analyse the security profile for each IAM user, without too many clicks and navigating back and forth on the IAM console. You know, checking if MFA is enabled, when last security keys were rotated, that kind of stuff. I found a very quick and easy way to do this via the AWS CLI.
Post updated: 2019-08-21 Version2 of the lambda function available. Git repo: https://github.com/smitphilip/Ec2-Auto-StartStop It's been an interesting week… I've been getting my hands dirty with a number of new AWS tasks, as I'm part of a task-force type team that is busy developing a new product where components of it will live in AWS. This is part of a larger internal proof of concept, and in the light of cost-saving, while building our MVP, the team decided to shut down the EC2 instances while we're not working on them.