Mantalus blog

Mantalus | AWS | Blog | Installing Prometheus and Grafana on EKS

Salek Ali — Wed, 14 Oct 2026 23:55:54 GMT

Why Prometheus and Grafana?

Prometheus is an open-source monitoring system with a time-series database, a powerful query language (PromQL), and built-in alerting. It's designed to handle dynamic cloud environments like Kubernetes.
Grafana is a popular open-source visualization tool that integrates seamlessly with Prometheus. It helps visualize metrics and build insightful dashboards.

Prerequisites

Before we begin, ensure you have the following:

EKS Cluster: A running Amazon EKS cluster.
kubectl: Installed and configured to interact with your EKS cluster.
Helm: A package manager for Kubernetes to simplify the installation process.
IAM Permissions: Adequate permissions to manage your EKS cluster, including installing Helm charts.

Step-by-Step Guide

Step 1: Install the Prometheus and Grafana Helm Chart

The easiest way to deploy Prometheus and Grafana in your Kubernetes cluster is via Helm. We will use the stable Helm charts.

First, add the Helm repository for Prometheus and Grafana:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

Now, install the Prometheus Helm chart into your EKS cluster. You can specify a namespace for Prometheus (e.g., monitoring).

kubectl create namespace monitoring
helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring

The Kube-Prometheus stack will install both Grafana, Prometheus and AlertManager, as well as the node-exporter and kube-state-metrics components for gathering Kubernetes metrics.

You can verify all pods in the stack are running through the following command:

kubectl get pods -n monitoring

Step 2: Accessing Prometheus and Grafana

By default, Prometheus and Grafana services are not exposed to the public internet. You can expose them through an AWS Application Load Balancer (ALB). To access Prometheus and Grafana externally, you can patch the corresponding services to use an ALB.

kubectl patch svc prometheus-kube-prometheus-prometheus -n monitoring -p '' kubectl patch svc prometheus-grafana -n monitoring -p ''

At this point, you can get the public DNS of the load balancer from the AWS console. Be sure to associate a security group to your load balancer to limit access to your monitoring solution. Once the load balancer is up and running, you can access Grafana using the DNS name of the load balancer.

Alternatively, if you are experimenting with Minikube, you can expose your services via port-forwarding using the following commands:

kubectl port-forward -n monitoring svc/prometheus-kube-prometheus-prometheus 9090:9090 kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80

You can now access Prometheus at http://localhost:9090 and Grafana at http://localhost:3000.

The default credentials are:

Username: admin
Password: prom-operator

Be sure to change your password after your first login.

Step 3: Setting up Grafana Dashboards

Grafana comes with pre-configured dashboards for Kubernetes monitoring. Once you're logged into Grafana, follow these steps to set them up:

Prometheus Data Source: If you setup Prometheus and Grafana using the Kube-Prometheus stack, this data source will already be configured. If you have installed Prometheus and Grafana separately, you will need to setup Prometheus as a data source.
- Navigate to Connections -> Data Sources.
- Add a new data source and choose "Prometheus."
- Enter the Prometheus service URL: http://prometheus-kube-prometheus-prometheus.monitoring.svc:9090.
- Click "Save & Test" to ensure Grafana can connect to Prometheus.
Import Pre-Built Dashboards: Grafana allows you to import community-built dashboards specifically designed for Kubernetes monitoring.
- Go to Dashboards -> New -> Import.
- Use dashboard IDs from Grafana's official dashboard page (https://grafana.com/grafana/dashboards).
- Copy the ID for any popular dashboard you want to use. For this post, we will use the "Node Exporter Full" dashboard.
- The dashboard you get from this looks like the following:

Step 4: Configuring Alerts

Prometheus comes with a powerful alerting system. Alerts are defined in Alertmanager, which you can configure in the values.yaml file before installing the Helm chart or modify later. To set up a simple alert, follow these steps:

kubectl edit configmap -n monitoring prometheus-kube-prometheus-alertmanager

Add your alert rules under the alertmanager.yaml section. For example, to set up a basic alert for high CPU usage:

yaml
   alert: HighCPUUsage
   expr: sum(rate(container_cpu_usage_seconds_total[5m])) by (instance) > 0.85
   for: 2m
   labels:
     severity: critical
   annotations:
     summary: "Instance  CPU usage is over 85%"
     description: "CPU usage is above 85% for the past 2 minutes."

Once you've configured alerts, Prometheus will automatically reload the configuration. You can verify the alerts by visiting the Alertmanager web UI (accessible through port-forwarding or Load Balancer).

