DEV Community: socraDrk

Troubleshooting EKS with MCP: The Good, the Bad, and the Ugly (plus the Setup)

socraDrk — Tue, 26 Aug 2025 11:12:40 +0000

As part of our sessions to develop the skills of a one-person army with AI tools, we began exploring how to integrate their use into our daily tasks.

One of the tasks that might be simple, but takes time is to troubleshoot issues during the deployment of our applications. In some of our projects, we use Kubernetes as the platform to deploy them. In dev environments, it's not uncommon for dev teams to struggle with deploying their applications. Either they are new to the topic, lack some information, or have a typo in the code, so we can have a flawless pipeline using GitOps, but the human factor still persists, and one way to help the teams is to also provide the tools to help them do the troubleshooting.

The Setup

Since we cannot share an actual setup from one of the projects, we tested the efficiency of solving issues in a Kubernetes cluster as an example. The complete setup is the following:

EKS cluster with a sample web application
- Deployed via eksctl
- 3-Tier Web application deployed with hidden errors
Local environment with
- Q Developer, using Claude Sonnet 4
- EKS MCP server
- Kubectl and eksctl

The references used for the setup will be at the end of the post, but as a summary, these steps were done:

# Prerequisites: Q Developer, MCP servers, uv, kubectl and AWS CLI installed 
# References at the end of the post, as summary for Q:
## [Download Amazon Q for command line for Linux AppImage](https://desktop-release.q.us-east-1.amazonaws.com/latest/amazon-q.appimage)
chmod +x amazon-q.appimage
./amazon-q.appimage
## Authenticate with Builder ID, or with IAM Identity Center using the start URL given to you by your account administrator

# MCP Servers configuration
pip install awslabs.aws-api-mcp-server

vim ~/.aws/amazonq/mcp.json
### Copy and paste content below
{
  "mcpServers": {
    "awslabs.aws-api-mcp-server": {
      "command": "python",
      "args": [
        "-m",
        "awslabs.aws_api_mcp_server.server"
      ],
      "env": {
        "AWS_REGION": "YOUR_REGION"
      },
      "disabled": false,
      "autoApprove": []
    },
    "awslabs.eks-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest",
        "--allow-write",
        "--allow-sensitive-data-access"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    }
  }
}


# AWS CLI configuration
aws config

## To store credentials:
vim ~/.aws/credentials
### Copy paste the credentials
[default]
aws_access_key_id=SHALALA
aws_secret_access_key=shalalala
aws_session_token=token


# Install eksctl
cd ~
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo install -m 0755 /tmp/eksctl /usr/local/bin && rm /tmp/eksctl


# Deploy K8s cluster
export AWS_REGION=eu-west-1
export EKS_CLUSTER_NAME=eks-workshop
cat cluster.yaml | envsubst | eksctl create cluster -f -

# Kubectl configuration
aws eks update-kubeconfig --name $EKS_CLUSTER_NAME

# Once EKS is ready, deploy application. On this case, kubernetes_xD has some hidden issues in it.
kubectl apply -f kubernetes_xD.yaml
kubectl wait --for=condition=available deployments --all

# Validating application is working
## Get load balancer URL
kubectl get svc ui
## Access it via browser (port 80), example:
http://a7a2821a812cb40daa48ab4cca3e4179-191623826.eu-west-1.elb.amazonaws.com:80

## Initially the above page will throw a 500 Error

# To redeployed the components via YAML
kubectl apply -f kubernetes_xD.yaml

# To delete the components
kubectl delete -f kubernetes_xD.yaml

# REMEMEBR!!!!!
# Once you are finished, destroy the cluster to avoid unnecessary costs 
eksctl delete cluster $EKS_CLUSTER_NAME --wait

After this, we had an amazing EKS cluster with several crashed pods. Great, now how do we fix this, while we have tons of meetings in parallel in the project? The answer is to delegate to the AI and check and approve the proposed fixes.

The Good

The summary provided by Q Developer regarding our environment's status is actually good. It took around 5 minutes to check all namespaces and detect what components were failing.

