Grasping all the rules and limitations of Instance Reservations is quite challenging. This article is designed to summarise key concepts and provide hints on further investigation.
Reserving AWS Instances is a purchasing option for Amazon EC2 instances. It is a way to reduce cloud spend for applications with steady or predictable utilization. By committing to a certain amount of usage, one can receive a significant reduction in the usage rate. Reserved Instances are not physical instances, but rather a billing discount applied to the use of On-Demand Instances.
In order to achieve user traceability of admin actions in you Kubernetes cluster, it is a good idea to set up personalized accounts.
In the IAM User Traceability in AWS EKS post I was showing the specifics of aws-auth ConfigMap user and role mapping.
This post dives into OIDC integration for AWS EKS user management.
Alternatively to aws-auth it is possible to use an OpenID Connect Identity provider with AWS EKS. The diagram below illustrates this approach.
Usage of the identity provider offers huge benefits (if the users are configured to have personalised identities):
- User Traceability
- Single Sign On
Today I would like to show how to trace IAM user actions in AWS EKS Clusters, what needs to be
configured and what limitations exist. It is a good practice to have Audit log on your admin
activities to make sure that no suspicious activities are happening. Audit log helps to investigate
issues and write postmortems, and you will most probably need it for certifications like ISO 27001.
This post does not cover specific strategies for tracing and monitoring user activity, but rather
adresses the setup required to log user actions in a traceable manner.
GitLab Auto DevOps is a great tool for managing code building and delivery to Kubernetes clusters.
It introduces an opinionated way to handle Kubernetes deployments and Environment management. It is
used extensively by small and big projects, and the whole concept is designed to be scalable and
In this tutorial I would like to dive into setting up a working Auto DevOps lab to provide a quick
way to get a feeling of the Gitlab Kubernetes CI CD approach.
Sometimes I hear the words “DevOps is the new IT”. I must say that I can relate to this a lot.
In the early days, IT used to be a generic pool of people managing anything about computers, as well
as any other electronic stuff. In the modern world a similar generic placeholder exists, and it has
the same mission: close any existing gaps in team composition and staffing. The name of this
placeholder varies, people call it DevOps, Ops, Infrastructure, Admin and some other.