Step 5: Persisting Data

By default, Prometheus and Grafana store data in their respective pods, which means the data will be lost if the pod restarts. To persist data, you need to configure persistent volume claims (PVCs). Modify the Helm values to enable persistence:

prometheus:
  prometheusSpec:
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 20Gi

grafana:
  persistence:
    enabled: true
    size: 10Gi

After updating the values, you'll need to redeploy the Helm chart with:

helm upgrade prometheus prometheus-community/kube-prometheus-stack --namespace monitoring

This ensures your data remains even after pod restarts.

Conclusion

With Prometheus and Grafana installed on your EKS cluster, you now have a powerful monitoring stack capable of tracking the health and performance of your Kubernetes environment. This setup provides detailed metrics, insightful visualizations, and flexible alerting capabilities, making it easier to ensure your applications and infrastructure are running smoothly. Monitoring with Prometheus and Grafana can be further extended by integrating with additional data sources, enabling long-term storage, or customizing alerts based on your system's needs. Happy monitoring!

Learn more about Amazon EKS here: https://aws.amazon.com/eks/
Learn more about Prometheus here: https://prometheus.io/docs/visualization/grafana/
Learn more about Grafana here: https://grafana.com/

And don't forget to check out more great Mantalus Blogs and Case Studies

Mantalus | AWS | Blog | AWS Verified Access

Anoop Mishra — Mon, 12 Oct 2026 05:08:51 GMT

Introduction

Secure access to corporate and internal applications is critical in today's distributed work environment. Organisations' most common and traditional approach is to have a Virtual Private Network (VPN), but they are often cumbersome to manage and provide a broad level of access, increasing security risks. Whether your applications are deployed within the AWS cloud or on external platforms such as on-premises infrastructure or third-party cloud environments, AWS Verified Access simplifies access to your internal applications using access policies integrated with your own trusted providers to assess user requests without managing the VPN infrastructure.

How it works

AWS Verified Access assesses each user request to your applications and grants access based on two criteria:

Trust Data provided by your selected trust provider (either AWS or a third-party service).
Access Policies that you define within Verified Access.

When a user attempts to access an application, Verified Access retrieves their trust data from the provider and evaluates it against your configured policies. Access is granted only if the user satisfies the specified security criteria. By default, all requests are denied until a policy is established.

Architecture

Key components of Verified Access^[1^]

This blog will explain how it works and the steps to configure AWS Verified Access in your AWS environment.

Type of Verifications

Verified Access supports two types of verifications:

Identity/User Verification integrates with AWS IAM or AWS SSO for user identity verification. You can also use third-party identity providers such as Okta, Azure AD or Google Workspace.
Device Posture Verification integrates with device management solutions, and AWS Verified Access verifies user device compliance. For example, it checks whether the device has up-to-date antivirus software and OS patches or is encrypted.

Access Group Policy Enforcement

AWS Verified Access evaluates access policies defined by the organisation. These policies specify which users, roles, or groups are allowed access and whether the device meets security posture requirements for the device trust provider. Policies can be enforced at the application level, ensuring only authorised users and compliant devices can access a specific app. It uses Cedar policy language, and here are some examples of the policies that can enforced.

The following is a user access policy that ensures that only the users from xyz.com domain are permitted to access the application:

permit(principal, action, resource) when ;

Here is an example of a device compliance policy that ensures the device's location is in the US and MFA is enabled.

permit(principal, action, resource) when ;

Based on the policy evaluation, access to the requested application is granted or denied. If access is denied, the user may be notified of the specific requirements for accessing the requested application.

Logging and Monitoring

All calls made to the application are logged in CloudWatch for auditing and monitoring purposes. Using CloudWatch alarms, you can set up alerts for unauthorised access attempts or suspicious activities to ensure the security incidents are properly handled.

Steps to Create it from AWS Console

1. Create a Verified Access Trust Provider

Configuring user trust provider

- On the AWS Console, select VPC and go to the AWS Verified Access section.
- Select Verified Access trust providers and click Create Verified Access trust provider button.
- Select the User trust provider as the Trust provider type and the required information based on the User trust provider type that you want to integrate. You can either choose IAM Identity Centre or your corporate Identity provider's OIDC settings to incorporate it.

Configuring user trust provider

- To configure this verification:
  - On the AWS Console, select VPC and go to the AWS Verified Access section.
  - Select Verified Access trust providers and click Create Verified Access trust provider button.
  - Select the Device trust provider as the Trust provider type and enter the Device trust provider type
    that you want to integrate.

2. Create a Verified Access Group