The prompt for this feels natural to write. Instead of asking to fix everything from the beginning, we started with a request for a summary, focusing on the fixes later.

After that, given the list of issues provided by Q, we started fixing one by one, and that's where the "problems started".

The Bad

Assumptions are a risk! Without much context, we observed that the tools accept the metadata written in the descriptions as truth, which leads to their own assumptions, some of which are beneficial, while others are not. The trick is in the prompt we give to clarify those assumptions.

As an example:
One of the pods was failing because, as an environment variable, we set up (on purpose for testing) an ActiveMQ reference variable, while the platform is using RabbitMQ.

And then, instead of using the second, it assumed that what needs to be done is to deploy ActiveMQ for the application. And as mentioned before, this was avoided and solved by providing the correct context in the prompt.

The Ugly

While trying to fix the issue, several requests were made that might not be necessary. A human would be able to detect such cases faster, or even the tool, once faced with a similar issue, learn from it and in the subsequent request not make the same mistake again.

As an example:
While solving issue one, it detected that the pod was having a problem. It first checked the pod with a get command, to later understand that a describe command was needed. On the second issue, the same applied. For the third time, I expected the describe command to be the first one tried, but it still kept the process, even though the get command didn't provide anything useful.

This might be because it still needs more iterations and use on the tasks for the learning to happen, but still, it's something to consider: It will take time to adjust to the current context of the project.

Final Thoughts

Even if this sample scenario is quite basic, we hope it will help other teams to be onboarded on this new way of doing troubleshooting.

As AI continues to evolve, now is the perfect time to become familiar with it and explore how it can support our projects.

By being careful with the information we share with it, and also, considering the kind of setup we use (some projects might prefer to use their own models, rather than use the ones provided by Bedrock, for example), it can give us a lot of advantages, like

Saving a lot of time that we can use for other tasks (like designing, supervising, and meetings)
Automate tasks and focus on what really brings value to our project

One of the following steps is this second point, where the use of AI Agents will be the focus of our knowledge gathering, and later shared in a post.

References

re:Invent 2023 - A Cloud Odyssey

socraDrk — Wed, 06 Dec 2023 19:56:40 +0000

What a week in Las Vegas!

I feel so lucky to say this is my fourth time attending AWS re:Invent, and it continues to amaze me with all the topics, events, and experiences we can find during that week. So, let me share some thoughts about it.

Before the trip

Ticket for the event... checked
- Every year, the Community Builders program gives a certain amount of vouchers with a discount for the event (this year was 43% off), and I was lucky enough to have one!
- Besides that option, I also learned about the AWS All Builders Welcome Grant program, which provides financial assistance to underrepresented technologists in their early stages of tech careers. Here is a link of a blog post that provides more information about it. And the best part is that I got to know about this thanks to people that I met this year that went thanks to it.
Hotel... checked
- The event is split into several conference centers in Las Vegas casinos. The portal of re:Invent provides access to some of them, but I was too late to reserve one of those, so I needed to book a hotel using a regular portal, and I stayed at the Flamingo's, which is quite close to the Ceasars Forum, which is also a venue of the event and has a direct connection to the Venetian, which is the main venue.
Flight... checked
- I couldn't find a direct flight to Las Vegas from Munich, so the next option that was more convenient and under my budget was to do a step in Atlanta. The downside was that the step took about 5 hours, which meant at least more time to kill playing Pokemon Go.
Making the agenda... checked
- While reserving the sessions I was interested in, I remember my time at the university, as it was required to log in on the platform, look for the session, create our agenda, and then be ready the day they open the registration for them, as the most interesting ones tend to run out of places quite fast.
- A tip is to try to have the sessions in a single venue because even though there's transportation between the venues, it can be exhausting and sometimes even impossible to go from one venue to the other and then to the other. So keep in mind that.
Things to wear... checked
- Remember my last point? Walking is a huge part of the event, so comfortable shoes and clothes are a must. Besides that, it can be chilly in the afternoons during this time of year, so warm clothes are also necessary.
- Also, remember to leave some space in your luggage for all the SWAG you could find in the Expo from the sponsor.