A Verified Access Group allows you to manage policies and configurations for multiple endpoints at once. You can assign endpoints to a group for easier management.

Navigate to the Verified Access Groups section.
Click Create Verified Access Group.
Specify the policies that apply to the group, such as user identity verification and device posture checks. For policy examples, refer to the Access Group Policy Enforcement section of this blog.

3. Create a Verified Access Endpoint

In the Verified Access section, choose Endpoints and click Create Endpoint.
Configure the Verified Access endpoint:
- Name: Give your endpoint a descriptive name.
- Application Load Balancer (ALB) or Network Load Balancer (NLB): Select the type of load balancer you use to route traffic to your application.
- Target: Choose the load balancer the endpoint will use to route traffic to your application.

You can either select an existing Verified Access group policy to attach to your endpoint or configure the access policies while creating the endpoint in this section.

Infrastructure As Code

The steps above describe configuring the required settings using the AWS Management Console. However, if you prefer using Infrastructure as Code (IaC) to automate this process, you can visit our Mantalus GitHub repository, which contains CDK code written in Python. With this approach, you can deploy the entire configuration with simple commands.

References

Mantalus | AWS | Blog | Azure AD AWS SSO and Amazon Connect

Stojan Veselinovski — Mon, 12 Oct 2026 05:08:36 GMT

Recently I was having a look at Amazon Connect and configuring a demo for a client. One of the things I wanted to get working was single sign on (SSO) with Azure AD as the identity provider (IdP). My search for blog posts and documentation on how to do this uncovered some good starting points but they didn't cater for all my requirements.

The Next Evolution in AWS Single Sign-On is a great blog post on getting Azure AD identities into AWS SSO but is missing the integration into Connect. Enabling federation with AWS Single Sign-On and Amazon Connect is another great blog post but uses AWS Managed Microsoft AD as its user base.

Between those two blog posts and the AWS documentation I thought I had everything I needed to get it working quickly. The first little hurdle I encountered was my users in Azure AD did not have all the mandatory fields set for automatic provisioning. As per the documentation:

For SCIM synchronization to work, every user must have a First name, Last name, Username and Display name value specified. If any of these values are missing from a user, that user will not be provisioned.

The Azure AD account I was using for this demo wasn't properly maintained so I had to go in there and update all the missing fields. Once these were updated the identities all came across to AWS SSO. A word of warning though, automatic provisioning on Azure syncs every 40 minutes. There were times it took almost an hour to sync across. It can be a long day waiting for users to come across especially if you don't get your settings right from the start and have to make changes and then wait for them to sync across again.

Once I had my users in AWS SSO I moved on to the Connect blog post setup steps. I created a user stojan.veselinovski@mantalus.com in my Amazon Connect instance and for attribute mappings I was using the configuration options as outlined in Step 4.

Now that everything was configured it was time to run my first test and to try login. I grabbed my SSO url from the SSO console. Its configured in the initial setup of SSO and in the format of:

https://.awsapps.com/start#/

The logon screen is shown below.

I clicked on Amazon Connect and it popped up the Microsoft login box and a list of accounts I could use. I authenticated with the appropriate account and then I got the error – $ is empty.

Looking at the documentation I could see the following supported attributes.

I checked the synced identities in AWS SSO and noticed that "Primary Email" was blank. The documentation says auto provisioning uses System for Cross-domain Identity Management (SCIM) v2.0 protocol. The core schema specification can be found at https://tools.ietf.org/html/rfc7643.

It wasn't completely obvious as to what fields I needed to map but my first inclination was to set the source attribute in Azure AD to be userPrincipalName and dest attribute to be email[type = "work"].value. See below. I waited the obligatory 40 odd minutes for the sync to come across and found that the email field had been populated.

So I ran my test login into Amazon Connect again and this time it all worked and we had success.

Key Takeaways

Follow The Next Evolution in AWS Single Sign-On to setup Azure AD integration into AWS SSO
Make sure First name, Last name, Username and Display name are populated in Azure AD for all users.
Make sure you set source userPrincipalName to dest email[type = "work"].value for primary email to come across. You could possibly set other attributes depending on requirements but read through rfc7623 to find what works for you.
Follow Enabling federation with AWS Single Sign-On and Amazon Connect to setup AWS SSO integration into Amazon Connect
Watch out for the 40 odd minute sync from Azure. There is no button or method to trigger a sync and it can be a long day waiting when you are testing different mappings.
Even though its single sign on you still have to manually create a user in Amazon Connect with the same username as the attribute passed in for RoleSessionName from the IdP.