Arrival

I traveled on Nov 26th and arrived in Las Vegas almost at midnight. However, I could still reach the AWS booth at the airport to collect my badge, which was practically empty due to the time. That way, I could avoid a longer queue the next day at the venues.

On the contrary, the queue at the hotel was way longer for everyone arriving. Still, it was nothing that a little bit of patience could handle.

One thing I recommend for people traveling from a different time zone is to avoid making the mistake I made of arriving with not even a complete day to rest. Monday was particularly challenging, but we could find coffee easily in the event.

Food and drinks

Breakfast, lunch, coffee, sodas, and snacks are included during the event. The major venues have specific places for that, and there's a schedule where they provide them. And this year was the first time that the breakfast on Monday was included, as far as I know.

For dinner, there are also several options. Depending on the events we attend after the daily sessions, it might also be possible to grab some food there, but here, let's be clear that it is not included directly on the ticket as the others.

Networking

As a reserved person, starting a conversation with a stranger or finding a proper topic is complex. On top of that, my introverted side requires more time to gather energy to be around people, making this kind of event challenging for me.

I always went with colleagues/friends in the past, so I already had a safety net of people who broke the ice for me. There were the typical occasions in the lunch rooms or in the halls where they started talking with someone, and then I would join the conversation.

Another situation would be during the sessions, where at least I would already have a common topic to talk about. Then, the conversations started naturally with other attendees, as we would have similar issues or solutions for those issues in our companies that were discussed during the session.

Besides that, one of the advantages of having at least one AWS certification is access to the Certification Lounge. In this place, people can relax and connect with other certified people. One of the main advantages is the continuous access to coffee and snacks. Don't get me wrong, these are provided for all attendees all day in the hallways, but the queue could get bigger there than in the certification lounge.

Well, I said all that because this time was exceptional, as it was the first time I went as part of the Community Builders program, which came with the possibility of getting to know even more people, exchanging ideas, and discussing the content of the sessions.

Curious enough, it was also the first time the Community Lounge took place, which worked as my base for the event. There, it was easier to find people I already knew or break the ice with new people, as we were already part of the same community. Therefore, we have things in common. Besides that, I didn't feel drained of energy much, as I felt part of a group that shared the same enthusiasm for the event.

Being an expat living in a country where they don't speak my native language can be challenging from time to time, so it was also great to talk with the AWS LATAM community and show them that the communities in EMEA and NAMER are also great.

Finally, one more thing to highlight on this part is that I met several AWS Heroes and User Group Leaders, which increased my motivation to share the knowledge and get more people involved in the cloud topics. Sharing is caring.

Content

I will not dig too much into the details of the announcements made at the event, as other fellow builders did a great job doing that, so I will share a couple of useful links that are great to keep on the radar.

You can find the top announcements of the event in this link
Most sessions are on this Youtube channel.
Some of the workshops, among other valuable topics, can be found here.

Besides that, the topics shown at the event are state of the art in their areas like DevOps, Serverless, Generative AI and Machine Learning in general, and best practices for building applications on the cloud or migrating to it. The sessions are made with a specific target audience, from beginners to experts.

Events

Besides the several kinds of sessions we can find at the re:Invent, other events promote networking among the participants while allowing them to have drinks and snacks. Like the Expo, where all the sponsors are located, and people can hunt for some cool swag, and also people working at AWS, where they expose use cases and success stories by industry and another place for the developers' community to gather and get more information of best practices and training and certification.

Besides the official party re:Play, we have the AWS Welcome receptions for each region, Community Mixer/User Group/AWS Heroes meetups, and sponsors' events.

It was great that during those events, I encountered colleagues from previous and current customers, which allowed me to catch up and have deeper discussions about the topics shown in the sessions.

Departure

I couldn't predict that snow would cause many problems in Munich. My connection flight got delayed more than 12 hours because of that (Munich airport closed operations), but what kind of odyssey would it be if it didn't have some unexpected events. And at least at this point in time, I could kill some time chatting with all the persons I met who were also traveling back, and that even got stuck, unfortunately.

Last but not least, is to remember to enjoy the event. I'm happy with all my experiences and the people I met.

I'm looking forward to future events, and I hope this information will be helpful. Feel free to share your questions in the comments.

Until next time re:Invent...

Central Repository of CVs with Amazon Textract and Neptune

socraDrk — Mon, 03 Jul 2023 15:01:07 +0000

Working in a consultancy company has the advantage of participating in several projects where different technologies are used to provide a solution for several use cases.

This lets us expand our perspective to solve problems, which is great, but with time is hard to keep up to date with all our colleagues on all the work we have done so far, due to being in different teams, projects, or just because we are mostly focused with our customer and we don’t have much time to chat.

But since we have a sharing knowledge culture at Data Insights, we thought of possible solutions for this. One was already covered by my colleague Hsiao-Ching in this blog post. And here we present another one that can be seen as a complementary part.

Considering our CVs has all the necessary information, we need a process to read and cluster it in the relevant groups like the technologies used, customers we have worked with so far, etc. After that, we can store this in our database of choice to query the results later in time.

For this process, Amazon Textract is the perfect choice to gather the data from within the CVs, which are already in PDF format, though Textract also supports other formats. The first part of our process is to upload the files to S3. From there, a Lambda function is triggered in order to start the Textract job.

By using the feature of form extraction, Textract automatically detects that the CVs have some information in common about the person, like the profile, customers, and technologies used, among others, and puts this information in key-values. After this, the function stores back the result in another S3 bucket in CSV format.

For the second part of the process, we use Amazon Neptune, as this will allow us to make queries in terms of the relationship of the data, like “give me all the colleagues who have worked with this technology or with this customer”.

Then in order to ingest the data into Neptune, another Lambda function is triggered when the result from Textract arrives at S3. The ingestion is possible as the CSV data is in Gremlin load data format, but other formats are also supported, and this lets us do the ingestion in a bulk load fashion, instead of sending insert by insert, and by checking the status of the ingestion, we can see how many files failed to be ingested and need more preprocessing.

Once the data is loaded, by using a Sagemaker notebook, we can start to identify easily who can support us whenever we have a question about a specific topic, find common interests, or check which projects we can use as references for other ones.

Finally, we can remark that this solution is completely serverless, as we don’t manage any infrastructure, and by just uploading the file, the process is automatically started. And as the next steps, we can further clean the information provided by Textract, in order to have a standardized output of values.

Preparing for CKAD exam with EKS, Terraform and ChatGPT sample integration 📘

socraDrk — Fri, 26 May 2023 14:09:08 +0000

I received some feedback from my previous post, saying that it would be interesting to see a little more in details the integration to the API from OpenAI.

I was on my way to write a blog post for that, but then I received a reminder that my CKAD certificate was close to be expired 🤯

So I decided to create a sandbox environment as a study playground for my exam, and deploy in it a really basic integration to OpenAI API 🤓

For the deployment of the Kubernetes cluster, I used Amazon Elastic Kubernetes Service (EKS). This service from AWS enables us to have a complete cluster with minimal operational tasks. And in order to have the configuration of the cluster as Infrastructure as Code, I used Terraform.

Having said that, my implementation is literally a sandbox that shouldn't be used for production or even development environments, but that doesn't mean that you cannot have those scenarios with these tools. For production workloads, I would totally recommend having a look at the Terraform Blueprints for EKS. They cover implementations where the best practices for Kubernetes clusters are followed in terms of network, and security, and it has also several add-ons like Argo, Calico, Kafka, and Airflow, among others.

As for the resources deployed inside Kubernetes, they are based on a simple frontend-backend scenario. Each application is based on a K8s Deployment with an init-container and a "normal" container.

The frontend is a really basic React App that sends a prompt to the backend. And the backend is based in Python and FastAPI, with a single HTTP POST method that prepares and forwards the request to OpenAI API. Both frontend and backend applications are then containerized with Docker and pushed to ECR.

Other K8s resources shown are a Job and a CronJob, accessing the backend and frontend respectively.

All of this is on my repository ckad-sandbox, which only has 2 branches. The master branch and a "fix me" branch, which I hope can be useful for the people that are preparing for the CKAD exam.

What I really like about this exam is that is 100% hands-on, which means we have a limited amount of time to fix the issues in the different clusters that are presented. Here you can find more information about the exam, like the curriculum and more details on what topics to study more.

Of course, if you are planning to do the CKA exam, then a "local" K8s cluster is the one you should install and configure, but the scope of the CKAD allows us to focus just on how the applications should be deployed and configured inside K8s. This means we can save study time by not wasting too much energy deploying the cluster, as we can rely on EKS to have this done for us.

Finally, this implementation could be used as a base for real use case scenarios with some adjustments depending on your use case, like:

Having more than 1 replica, depending on the amount of traffic we would expect for the frontend and backend 🐳🐳🐳
Having a much better definition of limits and quotas for our namespaces.
Enabling Pod security contexts for our deployments 🔒
Choose better persistent storage, as currently, it is using the local disk of the nodes, which is not at all recommended for production environments. For this, we could have a look to use EBS volumes as one of the many options.
Defining an Ingress resource, like the ALB Ingress controller, in order to have a proper way to connect to our application from the outside.
Enabling Calico in order to provide the possibility to use K8s Network Policies within the cluster, which by default are not enabled in EKS 🕸️

I hope this information would be useful in your path to learn more about Kubernetes, EKS, Terraform, and OpenAI.

And any feedback is more than welcome👨‍🏫

AWS Amplify and ChatGPT: one way to generate html mock files for our demos 🤖

socraDrk — Thu, 13 Apr 2023 21:09:29 +0000

In several projects I have worked I have faced the challenge to deliver a sample of what will be done at the end of the project. Usually, this will be after some sessions where the requirements will be gathered and brainstorming of ideas will take place 🤔.

As a result, sometimes we will have a whiteboard full of comments and some meeting notes with a quick summary, from which the developer team needs to start the analysis and development. For this, the deployment of the infrastructure can also take some time before we can actually see some samples running ⏲️.

All of this can take some time, depending on the expertise of our teams, but we would still lose time during this initial setup. Luckily on one of my past projects, I got the opportunity to work with AWS Amplify

"AWS Amplify is a complete solution that lets frontend web and mobile developers easily build, ship, and host full-stack applications on AWS, with the flexibility to leverage the breadth of AWS services as use cases evolve. No cloud expertise needed."

This means that our teams can leverage the deployment of both the frontend and the backend components to Amplify 🧐.

I will use React for my frontend, which will be requesting ChatGPT to generate some HTML mock files which then we can use as a starting point.⚠️Please be aware that the use of the exact same code delivered by ChatGPT is not recommended for production use cases, as it might cause issues with plagiarism, and this is just for demo purposes to show the integration with the API from OpenAI⚠️.

Having said that, I used as a base this link from AWS to initialize the components for the demo.

I'm using a GitHub repository, which can be integrated with Cognito in order to deploy the latest commit as soon as it gets pushed.

We can also add the backend components with Amplify Studio. The UI is quite intuitive and in just a few clicks we can have the components for Authentication (Cognito), Data (AppSync and DynamoDB), Storage (S3), and Functions (Lambda).

And the great part is that it also provides a CLI to use in our console to make these deployments also. For the demo, I added just the above components and modified the data schema to support the description, image, and HTML code of the mock file we want to deploy.

Following the Getting Started link I shared before, all of this took me less than an hour. This means I can focus my time on what my webpage needs to do, instead of breaking my head deploying all services needed! 😎

The sad part is that my frontend skills are not so great, so my modifications were quite simple and were the ones that took me a little more time than expected 🤯.

To begin with, I needed to modify the Lambda function, to read the description of each item and the uploaded image, which has a draft of what we want as a mock file. Based on that, I send a request to ChatGPT to generate the HTML file and store the response on the HTML attribute of the item. In the meantime, the HTML attribute has the name of the item. I also added 2 more columns, one to reflect the value of the HTML attribute of our items and another one for an external link (a little more about that in a moment)

The request to ChatGPT is quite simple for this demo, but this could be also completely parametrized and of course we can train our own model based on our needs, but I keep it simple for the demo and use one of the default ones.

The Lambda function is configured to be triggered by an S3 Event, whenever an image is uploaded with our front end. The best part of this is that with the AWS CLI, we can add this trigger configuration since the trigger happens from the S3 bucket that acts as storage for our amplify project. This step is then asynchronous and will take some time to be reflected on our site, but once we click on refresh we will see the mock HTML.

Now coming back to the external link. I created manually a CloudFront distribution to expose the HTML files generated by ChatGPT. I needed also to modify the Lambda function to store the HTML file also in S3, which acts as the origin for CloudFront.

Here is worth mentioning I'm using Amplify Hosting as a solution to expose my React App. It is also possible to use instead CloudFront + S3 and let Amplify do also this deployment. If we would want more control with setting up a CDN and hosting buckets, that would be the option to use, but for this demo, Amplify Console (Hosting) is more than enough... but I might change the deployment later to just use CloudFront + S3 😼.

Anyways, now if we follow the link, we can actually see the HTML mock file, and the great part is that it is automatically generated after we submit our idea in our frontend 🤖.

Another sample

Another HTML mock file was automatically generated

Lessons learned

Amplify can help us to reduce the development time for our apps. It provides not only support for React but also for other popular frameworks for both web and mobile development.

If we lack a deep knowledge of all the AWS services needed for this kind of application, this can save us from a lot of problems, but if we are an enterprise company where we have several kinds of projects in the same account (for any reason), things get tricky.

Even though we can import existing AWS resources as Amplify components, it might get quite complex to manage the shared resources and not mess with other projects. On top of that, if our application would require specific requirements like being able to access our app only from the Intranet of our company, this solution might not be the recommended way, as we would need to deal with network configuration, maybe adding a WAF for IP filtering or choosing another solution that provides compatibility with VPC + DirectConnect integration, which would make the deployment quite a mess 🙀.

Aside from that, ChatGPT is a tool that can help us in some situations, keeping heavily in mind we should still interpret the results that it gives us. The potential it provides is great if we also consider custom models, but that was out of the scope of the demo.

I hope these lessons are helpful for those who want to try Amplify and leave a comment if you would want to play with the demo.

Yet another journey to the cloud: User Management

socraDrk — Mon, 27 Mar 2023 18:35:47 +0000

Hi and welcome to my first post in dev.to!

There are already several posts, videos, and tutorials from different sources that cover their journey to the cloud, so I will not cover some of the really basic concepts of what's the cloud and similar, but I would rather focus on some of the concepts that I have seen are a bit of a challenge during the first days on cloud projects.

User Management is one of the first concepts we need to have clear before working in the cloud and for that we need to differentiate between the types of users we could have:

Cloud users and roles: via IAM or IAM Identity Center Users (successor to AWS Single Sign-On)
Operating System (OS) users: e.g. Linux or Windows
Database users: e.g. AuroraDB, Oracle, or SQL Server
External APIs or system users: e.g. SAP Hana, On Premises API, BI Tools (Tableau, Power BI, etc)
And on top of that our Application users. Which for this post can be either a web application or REST API

Cloud Users and Roles

The difference between a user and a role on a high level is that the user is associated with a person or an application and the role has no association with a specific person. I leave this link for more information and best practices on when to use a user or role.

These users depend normally on the IAM service or the IAM Identity Center Users and are the ones responsible to communicate with the AWS APIs, which makes them ideal for the use case of deploying the cloud infrastructure like EC2 (ideally with Infrastructure as a Code) or when our application needs to make direct calls to one of the AWS services like Lambda or S3.

The permissions we have for our users are managed by IAM Policies which we can attach to our user, role, or group. One of the best practices for this is to apply least-privilege permissions, which means that we should assign just the permission required to our tasks and nothing more.

OS Users

Once we have our EC2 up and running, we figure out that most probably we need to connect with ec2_user or ubuntu in case of most distros of Linux or Administrator for Windows.

These users are the local users configured by default in the AMIs we choose for our EC2 and with them, we can create more OS users, install packages, update the OS, and in general do our sysadmin tasks inside our EC2.

But one important thing to consider is that those users don't exist in IAM, so by default, we cannot access the AWS APIs (though we can attach an IAM role to our EC2, but let's leave that option aside at the moment to not complicate things more).

Database users

Next, we have our database. In this scenario, we can use AWS RDS to deploy our database and it will create an administrator user. With this, we can create more users and then, as an example, use AWS Secret Manager to store those credentials and even rotate them.

Besides this mechanism, RDS also supports authentication via IAM, which means we would need a valid Cloud User, and via Kerberos. This last one might sound scary, so I will leave it for later.

External Users

Depending on our organization, we might have more systems to access outside AWS, which means more users to track. Here it would depend on the system, we could be speaking of the regular user:password mechanism, certificate-based, SSO via SAML and OAuth2, among several others.

Our Application Users

And last we have the users for our application. Normally we would have a module in our application dedicated to this purpose. This module would have its database of users and check they are who they claim they are (authentication) and that the users have permission to access the resources they request in our applications (authorization).

Having said that, one of the benefits of deploying our application in AWS is that we can leverage that module to AWS Cognito. I talk a little more about this scenario in a previous post.

With Cognito, we can have a user pool with valid users that can access our application and configure our application to retrieve the scopes of those users and see if they can access certain resources.

Users everywhere

At this point I hope it's clear that the more systems and services we would use, the more kind of users are needed, so we need to be careful from the very beginning of our journey when we decide on the users to be created, their permissions and who will use them.

The developer's dream is to have administrator access, with root or sudo permissions, and grant all to our schemas, that would be rainbows and flowers until the sad truth comes when we realized why the best practices are in our best interest: keeping our application and environment safe from attacks, misuse or error during deployments and have proper observability on what is happening in our account.

Centralized user management

But not everything needs to be spread in several places, remember that scary word: Kerberos. This mechanism is used by RDS as a way to authenticate to our database and it requires an Active Directory (AD). Luckily for us, AWS provides a service for that: AWS Directory Service.

If we enable this integration in RDS, all the users we create on Active Directory will be valid on our database. Up to this date, AuroraDB, MySQL, Postgres, Oracle, and SQL Server are compatible with this.

The advantage of using AD is that several external systems, like SAP Hana or BI Tools, are compatible with it and we could configure them also to use it. Even QuickSight, which is the business analytics service from AWS, and with its enterprise edition we can integrate it with Directory Service.

Besides that, we can also configure our Linux or Windows EC2 instances to join our AD and do it automatically during bootstrap. And if we would require to provide several desktops to our users, we might have had a look into AWS Workspaces, which is a managed desktop computing service in the cloud that can be also integrated with AD.

For Cognito, you might guess, we can integrate it with AD using SAML and Active Directory Federation Services. And with this, we can implicitly extend this integration to our applications behind API Gateway, ELB, or mobile apps.

And last, we can enable IAM Identity Center Users to communicate with an AD in our central AWS account, so all the child accounts can access them using the SSO mechanism.

Having configured this, we would need:

Cloud Users: For the initial setup of the main account and the AD.
AD Users: Active Directory users and groups for all other cases.

And that's it! I won't cover the details of the configuration of this setup here, but please leave a comment if that would be something of interest for another post. And I hope this will help you in your journey to the cloud...

One User to rule them all, One User to find them, One User to bring them all and in the system bind them.