Forem: David💻

The AWS Badge-Dex: An Almost Complete Guide for 2026

David💻 — Wed, 11 Feb 2026 17:26:44 +0000

This guide provides a comprehensive reference of all current AWS badges available on Credly, covering public badges, subscription-based programs, educational offerings, and AWS employee–exclusive badges.

AWS Certified Early Adopter

AWS Certified Early Adopter, are badges given to those that has passed the certifications exams on their beta phases, if successfully the earner will get the certification plus this early adopter badge, which is only obtainable at beta.

Requirements: The first 5,000 exam participants will receive a special Early Adopter badge upon passing.
Cost: At half cost of the normal price of a certification
Course Level: Ranges from foundational to advanced, catering to a wide range of professionals including beginners, intermediates, and experts.
Duration: 250 minutes
Assessment: Involves a proctored exam that need to be passed to achieve AWS Certified status.
Platform: Link

AWS Microcredentials

AWS Microcredentials are hands on, scenario based labs designed to validate user ability to solve real world problems using AWS services. Each microcredential focuses on a specific service and on practical tasks rather than theory, ensuring the user can apply their knowledge in a controlled AWS environment.

Requirements: An active skillbuilder subscription.
Cost: $29 (or the cost of the basic skillbuilder subscription at the time)
Course Level: Appropriate for Intermediates, and Advanced learners.
Duration: 1h30m
Assessment: A set of questions based on to-do tasks on an controlled AWS account environment.
Platform: Link

AWS Ambassador

The AWS Ambassador Program is a dynamic initiative designed to enhance expertise in AWS technologies, fostering a community of skilled professionals. This program offers a variety of digital and in-person learning opportunities, tailored to suit different learning preferences and schedules. It features multiple learning paths and courses that focus on a broad range of AWS topics and services, crucial for mastering the use of AWS tools and services. AWS Ambassadors, as participants, engage in interactive activities and practical exercises, which are key to reinforcing their knowledge and skills.

Requirements: To become an AWS Ambassador, one must be an employee of an AWS Partner Network and hold at least two AWS technical certifications at the Professional or Specialty level. Active contribution to the AWS community through various channels is also required.
Cost: The program, focused on community building and knowledge sharing, does not typically involve a subscription fee like traditional courses. Instead, it emphasizes active participation and contribution.
Course Level: Suitable for individuals who are already familiar with AWS technologies, looking to deepen their expertise and share knowledge with others.
Duration: The involvement varies, as it depends on the individual's contributions and activities within the AWS community.
Assessment: The assessment in this context is more about real-world application and contribution rather than a formalized test. Ambassadors demonstrate their knowledge through public presentations, blogs, whitepapers, and community activities.
Platform: Link

AWS Quest

AWS Cloud Quest is an innovative learning platform that enhances skills in AWS technologies through a role-playing game format. It offers a blend of digital training options, catering to various learning styles and schedules. This platform includes diverse learning paths and courses, focusing on key AWS topics and services. Essential for effectively utilizing AWS tools, it enables learners to engage in interactive labs and hands-on exercises. This approach helps users proficiently architect, develop, and operate within the AWS cloud environment.

Requirements: A skillbuilder account is needed.
Cost: Some roles are available for free; others may require a subscription.
Course Level: Appropriate for various levels, from beginners to advanced.
Duration: Varies 2-6 hours based on the chosen role and learning pace.
Assessment: Involves completing role-specific assignments and tasks.
Platform: Link | Cloud Quest | Industry Quest

AWS re/Start

AWS re/Start is a comprehensive learning platform aimed at individuals seeking careers in cloud computing. It's a full-time, 12-week program that offers skills development in cloud technologies and professional skills like communication and time management. The program is designed for unemployed or underemployed individuals, and no prior technology background is required to apply. It provides hands-on labs and coursework to prepare for entry-level cloud roles and the AWS Certified Cloud Practitioner certification. Upon completion, the program also assists with job placement.

Requirements: Targeted at individuals with little to no technology background, particularly those who are unemployed or underemployed.
Cost: The program is free for learners.
Course Level: Entry-level, suitable for individuals new to cloud computing.
Duration: 12 weeks, full-time.
Assessment: Includes preparation for the AWS Certified Cloud Practitioner exam.
Platform: Link

AWS Instructor

The AWS Authorized Instructor Program and AWS Classroom Training form an integrated learning platform designed to enhance knowledge and skills in AWS technologies. These programs offer a comprehensive range of instructor-led training options, meticulously crafted to cater to different learning styles and schedules. The platform features a variety of learning paths and courses, focusing on diverse AWS topics and services. These instructor-led courses are instrumental in cultivating the competencies required for effectively utilizing AWS tools and services.

Requirements: To become an AWS Authorized Instructor, one must have at least the AWS Certified Solution Architect - Associate Certification and be sponsored by an AWS Training Partner.
Cost: Joining the AWS Authorized Instructor Program is free. Instructors receive benefits like exam vouchers and console credits. The cost for classroom training varies based on the course and delivery method.
Course Level: Suitable for various levels, from beginners to advanced learners, with courses available for different roles such as Solutions Architect, Developer, and Cloud Practitioner.
Duration: Classroom training courses vary in length, ranging from half-day workshops to multi-day sessions.
Assessment: Instructors are evaluated on their knowledge and ability to deliver courses effectively. Students in classroom training participate in hands-on labs and practical exercises.
Platform: Link

AWS Subject Matter Expert

SME is a program that seeks qualified Subject Matter Experts (SME) to participate in AWS certification exam development events. Subject Matter Experts (SME) participate in remote and in-person events that focus on the creation and review of certification exam content.

Requirements:
Relevant hands-on experience with AWS, Approve an AWS certification an claim the benefit of applying for SME
Strong reading and writing skills in English.
For Foundational and Associate level exams: a minimum of one year of practical experience or equivalent in AWS.
For the Professional and Specialty level exams: A minimum of two years of practical experience or equivalent in AWS.
Cost: None
Course Level: Advanced
Duration: None/ At least participate in 3 exams creation
Assessment: Pass the Item Writing Course/ some knowledge checks
Platform:Link | Link (SME) Item Writing Course

AWS Educate

AWS Educate offers hundreds of hours of self-paced training and resources for students new to the cloud, including hands-on labs in the AWS Management Console.

Introductory courses to learn and practice fundamental aspects of the AWS cloud through hands-on labs for six key services: Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, AWS Identity and Access Management (IAM), and Amazon Virtual Private Cloud (Amazon VPC).

Requirements: Register via e-mail (an email from a educational institution is not needed anymore)
Cost: None
Course Level: Beginner
Duration: 4-6 hours
Assessment: Yes, you can retry as many times as you like
Platform: Link

Note Register from the dashboard before entering the courses directly.

AWS Academy

AWS Academy offers higher education institutions a free, ready-to-teach cloud computing curriculum that prepares students to pursue industry-recognized certifications and high-demand cloud jobs. Our curriculum helps educators stay on the cutting edge of AWS cloud innovation so they can help students develop the skills they need to get hired in one of the fastest growing industries.

Requirements: Have been invited by an education institution to a canvas platform
Cost: Not additional cost, but you need to be enrolled in a course
Course Level: Beginner
Duration: 3-12 Months
Assessment: Assessments per module
Platform:Link

AWS Solutions-Focused Immersion Days (Builders Quest)

The AWS Builders Quest comprises a series of webinar-style events aimed at facilitating learning about various AWS services. Each event features a presentation followed by lab sessions, which are instrumental in developing the skills necessary for building, deploying, and operating infrastructure and applications in the cloud.
Requirements: Registration with a business/education email is required.
Cost: None.
Course Level: Appropriate for Beginners, Intermediates, and Advanced learners.
Duration: Sessions typically range from 4 to 6 hours.
Assessment: No formal assessment is conducted; however, participants must complete a form at the conclusion of the presentation.
Platform: Link

AWS Knowledge (Skillbuilder)

The AWS Skill Builder is an integrated learning platform designed to enhance knowledge and skills in AWS technologies. It provides a comprehensive range of digital and classroom training options, each meticulously crafted to cater to different learning styles and schedules. The platform features a variety of learning paths and courses, focusing on diverse AWS topics and services. These courses are instrumental in cultivating the competencies required for effectively utilizing AWS tools and services. Learners can engage in interactive labs and hands-on exercises that reinforce their understanding, thereby enabling them to proficiently architect, develop, and operate applications and infrastructure within the AWS cloud environment.

Requirements: Registration is mandatory, either through email or a Builder ID.
Cost: Free access is available. Paths including labs require a subscription at $29 per month, although these are optional for earning the badge.
Course Level: Suitable for Beginners, Intermediate, and Advanced learners.
Duration: Learning paths vary in length, ranging from 2 to 100 hours.
Assessment: At the end of each path, there is an assessment consisting of approximately 40-60 questions. Participants can attempt the assessment once per day. It is not timed.
Platform: Link

AWS Certified

AWS Certified is a certification program offered by Amazon Web Services (AWS) for professionals seeking to validate their technical expertise and knowledge in the AWS cloud. The program provides a range of certifications that cover various aspects of AWS, from foundational knowledge to specialized skills in areas like solutions architecture, development, operations, and more. These certifications are recognized in the industry and are designed to help professionals demonstrate their cloud abilities and enhance their careers.

Requirements: Requires registration with any email. Prior knowledge and experience in the certification area are beneficial.
Cost: Varies depending on the certification level and includes both free resources and paid exams from $100 - $300.
Course Level: Ranges from foundational to advanced, catering to a wide range of professionals including beginners, intermediates, and experts.
Duration: The preparation time varies based on the certification and the learner's background. Courses and study materials can range from a few hours to several weeks.
Assessment: Involves a proctored exam that need to be passed to achieve AWS Certified status.
Platform: Link

How to obtain a discount in your certifications

There are several ways to get discounts on AWS certifications:

AWS Certified Benefits: Once you are AWS Certified, you can access benefits including a 50% discount voucher for recertification or any other exam.
AWS Emerging Talent Community (ETC): By participating in AWS Educate, AWS Educate, AWS re/start and earning a digital badge, you can be invited to the AWS ETC. Within this community, completing challenges earns you points, which can be redeemed for rewards like AWS certification vouchers.
AWS Certified Global Community: Similar to ETC, once you are AWS Certified you can get an invitation to the Certified Global Community. Within this community, completing challenges earns you points, which can be redeemed for rewards like AWS certification vouchers.
Get AWS Certified: Challenge: By joining the Get AWS Certified Challenge before a specified deadline, you can receive a 50% discount code for a Practitioner, Associate, or Professional-level certification exam. There are also challenges for specific specialty exams; however, these events tend to occur throughout the year without prior notice. Be sure to follow AWS Training & Certification on LinkedIn for updates.
AWS Community Builders Programand Other Initiatives: You can obtain free AWS certification vouchers through various initiatives like the AWS Community Builders Program, the All Builders Welcome Grant scholarship, the AWS New Voices foundational speaker training program.
AWS re:Invent Discount: Attendees of the AWS re:Invent conference also have the opportunity to receive a 50% discount voucher. This voucher can be used for any AWS certification exams.

AWS Partner

The AWS Partner Network offers an array of specialized courses and interactive labs, specifically curated to empower partners with a profound understanding of AWS technologies. This suite of educational resources is thoughtfully designed, encompassing both digital and classroom training tailored to diverse learning styles and busy schedules. The program highlights various learning paths, each focused on distinct AWS themes and services, essential for mastering the nuances of AWS tools and applications. These courses play a crucial role in developing the requisite expertise for effectively deploying AWS solutions. Enrollees are immersed in hands-on labs and engaging exercises, which are instrumental in reinforcing their knowledge. This practical approach ensures that AWS partners are well-equipped to architect, implement, and manage sophisticated solutions within the AWS ecosystem.

Requirements: Company email (the company needs to be part of APN).
Cost: None.
Course Level: Suitable for Intermediate and Advanced learners.
Duration: Learning paths vary in length, ranging from 4 to 8hours.
Assessment: Yes, you can retake as many times as you like
Platform: Link

AWS Cloud Club Captain

AWS Cloud Clubs are student-led user groups for post-secondary students and independent learners. Led by Cloud Club Captains, these communities are open to learners aged 18+ and focus on building, sharing, and growing cloud knowledge through peer-driven activities and events.

Requirements: Must be a post secondary student or an eligible independent learner aged 18+.
Cost: None.
Course Level: Community focused; targeted at individuals interested in building and leading learning communities.
Assessment: No formal assessment. Badge levels are earned based on community activity, event organization, and overall engagement.
Platform: Link

AWS Support Engineer

The AWS Support team is at the forefront of transformational technology, working with a global community of companies and developers who leverage an ever-growing portfolio of AWS services and features to run mission critical applications. These badges recognize demonstrated expertise and a deep understanding of AWS services, reflecting the ability to support, troubleshoot, and optimize complex cloud workloads at scale.

Requirements: Being an AWS active employee. And pass a curated course compromising of level 300 laboratories.
Cost: None.
Course Level: For advances engineers with a deep understanding of services in the area of support
Assessment: An SME Assesment.
Platform: Link

AWS Worldwide Field Enablement

The WWFE mission is to enable the AWS field organization to be the most efficient in the world by empowering sellers to focus their time where it matters most helping customers succeed. This is achieved through the delivery of efficient tools and streamlined processes, timely and relevant customer data, and best in class training and enablement, ensuring sellers can provide exceptional customer experiences and positioning AWS as the place where top sellers want to work. AWS employees that earn the accreditation badge has demonstrated foundational industry domain knowledge, an understanding of financial services customer outcomes, and familiarity with AWS industry solution areas.

Requirements: Must be an active AWS employee.
Cost: None.
Course Level: Targeted to individuals working within a specific industry domain.
Assessment: No formal assessment required.
Platform: Link

AWS Builders League

Builders League (BL) is a 4-6 month event where customers compete in a gamified environment through AWS GameDays, Immersion Days, Certification Challenges, Workshops, and other activities. Solutions Architect, Training & Certification, and Marketing teams leverage the league to increase technical expertise in AWS services, best practices, and architecture patterns through chaos engineering challenges and Skill Builder learning plans. It aims to increase customer AWS certifications, build a technical community for sharing AWS-related queries, and enhance Skill Builder platform knowledge.

Requirements: Needs to be part of APN of Latin America.
Cost: None.
Course Level: Intermediate to advanced; targeted to technical AWS practitioners.
Assessment: No formal assessment required; participation and challenges are gamified through point accumulation.
Platform: Builders League Virtual AWS-hosted environments and online events (GameDays, Immersion Days, Webinars).

AWS AWSome Awards

The AWSome Award program recognizes individuals who exemplify Amazon’s Leadership Principles and deliver extraordinary customer outcomes over the course of a year.

Requirements: Must be an active AWS employee.
Cost: None.
Course Level: Not applicable.
Assessment: No formal assessment required. Recipients must consistently perform at the highest level in their role, raise the bar through their contributions, deliver extraordinary customer outcomes, and be selected by their respective organizational leader.
Platform: AWS Private

Other Badges

Don't forget to gather all your emails in one credly account, you can find the option in settings.

Stuck at an assesment question ? Feel free to check this

Implementing a Secure Data Governance Architecture on AWS with S3, Glue, Athena, and Lake Formation

David💻 — Sat, 18 Oct 2025 23:55:12 +0000

This article explains how to built a secure and fully auditable data governance architecture using AWS S3, Glue, CloudTrail, Lake Formation, and Amazon Quick Suite

This design ensures data organization, encryption, version control, access restriction, and advanced traceability, while enabling analytical queries and dashboards through Athena and Quick Suite

Requirements

AWS account
CSV files with data

The proposed architecture

Walkthrough

The goal is to build a centralized S3-based data lake that manages raw, processed, and sensitive data securely.
Our main bucket can be called as company-data-governance-raw

Inside our bucket we follow this folder structure:

company-data-governance-raw/
├── raw/               
│   ├── clientes/
│   ├── transacciones/
│   └── productos/
│
├── processed/          
│   ├── clientes/
│   └── transacciones/
│       └── sensible=no/
│
├── sensitive/  
│
├── athena/ 
│
└── logs/ 
    └── s3-access/

Inside raw folder we will have these respective csv files:

clientes.csv
cliente_id,nombre,email,tarjeta_credito,region,unidad_negocio
1,Juan Perez,juan@email.com,4532-1234-5678-9010,LATAM,Ventas
2,Maria Lopez,maria@email.com,5425-2345-6789-0123,LATAM,Marketing
3,Carlos Ruiz,carlos@email.com,3782-3456-7890-1234,NORTE,Ventas
4,Ana Torres,ana@email.com,6011-4567-8901-2345,EUROPA,IT
5,Luis Garcia,luis@email.com,4916-5678-9012-3456,LATAM,Finanzas

transaccion_id,cliente_id,monto,fecha,tipo,sensible
1001,1,150.50,2025-10-01,compra,no
1002,2,320.75,2025-10-02,compra,no
1003,3,89.99,2025-10-03,devolucion,no
1004,1,1500.00,2025-10-04,compra,si
1005,4,45.20,2025-10-05,compra,no

producto_id,nombre,precio,categoria,stock
101,Laptop,899.99,Tecnologia,50
102,Mouse,25.99,Tecnologia,200
103,Teclado,45.50,Tecnologia,150
104,Monitor,299.99,Tecnologia,75
105,Webcam,79.99,Tecnologia,100

This organization keeps every dataset in its right lifecycle stage, from ingestion to analysis.

S3 Configuration and Security Controls

When creating the bucket:

✅ Block all public access

✅ Enable versioning to preserve data integrity and restore older versions

✅ Enable MFA Delete to prevent accidental or unauthorized deletions

✅ Enable encryption in transit and at rest (S3 SSE-S3 or SSE-KMS with your own CMK)

Using AWS KMS allows symmetric encryption under your control, essential for sensitive workloads.

S3 Bucket Policy – Enforcing Security

To harden the S3 layer, we can configure our bucket policy with these three key rules:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::company-data-governance-raw/*",
        "arn:aws:s3:::company-data-governance-raw"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    },
    {
      "Sid": "RestrictSensitiveData",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::company-data-governance-raw/sensitive/*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::<account-id>:user/<user-or-role>",
            "arn:aws:iam::<account-id>:role/AWSGlueServiceRole-GobiernoDatos"
          ]
        }
      }
    },
    {
      "Sid": "S3PolicyStmt-DO-NOT-MODIFY-1760725108745",
      "Effect": "Allow",
      "Principal": { "Service": "logging.s3.amazonaws.com" },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::company-data-governance-raw/*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "<your-account-id" }
      }
    }
  ]
}

What this does, denies HTTP requests only HTTPS traffic is allowed.

Restricts access to /sensitive/ only for a specific IAM user and Glue role. Grants S3 logging service permission to write access logs only from the same AWS account. This combination provides network level encryption, identity based access control, and logging integrity.

Enabling Access Logging

Enabling S3 server access logging is essential for auditing who accessed what. Logs from all requests (user or programmatic) are stored under /logs/s3-access/ inside the same bucket, ensuring full traceability of every data operation.

Building the Data Catalog in AWS Glue

After uploading your data into the appropriate folders, the next step is to catalog it. Go to AWS Glue → Data Catalog → Databases

Create a new database named data_governance_catalog

Then create a crawler that will scan your S3 bucket and automatically build table schemas.

Steps:

Crawler name: company-crawler-governance-data-raw
Create a new IAM role: DataGovernance
Choose the database data_governance_catalog as target
Run the crawler on demand

Once it finishes, you’ll see three tables reflecting your S3 folder structure (clientes, transacciones, productos).

Adding Traceability with AWS CloudTrail

Security doesn’t stop at encryption. We also need visibility into every read and write operation.

In CloudTrail → Trails, select your primary trail and enable Data Events for S3. This allows auditing of operations like GetObject and PutObject inside the bucket. CloudTrail logs will now show who accessed which file and when, ensuring compliance and audit readiness

Applying Data Access Controls with Lake Formation

For column level and row level permissions, we can use AWS Lake Formation Filters. Go to Lake Formation → Data Filters → Create new filter

Filter name: data-governance-filters

Select your data catalog and focus on sensitive columns in the clientes table (e.g., credit card holder details)
Column filters: hide entire sensitive columns
Row filters: restrict specific data rows
Then, under Permissions, define Grants to control who can see what.
For example, deny the Glue role and the current user access to columns marked as sensitive.

After applying the filter, running queries via Athena will show masked results for those restricted columns.

Querying Data with Amazon Athena

Now we can query the cataloged data using Athena, which automatically integrates with Glue. When executing a query, Athena respects Lake Formation permissions sensitive columns are hidden for restricted users, and queries run against optimized Parquet data under /processed/.

Example:

SELECT * FROM data_governance_catalog.clientes;

Results are stored in the /athena/ folder, ready to visualize in Quick suite.

Visualizing Insights with Amazon QuickSight

To visualize and share insights. Open QuickSight → New Analysis

Choose Athena as the data source
Select the data_governance_catalog
Build dashboards using your filtered datasets

Example visualizations:

Customers by region
Predicted transactions per segment
Sensitive data audit summaries Quick Suite connects seamlessly with Athena, ensuring that governance rules continue to apply even at the visualization layer.

Cost Estimation

Here’s an approximate monthly cost breakdown for a moderate workload:

Component	Usage Assumption	Estimated / Month (USD)
S3 Storage	500 GB (Standard)	$11.50
S3 Requests	Moderate GET/PUT traffic	$8.00
CloudTrail Data Events	25 M events	$25.00
Glue Data Catalog	20k objects / 1 M requests	$1.20
Glue Crawler	~0.3 h/day (≈ 9 DPU-h)	$4.00
Glue ETL (light)	≈ 9 DPU-h/month	$4.00
Athena Queries	3 TB scanned/month	$15.00
CloudWatch Alarms	5 alarms	$0.50
QuickSight (Enterprise)	1 author + 1 reader + 5 GB SPICE	$30.90
Total Estimated Cost		≈ $100.10 / month

A compact and cost efficient solution for complete data governance.

Conclusion

This architecture provides a secure, auditable, and scalable data governance foundation built entirely with managed AWS services.
From S3 encryption to Lake Formation filters and QuickSight dashboards, every layer enforces security, traceability, and performance. We can easily extend this solution by:

Adding Glue ETL jobs for automated transformations
Integrating with Amazon Redshift for advanced analytics
Applying AWS Macie for sensitive data discovery

If you’re building a data lake or starting a governance project, this structure provides a strong and repeatable foundation for compliance ready analytics in AWS.

Implementing OWIN Authentication and roles for AppService in ASP.NET Framework

David💻 — Sun, 05 Oct 2025 15:59:44 +0000

This article purpose is to describe how to secure our ASP.NET Framework application following a layer structure using OWIN as a middleware and Microsoft Entra ID. This comprehensive guide walks you through the creation of an App that will be published to Azure App Service.

Requirements

Visual Studio 2022
Azure Subscription

Walkthrough

Creating the App Service

Within our Azure subscription, we will create an App Service of type Web App.
In the template, we will fill in basic data:

Select our Azure subscription
Create a resource group if one doesn't already exist
Give our application a name
We will publish the code directly from Visual Studio 2022
Our Runtime will be ASP.NET V4.8
Choose the Region and plan that best suits our needs
For this example, we will select a less crowded region and proceed with the Free plan

Proceed with the "Review + Create" option.

Configuring the Default Domain

After our service has been created, we will navigate to the dashboard and copy the "Default Domain" value.

Registering the Application in Microsoft Entra ID

Now we will navigate within our Azure Portal to Microsoft Entra ID > Manage > App Registrations.
Within this window, we will register the application by clicking the "New Registration" option.

In this window, we will:

Register the name of our application
Define which Tenants can access the application
Register the URI by copying the App Service application URL as "Web"

Configuring Authentication

After having our application registered, in the same dashboard of our registered application, we navigate to Manage > Authentication.

In this window, we will activate the following options:

ID tokens (used for implicit and hybrid flows)
Access tokens (used for implicit and hybrid flows)

Creating the Application in Visual Studio 2022

We will create a new project with the following template:

ASP.NET Web Application (.NET Framework)
Select runtime: .NET Framework 4.8

In the next window:

Select type: Empty & Web Api
Authentication: None

Installing Required Dependencies

Now we will proceed to install the necessary dependencies to run the project. Within the project:

Right-click > Manage NuGet Packages for Solution

Search for and install the following packages:

System.Linq;
System.Security.Claims;
Microsoft.IdentityModel.Protocols.OpenIdConnect;
Microsoft.IdentityModel.Tokens;
Microsoft.Owin.Host.SystemWeb;
Microsoft.Owin.Security;
Microsoft.Owin.Security.Cookies;
Microsoft.Owin.Security.OpenIdConnect;
Owin;
System.Configuration;
System.IdentityModel.Tokens.Jwt;
Microsoft.Owin;

Modifying Web.Config

After installing our dependencies, we start by modifying the Web.Config file.
Within appSettings, we proceed to modify the following values.

From Microsoft Entra ID, in App registrations, we look for our application and copy the following values:

ClientID
TenantID
RedirectUri (that we configured in App Service)

<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="ida:ClientId" value="<your-client-id>" />
  <add key="ida:TenantId" value="<your-tenant-id>" />
  <add key="ida:Authority" value="https://login.microsoftonline.com/<your-tenant-id>/v2.0" />
  <add key="ida:RedirectUri" value="https://<your-application>.azurewebsites.net/" />
</appSettings>
<system.web>
  <authentication mode="None" />
  <compilation debug="true" targetFramework="4.8" />
  <httpRuntime targetFramework="4.8" />
  <customErrors mode="Off"/>
</system.web>
<system.webServer>
  <modules>
    <remove name="FormsAuthentication" />
  </modules>
</system.webServer>

Creating Startup.cs

Now we will proceed with the creation of a file in the root called Startup.cs which is the entry point of an ASP.NET application that uses OWIN; it’s where we define how our app boots up and handles requests.

using System.Web.Http;
using Owin;

[assembly: Microsoft.Owin.OwinStartup(typeof(TestOwinRoles.Startup))]
namespace OwinAuthApp
{
    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // auth middleware
            ConfigureAuth(app);

            // web API
            var config = new HttpConfiguration();

            // attribute routing (required for [Route]/[RoutePrefix])
            config.MapHttpAttributeRoutes();

            app.UseWebApi(config);
        }
    }
}

Creating Startup.Auth.cs

Now we will proceed with the creation of a file in the folder App_start called Startup.Auth.cs which is where our app’s sign-in is set up. It reads our Azure Entra ID settings, turns on cookie authentication so users stay logged in, and enables OpenID Connect so the Microsoft login page is used for authentication. It also fine tunes claims: it keeps the "roles" claim intact, maps those roles so User.IsInRole(...) works.

using System.Linq;
using System.Security.Claims;
using Microsoft.IdentityModel.Protocols.OpenIdConnect;
using Microsoft.IdentityModel.Tokens;
using Microsoft.Owin.Host.SystemWeb;
using Microsoft.Owin.Security;
using Microsoft.Owin.Security.Cookies;
using Microsoft.Owin.Security.OpenIdConnect;
using Owin;
using System.Configuration;
using System.IdentityModel.Tokens.Jwt;
using Microsoft.Owin;

namespace OwinAuthApp
{
    public partial class Startup
    {
        public void ConfigureAuth(IAppBuilder app)
        {
            var clientId = ConfigurationManager.AppSettings["ida:ClientId"];
            var authority = ConfigurationManager.AppSettings["ida:Authority"];
            var redirectUri = ConfigurationManager.AppSettings["ida:RedirectUri"];

            JwtSecurityTokenHandler.DefaultMapInboundClaims = false;

            app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
                CookieName = "OwinAuthApp",
                CookieSecure = CookieSecureOption.Always,
                CookieSameSite = SameSiteMode.None,
                ExpireTimeSpan = System.TimeSpan.FromHours(1),
                SlidingExpiration = true,
                CookieManager = new SystemWebCookieManager()
            });

            app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = authority,
                RedirectUri = redirectUri,
                PostLogoutRedirectUri = redirectUri,

                Scope = OpenIdConnectScope.OpenIdProfile,
                ResponseType = OpenIdConnectResponseType.IdToken,

                TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuer = false,
                    NameClaimType = "name",
                    RoleClaimType = "roles"
                },

                CookieManager = new SystemWebCookieManager(),

                Notifications = new OpenIdConnectAuthenticationNotifications
                {
                    SecurityTokenValidated = context =>
                    {
                        var id = (ClaimsIdentity)context.AuthenticationTicket.Identity;

                        var v2Roles = id.FindAll("roles").Select(c => c.Value).ToList();
                        foreach (var r in v2Roles)
                            id.AddClaim(new Claim(ClaimTypes.Role, r));

                        //  this through the route /token exposes the JWT token for debugging purposes
                        var raw = context.ProtocolMessage.IdToken;
                        if (!string.IsNullOrEmpty(raw))
                            id.AddClaim(new Claim("raw_id_token", raw));

                        return System.Threading.Tasks.Task.FromResult(0);
                    },

                    RedirectToIdentityProvider = context =>
                    {
                        // force re-login only when you explicitly ask: ?relogin=1
                        if (context.ProtocolMessage.RequestType == OpenIdConnectRequestType.Authentication)
                        {
                            if ("1".Equals(context.OwinContext.Request.Query.Get("relogin")))
                            {
                                context.ProtocolMessage.Prompt = "login";
                                context.ProtocolMessage.MaxAge = "0";
                            }
                        }
                        return System.Threading.Tasks.Task.FromResult(0);
                    },

                    AuthenticationFailed = context =>
                    {
                        System.Diagnostics.Trace.TraceError("OIDC Auth Failed: " + context.Exception);
                        context.HandleResponse();
                        var msg = System.Uri.EscapeDataString(context.Exception.Message);
                        context.Response.Redirect("/error.html?message=" + msg);
                        return System.Threading.Tasks.Task.FromResult(0);
                    }
                }
            });
        }
    }
}

Now we are going to create some roles to test our app. For this we go into Azure portal > App registration > Our App > Manifest > AppRoles

Inside our manifest which should be a json object create the following roles:

    "appRoles": [
        {
            "allowedMemberTypes": [
                "User"
            ],
            "description": "Regular users",
            "displayName": "User",
            "id": "00000000-0000-0000-0000-000000000002",
            "isEnabled": true,
            "origin": "Application",
            "value": "User"
        },
        {
            "allowedMemberTypes": [
                "User"
            ],
            "description": "Administrators can do admin things",
            "displayName": "Admin",
            "id": "00000000-0000-0000-0000-000000000001",
            "isEnabled": true,
            "origin": "Application",
            "value": "Admin"
        }
    ],

Now still at Azure portal > Enterprise Application > Our App > Users and groups > Add user/group
Here we will assign our tenant users into the previously created roles

Creating Controllers

Now we proceed to create a controller which will expose our API routes. Create the file SecureController.cs inside the folder Controllers.

In this controller we will expose 4 API's which we should access like: https://.azurewebsites.net/api/secure/

info: Expose the current user authenticated and current role
claims: Expose all current claims with type-value
token: Expose the JWT token for the session
test: A simple endpoint to test if the application is up

using System;
using System.Linq;
using System.Security.Claims;
using System.Web.Http;

namespace OwinAuthApp.Controllers
{
    [Authorize]
    [RoutePrefix("api/secure")]
    public class SecureController : ApiController
    {
        [HttpGet]
        [Route("info")]
        public IHttpActionResult GetInfo()
        {
            var id = User?.Identity as ClaimsIdentity;

            var rolesV2 = id?.FindAll("roles").Select(c => c.Value).ToArray() ?? new string[0];
            var rolesV1 = id?.FindAll(ClaimTypes.Role).Select(c => c.Value).ToArray() ?? new string[0];
            var anyRoles = rolesV2.Concat(rolesV1).Distinct().ToArray();

            var isAdmin = User.IsInRole("Admin") || anyRoles.Contains("Admin");
            var isUser = User.IsInRole("User") || anyRoles.Contains("User");

            var role = isAdmin ? "Admin" : isUser ? "User" : "Unassigned";
            var message = isAdmin ? "Welcome, Admin!" :
                          isUser ? "Hello, User!" :
                                    "You don’t have a role yet. Please contact an administrator.";

            return Ok(new
            {
                isAuthenticated = id?.IsAuthenticated ?? false,
                userName = id?.Name ?? "",
                authType = User?.Identity?.AuthenticationType ?? "",
                rolesV2,
                rolesV1,
                role,
                message
            });
        }

        [HttpGet]
        [Route("claims")]
        public IHttpActionResult Claims()
        {
            var ci = User?.Identity as ClaimsIdentity;

            var claims = (ci?.Claims ?? Enumerable.Empty<Claim>())
                         .Select(c => new { c.Type, c.Value })
                         .ToList();

            var rolesV2 = (ci?.FindAll("roles") ?? Enumerable.Empty<Claim>())
                          .Select(c => c.Value).ToArray();

            var rolesV1 = (ci?.FindAll(ClaimTypes.Role) ?? Enumerable.Empty<Claim>())
                          .Select(c => c.Value).ToArray();

            return Ok(new { rolesV2, rolesV1, claimsCount = claims.Count, claims });
        }

        [HttpGet]
        [Route("token")]
        public IHttpActionResult GetToken()
        {
            var ci = User as ClaimsPrincipal;
            var token = ci?.FindFirst("raw_id_token")?.Value ?? "(none)";
            return Ok(new { id_token = token });
        }

        [AllowAnonymous]
        [HttpGet]
        [Route("test")]
        public IHttpActionResult Test()
        {
            return Ok(new { message = "Controller is working!", timestamp = DateTime.UtcNow });
        }
    }
}

Publishing to Azure

With our project ready, we will now proceed to publish it:

Right-click on the project > Publish > Azure
Authenticate with the user account that has access to our Azure subscription
Select our resource group and app service
Click Publish

Testing the Application

Finally, we verify the access:

User authenticated but without a role

User authenticated with an assigned role

Summary

The Startup.cs sets up the OWIN pipeline so every request passes through authentication and routing, while Startup.Auth.cs configures cookie authentication and OpenID Connect to handle Microsoft logins. We defined app roles in Entra, assigned users and guests to those roles, and mapped the "roles" claim from the ID token into the app so User.IsInRole() and [Authorize(Roles=...)] work correctly. The end result is a secure API where users must log in with Microsoft accounts and see different responses depending on whether they are assigned as Admin or User

Automating EBS Volume Upsizing on AWS

David💻 — Mon, 29 Sep 2025 02:41:55 +0000

In this article, we’ll show how to automate EBS volume upsizing using CloudWatch alarms, SNS notifications, AWS Systems Manager runbooks, and Lambda. By the end, we will have a hands-free setup that detects when volumes are running low on space, triggers an automated workflow, and expands them without downtime, keeping our workloads running smoothly

The Problem

This solution was created so we can fix a specific problem, and that is for the workloads that are running SAP in our EC2 instances, which sometimes run out of space. However, we are very intricate with our cost. The challenge is that not all disks are mounted on the same mount point: some are under /hana/data, others are under /usr/. Also, AWS Lambda currently has no way or library to identify inside our EC2 instances which volumes we have or where they are mounted. Certainly, we can increment the disk size of an EBS volume; however, we also need to extend that storage space inside the instance. For this, we created the following automation that can be easily adapted to other disks, not only SAP solutions

Requirements

AWS account / AWS CLI

Walkthrough

Before we begin, let's make sure the EBS volume that we are going to monitor is attached to an EC2 instance and has the CloudWatch agent installed. This way, we can leverage it to collect metrics

Accesing through Sessiong Manager

First, let's configure an EC2 instance so it has access to Systems Manager. In the AWS Console > Search for EC2 > Instances > Pick your instance > Security

If the instance doesn't have an instance profile role attached, go to Actions > Security > Modify IAM Role

Create a new role or use an existing one that has the policy AmazonSSMManagedInstanceCore attached. This role enables the instance to communicate with the AWS Systems Manager API

Note: Systems Manager is already installed in instances like AL2 and AL2023. If you are using another type of AMI, you should install Systems Manager first

Now, if our EC2 is not public or doesn't have an Elastic IP attached, we need to create VPC endpoints. For this, in the AWS Console go to > VPC > Endpoints > Create endpoint

Here, we need to create 3 types of endpoints in our VPC, in the subnets where our EC2 instances live

com.amazonaws.us-east-1.ssm
com.amazonaws.us-east-1.ssmmessages
com.amazonaws.us-east-1.ec2messages

After picking your VPC and subnets, be sure to pick or create a SG that has the instance SG in the port 443 as the source, feel free to use the same SG for each endpoint

After waiting some minutes this should be enough to have our instance ready ! In the AWS Console search for EC2 > Connect > Session Manager

Installing Amazon Cloudwatch Agent in EC2 AL2023

We begin by downloading the RPM file

curl -O https://amazoncloudwatch-agent.s3.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm

sudo dnf install -y ./amazon-cloudwatch-agent.rpm

We then execute the wizard installer, this will create a series of steps to configure the agent in our instance

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

For the first option we pick Linux.
On which OS are you planning to use the agent? 1. Linux

Trying to fetch the default region based on ec2 metadata. 1. EC2
Which user are you planning to run the agent?. 1. cwagent
Do you want to turn on StatsD daemon?. 2.No
Do you want to monitor metrics from CollectD? WARNING: CollectD must be installed or the Agent will fail to start. 2.No
Do you want to monitor any host metrics? e.g. CPU, memory, etc. 1. yes
Do you want to monitor cpu metrics per core? 2. No (We are only focusing on storage here)
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available? 1. yes
Do you want to aggregate ec2 dimensions (InstanceId)? 2. No
Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file. 4. 60s
Which default metrics config do you want?. 2. Standard

Final output:

{
        "agent": {
                "metrics_collection_interval": 60,
                "run_as_user": "cwagent"
        },
        "metrics": {
                "append_dimensions": {
                        "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
                        "ImageId": "${aws:ImageId}",
                        "InstanceId": "${aws:InstanceId}",
                        "InstanceType": "${aws:InstanceType}"
                },
                "metrics_collected": {
                        "cpu": {
                                "measurement": [
                                        "cpu_usage_idle",
                                        "cpu_usage_iowait",
                                        "cpu_usage_user",
                                        "cpu_usage_system"
                                ],
                                "metrics_collection_interval": 60,
                                "totalcpu": false
                        },
                        "disk": {
                                "measurement": [
                                        "used_percent",
                                        "inodes_free"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "diskio": {
                                "measurement": [
                                        "io_time"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "mem": {
                                "measurement": [
                                        "mem_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        },
                        "swap": {
                                "measurement": [
                                        "swap_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        }
                }
        }
}

Now let's make sure the cloudwatch agent is running by enabling the agent

sudo systemctl start amazon-cloudwatch-agent
sudo systemctl enable amazon-cloudwatch-agent
sudo systemctl status amazon-cloudwatch-agent

If the agent presents this error:

Search for your configuration that probably was created at bin at copy it in the /etc/ folder

sudo cp /opt/aws/amazon-cloudwatch-agent/bin/config.json /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

After that restart the agent

sudo systemctl restart amazon-cloudwatch-agent

Note: If you want to retrieve metrics from inside the EC2 be sure to have this permission cloudwatch:GetMetricStatistics in the instance role, or copy your temporal credentials in the instance

If you only want to track disk percentage which this article aims for this is the config file minimum for that, edit the file /opt/aws/amazon-cloudwatch-agent/bin/config.json

{
        "agent": {
                "metrics_collection_interval": 60,
                "run_as_user": "cwagent"
        },
        "metrics": {
                "append_dimensions": {
                        "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
                        "ImageId": "${aws:ImageId}",
                        "InstanceId": "${aws:InstanceId}",
                        "InstanceType": "${aws:InstanceType}"
                },
                "metrics_collected": {
                        "cpu": {
                                "measurement": [
                                        "cpu_usage_idle",
                                        "cpu_usage_iowait",
                                        "cpu_usage_user",
                                        "cpu_usage_system"
                                ],
                                "metrics_collection_interval": 60,
                                "totalcpu": false
                        },
                        "disk": {
                                "measurement": [
                                        "used_percent",
                                        "inodes_free"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "diskio": {
                                "measurement": [
                                        "io_time"
                                ],
                                "metrics_collection_interval": 60,
                                "resources": [
                                        "*"
                                ]
                        },
                        "mem": {
                                "measurement": [
                                        "mem_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        },
                        "swap": {
                                "measurement": [
                                        "swap_used_percent"
                                ],
                                "metrics_collection_interval": 60
                        }
                }
        }
}

After that reload the file with the following commands

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

Now let's proceed to create a dashboard to actually track the disk usage. For this in the AWS Console > Cloudwatch > Dashboard > Create Dashboard

Inside the dashboard we are going to create a widget metric of type gauge

Here in the tab Source we are going to add the following code:

{
    "region": "us-east-1",
    "title": "Disk Used % (Exact dims, /, <instance-id>)",
    "view": "gauge",
    "stat": "Average",
    "period": 60,
    "setPeriodToTimeRange": true,
    "yAxis": {
        "left": {
            "min": 0,
            "max": 100
        }
    },
    "metrics": [
        [ "CWAgent", "disk_used_percent", "InstanceId", "<your-instance-id>", "path", "/", "device", "<devive-name>", "fstype", "<device-type>", "ImageId", "<ami-id>", "InstanceType", "<instance-type>" ]
    ]
}

After adding the source click on Save, you should see a Gauge graphic showing your current disk usage

For cloudwatch the dimensions needed for instance are required, otherwise you can use only the host.

Since I'm tracking instance with a single root volume, I only checking the device name of the root otherwise you should add the other devices type attached if using more than one volume

Now let's create our custom runbook for this in the AWS Console we search for System Manager. Inside the left menu bar we go for Change Management Tools > Documents

Here we are going to click a Document of type Command.
We can fill the file like this:
Name: ExtendFilesystemRunbook
Target Type: --
Document Type: Command
For the code we are going to use yaml and paste the following code:

schemaVersion: "2.2"
description: "Robust filesystem extension with proper error handling"
parameters:
  device:
    type: "String"
    description: "Device name from CloudWatch"
    default: ""
  mountPath:
    type: "String"
    description: "Mount path from CloudWatch alarm"
    default: "/"
  executionTimeout:
    type: "String"
    default: "900"
mainSteps:
  - action: "aws:runShellScript"
    name: "extendFilesystem"
    inputs:
      timeoutSeconds: "{{ executionTimeout }}"
      runCommand:
        - "#!/bin/bash"
        - "set -e"
        - ""
        - "echo '=== Starting filesystem extension ==='"
        - "echo 'Device: {{ device }}'"
        - "echo 'Mount Path: {{ mountPath }}'"
        - ""
        - "# Install required tools"
        - "echo 'Installing required tools...'"
        - "sudo yum install -y parted cloud-utils-growpart util-linux"
        - ""
        - "# Wait for EBS changes and optimization"
        - "echo 'Waiting for EBS optimization to complete...'"
        - "sleep 60"
        - ""
        - "# Check if volume is still optimizing"
        - "echo 'Checking volume status...'"
        - "for i in {1..10}; do"
        - "    echo \"Check $i/10 - waiting for volume optimization...\""
        - "    sleep 30"
        - "    # Try to read the device"
        - "    if sudo blockdev --getsize64 $ACTUAL_DEVICE > /dev/null 2>&1; then"
        - "        echo 'Volume appears ready'"
        - "        break"
        - "    fi"
        - "done"
        - ""
        - "# Find the actual device"
        - "echo 'Finding actual device for mount path {{ mountPath }}...'"
        - "ACTUAL_DEVICE=$(df '{{ mountPath }}' | tail -1 | awk '{print $1}')"
        - "echo \"Device found: $ACTUAL_DEVICE\""
        - ""
        - "# Show current filesystem info"
        - "echo 'Current filesystem info:'"
        - "lsblk $ACTUAL_DEVICE"
        - "blkid $ACTUAL_DEVICE"
        - ""
        - "# Extract base device and partition"
        - "if [[ $ACTUAL_DEVICE =~ nvme.*p[0-9] ]]; then"
        - "    BASE_DEVICE=$(echo $ACTUAL_DEVICE | sed 's/p[0-9]*$//')"
        - "    PARTITION=$(echo $ACTUAL_DEVICE | sed 's/.*p//')"
        - "else"
        - "    BASE_DEVICE=$(echo $ACTUAL_DEVICE | sed 's/[0-9]*$//')"
        - "    PARTITION=$(echo $ACTUAL_DEVICE | sed 's/.*[^0-9]//')"
        - "fi"
        - ""
        - "echo \"Base device: $BASE_DEVICE\""
        - "echo \"Partition: $PARTITION\""
        - ""
        - "# Show partition table before"
        - "echo 'Partition table before:'"
        - "sudo fdisk -l $BASE_DEVICE"
        - ""
        - "# Grow the partition"
        - "echo 'Growing partition...'"
        - "sudo growpart $BASE_DEVICE $PARTITION"
        - ""
        - "# Show partition table after"
        - "echo 'Partition table after:'"
        - "sudo fdisk -l $BASE_DEVICE"
        - ""
        - "# Force kernel to re-read partition table"
        - "echo 'Forcing kernel to re-read partition table...'"
        - "sudo partprobe $BASE_DEVICE"
        - "sync"
        - ""
        - "# Get filesystem type"
        - "FS_TYPE=$(lsblk -no FSTYPE $ACTUAL_DEVICE)"
        - "echo \"Filesystem type: $FS_TYPE\""
        - ""
        - "# Extend filesystem based on type"
        - "case $FS_TYPE in"
        - "    'ext2'|'ext3'|'ext4')"
        - "        echo 'Extending ext filesystem...'"
        - "        sudo e2fsck -f $ACTUAL_DEVICE || echo 'e2fsck failed, continuing...'"
        - "        sudo resize2fs $ACTUAL_DEVICE"
        - "        ;;"
        - "    'xfs')"
        - "        echo 'Extending XFS filesystem...'"
        - "        sudo xfs_growfs '{{ mountPath }}'"
        - "        ;;"
        - "    *)"
        - "        echo \"Unknown or unsupported filesystem type: $FS_TYPE\""
        - "        echo 'Trying resize2fs anyway...'"
        - "        sudo resize2fs $ACTUAL_DEVICE || echo 'resize2fs failed'"
        - "        ;;"
        - "esac"
        - ""
        - "echo '=== Filesystem extension completed! ==='"
        - "echo 'Final result:'"
        - "df -h '{{ mountPath }}'"
        - "lsblk $ACTUAL_DEVICE"

This AWS Systems Manager runbook automates LVM filesystem expansion to utilize additional storage. It takes three parameters volume group name, logical volume name, and mount point (defaulting to a SAP HANA data setup) then runs a script that resizes all physical volumes in the group, extends the logical volume to use all available free space, and grows the XFS filesystem

Feel free to add tags if necessary, and then click on Create Document

Now we proceed to create our lambda, the purpose of this is to actually increment the volume size at the aws level and then call for the runbook to extend the lvm filesystem.
For this we search for the service Lambda, we click on Functions > Create Function.

We select Author from scratch and fill the following data.

Function name: ExtendFileSystemLambda
Runtime: Python 3.13
Architecture: x86_64
Execution Role: Create a new role with basic Lambda permissions

Feel free to add tags, and then click on CreateFunction

Note: There is no need for the lambda to be on the same VPC

Before we proceed we are going to add an aditional permission needed to run the runbook, for this we go to Configuration > Permissions > Click on Role Name

Inside the IAM Role of the lambda we are going to click on Add Permissions > Create inline policy > Choose JSON

And we copy the following policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeVolumes",
                "ec2:ModifyVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:SendCommand",
                "ssm:GetCommandInvocation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        }
    ]
}

This IAM policy allows the view and resize of EC2 storage volumes, execute commands on EC2 instances through Systems Manager, and write logs for monitoring

After copying the policy in the policy editor we click on Next, we give it a policy name like CommandExecutionResizeFileSystem and proceed clicking Create policy

Now we can go back to our lambda, after this we go into the Code tab and copy this code under the lambda_function.py file

import json
import boto3
import logging
import time
import os

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    """AWS Lambda to resize EBS volume based on CloudWatch alarm."""

    try:
        # Configuration
        volume_increase_gb = int(os.environ.get('VOLUME_INCREASE_GB', '1'))
        wait_time = int(os.environ.get('WAIT_TIME_SECONDS', '30'))

        # AWS clients
        ec2 = boto3.client('ec2')

        # Parse SNS message
        sns_message = json.loads(event['Records'][0]['Sns']['Message'])
        alarm_name = sns_message['AlarmName']

        # Extract instance ID and device from alarm dimensions
        dimensions = sns_message.get('Trigger', {}).get('Dimensions', [])
        instance_id = None
        device = None

        for dim in dimensions:
            if dim['name'] == 'InstanceId':
                instance_id = dim['value']
            elif dim['name'] == 'device':
                device = dim['value']

        if not instance_id:
            raise ValueError("No instance ID found in alarm")

        logger.info(f"Processing alarm '{alarm_name}' for instance {instance_id}, device: {device}")

        # Get instance to find the volume
        response = ec2.describe_instances(InstanceIds=[instance_id])
        instance = response['Reservations'][0]['Instances'][0]

        # Find the volume for the specific device
        target_volume = None
        device_variations = [device, f"/dev/{device}", device.replace('xvd', 'sd'), device.replace('sd', 'xvd')]

        for block_device in instance.get('BlockDeviceMappings', []):
            device_name = block_device['DeviceName']
            volume_id = block_device['Ebs']['VolumeId']

            # Check if this device matches our target (handle naming variations)
            if any(device_name.endswith(var.lstrip('/dev/')) for var in device_variations):
                target_volume = volume_id
                logger.info(f"Found target volume {volume_id} on device {device_name}")
                break

        if not target_volume:
            # Fallback: if no device specified, resize the first non-root volume or root if it's the only one
            volumes = [bd['Ebs']['VolumeId'] for bd in instance.get('BlockDeviceMappings', [])]
            if volumes:
                target_volume = volumes[0]
                logger.info(f"No specific device found, using first volume: {target_volume}")

        if not target_volume:
            raise ValueError(f"No volume found to resize for instance {instance_id}")

        # Get current volume size
        vol_response = ec2.describe_volumes(VolumeIds=[target_volume])
        current_size = vol_response['Volumes'][0]['Size']
        new_size = current_size + volume_increase_gb

        # Resize the volume
        ec2.modify_volume(VolumeId=target_volume, Size=new_size)
        logger.info(f"Resized volume {target_volume}: {current_size}GB -> {new_size}GB")

        # Wait for modification to complete
        logger.info(f"Waiting {wait_time} seconds for volume modification...")
        time.sleep(wait_time)

        # Optional: Run SSM command to extend filesystem
        runbook_name = os.environ.get('RUNBOOK_NAME', 'ExtendFilesystemRunbook')

        if runbook_name:
            ssm = boto3.client('ssm')

            # Get mount path and device from alarm dimensions
            disk_path = "/"  # default
            disk_device_raw = None

            for dim in dimensions:
                if dim['name'] == 'path':
                    disk_path = dim['value']
                elif dim['name'] == 'device':
                    disk_device_raw = dim['value']

            # Find the actual device by looking at the instance
            actual_device = None
            for block_device in instance.get('BlockDeviceMappings', []):
                device_name = block_device['DeviceName']
                # Strip /dev/ prefix for comparison
                device_short = device_name.replace('/dev/', '')

                # Match against the alarm device (handle xvda vs nvme naming)
                if (disk_device_raw and 
                    (device_short.startswith(disk_device_raw) or 
                     disk_device_raw.startswith(device_short) or
                     device_short.replace('nvme0n1p', 'xvd').replace('1', 'a') == disk_device_raw or
                     disk_device_raw.replace('xvd', 'nvme0n1p').replace('a', '1') == device_short)):
                    actual_device = device_name.replace('/dev/', '')  # Remove /dev/ prefix
                    break

            if not actual_device:
                # Fallback: use the first device
                actual_device = instance.get('BlockDeviceMappings', [{}])[0].get('DeviceName', '').replace('/dev/', '')

            # Prepare parameters for the runbook
            ssm_params = {
                'device': [actual_device],  # Send device without /dev/ prefix
                'mountPath': [disk_path]    # Send the actual mount path from alarm
            }

            logger.info(f"Running runbook with device='{actual_device}' and mountPath='{disk_path}'")

            command_response = ssm.send_command(
                InstanceIds=[instance_id],
                DocumentName=runbook_name,
                Parameters=ssm_params,
                Comment=f'Filesystem extension for alarm: {alarm_name}',
                TimeoutSeconds=300
            )
            command_id = command_response['Command']['CommandId']
            logger.info(f"Started filesystem extension: {command_id}")
        else:
            command_id = None
            logger.info("No SSM runbook configured, skipping filesystem extension")

        # Success response
        result = {
            'success': True,
            'instance_id': instance_id,
            'volume_id': target_volume,
            'old_size_gb': current_size,
            'new_size_gb': new_size,
            'alarm_name': alarm_name
        }

        if command_id:
            result['command_id'] = command_id

        return {
            'statusCode': 200,
            'body': json.dumps(result)
        }

    except Exception as e:
        logger.error(f"Error: {str(e)}")
        return {
            'statusCode': 500,
            'body': json.dumps({
                'success': False,
                'error': str(e)
            })
        }

After copying the code, click on Deploy

This Lambda function automatically responds to CloudWatch alarms by expanding disk storage. When triggered by an SNS notification from a storage alarm, it identifies the specific EC2 instance from the alarm, increases each volume by 1GB, waits for the changes to take effect, then runs the filesystem extension runbook to make the additional space available to the database

Now to test our lambda, this body should replicate the data of the alarm we should receive from a cloudwatch alarm this way the lambda will resize the disk in AWS and invoke the runbook we previously config

{
  "Records": [
    {
      "Sns": {
        "Message": "{\n  \"AlarmName\": \"DiskUsed% CRIT\",\n  \"AWSAccountId\": \"111882299112\",\n  \"NewStateValue\": \"ALARM\",\n  \"Trigger\": {\n    \"Namespace\": \"CWAgent\",\n    \"MetricName\": \"disk_used_percent\",\n    \"Dimensions\": [\n      {\"name\": \"InstanceId\", \"value\": \"<your-instance-id>\"},\n      {\"name\": \"device\", \"value\": \"nvme0n1p1\"},\n      {\"name\": \"path\", \"value\": \"/\"}\n    ]\n  }\n}"
      }
    }
  ]
}

Once we tested our lambda we can verify it certainly increase the space both in AWS and inside the volume

Now for our final steps we are going to configure the automated part of this, for this we are going to create a cloudwatch alarm with a sns to trigger our lambda we are going to receive the event for our lambda to increment the space on the volume and then expand it at OS level. For this we go AWS Console > Cloudwatch > All alarms > Create alarm.

In the first step Metric, we copy the same source we used in our dashboard.

{
    "region": "us-east-1",
    "title": "Disk Used % (Exact dims, /, <instance-id>)",
    "view": "gauge",
    "stat": "Average",
    "period": 60,
    "setPeriodToTimeRange": true,
    "yAxis": {
        "left": {
            "min": 0,
            "max": 100
        }
    },
    "metrics": [
        [ "CWAgent", "disk_used_percent", "InstanceId", "<your-instance-id>", "path", "/", "device", "<devive-name>", "fstype", "<device-type>", "ImageId", "<ami-id>", "InstanceType", "<instance-type>" ]
    ]
}

This should show us the current metric we are tracking

At conditions for testing purpose we are going to put the disk at the current limit otherwise put it at a threshold you see fit

At notification pick > In alarm state > Create new topic > Set up your sns topic > your sns topic should point to the lambda
Next in alarm details feel free to add a name and a description, after that create the Alarm.

After waiting for some minutes we should see the alarm being triggered

When the alarm is activated it will trigger our lambda then our runbook will resize our volume

The volume can only be resized every 6 hours

After lambda execution we can se our resize has been succesful

Lessons learned and a conclusion

Automating EBS growth from disk usage alarms is solid, but there are some details:

Don’t rely on device names. Rely on the VolumeId. You won’t get it from CloudWatch; resolve it on the instance via SSM using the device and path the alarm provides
Pick a single integration pattern and wire it correctly. For code that expects SNS, use Alarm → SNS → Lambda and the SNS principal in your Lambda policy
Bias toward safety. Remove “first volume” fallbacks, add idempotency checks, and guard with clear alarms and logs

Protecting our EKS Nodes with Wazuh

David💻 — Thu, 18 Sep 2025 21:31:54 +0000

This article explains how to deploy a secure Wazuh All-in-One server on AWS and configure Amazon EKS node groups to automatically install the Wazuh agent. With this setup, we can enable vulnerability detection and continuous monitoring across our Kubernetes workloads.

Before we start with this article, have you heard of Wazuh before ?

What is Wazuh?

Wazuh is a powerful open source platform for threat detection, incident response, and compliance.

Requirements

AWS Account & CLI (and a profile with enough permissions for: VPC, EC2, ACM PCA, and Client VPN
ACM Private CA (or an external CA you control
OpenSSL

What is AWS Client VPN?

AWS Client VPN is a managed VPN service that lets users securely connect to AWS resources using OpenVPN based clients. By using ACM Private CA certificates, we can enforce mutual authentication, ensuring both the server and the client prove their identities before a session is established

Walkthrough

Creating the VPC

Let's start by creating or using an existing VPC. Create subnets for:

Public subnet – for NAT Gateway
Private subnet – for Wazuh All-in-One
VPN subnet – to associate with the Client VPN endpoint
The Wazuh server must go in the private subnet. No public IP is required

In this case, we are defining one public subnet and two private subnets. The public subnet will host the Internet Gateway and a NAT Gateway, which act as controlled egress points for outbound traffic. The private subnet will serve different purposes: one dedicated to the Wazuh server itself, and another for VPN clients that will provide secure access into the VPC

Note: If your architecture already connects multiple VPCs through an AWS Transit Gateway (TGW), you could simplify this design by deploying Wazuh entirely in private subnets and routing access through the TGW. This way, Wazuh services remain isolated while still being reachable from other connected networks without needing multiple subnet roles or direct internet exposure

We are going to create our VPC, for this in the AWS console we search for VPC > Your VPCs > Create VPC > VPC Only

We follow by creating our subnets in our VPC, by following in the AWS console > VPC > Subnet > Create Subnet > Select the previously created VPC. And we follow the following segmentation, for this example we are going to use a single AZ but for reability we can use two.

Segmentation

VPC CIDR: 10.50.0.0/24

WAZUH Public Subnet (10.50.0.0/28): Hosts the NAT Gateway to provide controlled outbound internet access.
WAZUH Server Managed (10.50.0.32/27): Private subnet for the Wazuh All-in-One server.
VPN Client Subnet (10.50.0.64/27): Private subnet dedicated to Client VPN resources.
Client VPN Endpoint Range (10.50.8.0/22): Address pool for devices connecting through the VPN, non-overlapping with the VPC.

Now we create. route table for our subnets, for this in the AWS Console > VPC > Route Tables > Create Route Table

Our route table for the Wazuh subnet, should have a NAT Gateway pointing to the public subnet:

The Peering between VPC

Since my EKS lives in another VPC we need to make a VPC peering between both so they can communicate, this step can be ignored if the Wazuh server and EKS lives in the same VPC, but as a good practices both of them are separated.

For this we follow this step in the AWS Console > VPC > Peering Connections. Define the request VPC as the EKS VPC and the acepter as the Wazuh VPC.

Certificates with ACM PCA

Create server and client certificates to use with Client VPN.
Server Certificate:
Generate a CSR and private key with OpenSSL:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key \
  -out server.csr \
  -subj "/CN=wazuh.server" \
  -addext "extendedKeyUsage=serverAuth"

Issue the certificate with ACM PCA:

aws acm-pca issue-certificate \
  --certificate-authority-arn <pca-arn> \
  --csr fileb://server.csr \
  --signing-algorithm "SHA256WITHRSA" \
  --validity Value=365,Type="DAYS" \
  --idempotency-token vpn-cert-01

Fetch the certificate (replace with the ARN from the previous command):

aws acm-pca get-certificate \
  --certificate-authority-arn <pca-arn> \
  --certificate-arn <certificate-arn> \
  --output text > server.crt

Import the certificate into ACM so it can be used by Client VPN:

aws acm import-certificate \
  --certificate fileb://server.crt \
  --private-key fileb://server.key \
  --certificate-chain fileb://ca-chain.pem

Client Certificate
Generate a CSR and private key:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout client.key \
  -out client.csr \
  -subj "/CN=wazuh.client" \
  -addext "keyUsage=digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=clientAuth"

Issue with ACM PCA (using the EndEntityClientAuthCertificate template):

aws acm-pca issue-certificate \
  --certificate-authority-arn <pca-arn> \
  --csr fileb://client.csr \
  --signing-algorithm "SHA256WITHRSA" \
  --validity Value=365,Type="DAYS" \
  --idempotency-token vpn-cert-02 \
  --template-arn arn:aws:acm-pca:::template/EndEntityClientAuthCertificate/V1

Fetch the certificate:

aws acm-pca get-certificate \
  --certificate-authority-arn <pca-arn> \
  --certificate-arn <certificate-arn> \
  --output text > client.crt

Security Groups

Client VPN SG – allow inbound 443 (UDP) and allow traffic from the VPN CIDR.
Wazuh SG – allow 22, 443, 1514, and 1515 only from the VPN CIDR.

SG for Client VPN:

aws ec2 create-security-group \
  --group-name wazuh-clientvpn-access \
  --description "Enable traffic from Client VPN" \
  --vpc-id <vpc-id> \
  --region <region>

aws ec2 authorize-security-group-ingress \
  --group-id <vpn-sg-id> \
  --protocol tcp --port 22 --cidr <vpn-client-cidr> \
  --region <region>

aws ec2 authorize-security-group-ingress \
  --group-id <vpn-sg-id> \
  --protocol tcp --port 443 --cidr <vpn-client-cidr> \
  --region <region>

SG for Wazuh Server

aws ec2 create-security-group \
  --group-name wazuh-management-access \
  --description "Enable access from VPN to Wazuh" \
  --vpc-id <vpc-id> \
  --region <region>

aws ec2 authorize-security-group-ingress --group-id <wazuh-sg-id> --protocol tcp --port 22   --cidr <vpn-client-cidr> --region <region>
aws ec2 authorize-security-group-ingress --group-id <wazuh-sg-id> --protocol tcp --port 443  --cidr <vpn-client-cidr> --region <region>
aws ec2 authorize-security-group-ingress --group-id <wazuh-sg-id> --protocol tcp --port 1514 --cidr <vpn-client-cidr> --region <region>
aws ec2 authorize-security-group-ingress --group-id <wazuh-sg-id> --protocol tcp --port 1515 --cidr <vpn-client-cidr> --region <region>

Create Client VPN Endpoint

Use the ACM server certificate and your root CA for mutual authentication:

aws ec2 create-client-vpn-endpoint \
  --client-cidr-block <vpn-client-cidr> \
  --server-certificate-arn <server-cert-arn> \
  --authentication-options Type=certificate-authentication,MutualAuthentication={ClientRootCertificateChainArn=<ca-arn>} \
  --dns-servers 8.8.8.8 8.8.4.4 \
  --transport-protocol udp \
  --vpc-id <vpc-id> \
  --security-group-ids <vpn-sg-id> \
  --region <region>

Associate the endpoint with your VPN subnet, create a route to the Wazuh subnet, and authorize ingress

aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id <cvpn-endpoint-id> \
  --subnet-id <subnet-id> \
  --region <region>

Route to Wazuh subnet

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id <cvpn-endpoint-id> \
  --destination-cidr-block <wazuh-subnet-cidr> \
  --target-vpc-subnet-id <subnet-id> \
  --region <region>

Authorize access

aws ec2 authorize-client-vpn-ingress \
  --client-vpn-endpoint-id <cvpn-endpoint-id> \
  --target-network-cidr <wazuh-subnet-cidr> \
  --authorize-all-groups \
  --region <region>

Launch Wazuh All-in-One

Deploy the official Wazuh All-in-One AMI from AWS Marketplace. Place it in your private subnet with the Wazuh SG attached. No public IP is needed

Configure the VPN Client

Download the Client VPN config file and add your client certificate, key, and CA:

client
dev tun
proto udp
remote <vpn-endpoint>.prod.clientvpn.<region>.amazonaws.com 443
nobind

<cert>
(client.crt)
</cert>
<key>
(client.key)
</key>
<ca>
(root-ca.pem)
</ca>

Import this into the AWS VPN client or OpenVPN client.

For this Download AWS VPN Client here, after installing go to File > Manage Profiles > Fill the name and import he ovpn.

Test Access

Connect to the VPN.

Open Wazuh UI at https://

Confirm agents can communicate on ports 1514 and 1515.

At this point, your Wazuh All-in-One deployment is securely reachable only via VPN. You’ve kept your server private, used certificate-based authentication, and segmented your AWS environment properly.

Installing Wazuh in our EKS Node

For this we are going to create a new launch template that we can use in our managed EC2 nodes.

Note: Replace WAZUH_MANAGER with the IP of the EC2 instance of Wazuh

Create a bash script like this and execute it after filling the fields.

LT_NAME="wazuh-agents-lt"
AMI_ID="ami-030da889991638ab6"        # (AL EKS 2023 or your preferred EKS AMI)
INSTANCE_PROFILE_ARN="<arn:aws:iam::123456789012:instance-profile/MyRole>"  # Useful if you want to session manager into the nodes.
SECURITY_GROUP_ID="<sg-xxx>"
SUBNET_ID="<subnet-xxx>"


BOUNDARY="==MYBOUNDARY=="

read -r -d '' MIME <<'EOF'
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -euxo pipefail
HOSTNAME=$(curl -s http://169.254.169.254/latest/meta-data/local-hostname || hostname)
curl -o /root/wazuh-agent-4.12.0-1.x86_64.rpm https://packages.wazuh.com/4.x/yum/wazuh-agent-4.12.0-1.x86_64.rpm
WAZUH_MANAGER=10.50.0.41 WAZUH_AGENT_NAME="$HOSTNAME" rpm -ihv /root/wazuh-agent-4.12.0-1.x86_64.rpm
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

--==MYBOUNDARY==--
EOF

UD_B64=$(printf "%s" "$MIME" | base64 | tr -d '\n')

aws ec2 create-launch-template \
  --launch-template-name "$LT_NAME" \
  --version-description "v1-wazuh-agent" \
  --launch-template-data "{
    \"ImageId\": \"${AMI_ID}\",
    \"InstanceType\": \"<your-node-group-instance>\",
    \"IamInstanceProfile\": { \"Arn\": \"${INSTANCE_PROFILE_ARN}\" },
    \"NetworkInterfaces\": [
      {
        \"DeviceIndex\": 0,
        \"SubnetId\": \"${SUBNET_ID}\",
        \"Groups\": [ \"${SECURITY_GROUP_ID}\" ],
        \"AssociatePublicIpAddress\": false
      }
    ],
    \"MetadataOptions\": { \"HttpTokens\": \"required\", \"HttpEndpoint\": \"enabled\" },
    \"TagSpecifications\": [
      {
        \"ResourceType\": \"instance\",
        \"Tags\": [
          { \"Key\": \"Name\", \"Value\": \"wazuh-agent\" },
          { \"Key\": \"Role\", \"Value\": \"wazuh\" }
        ]
      }
    ],
    \"UserData\": \"${UD_B64}\"
  }"

After creating the launch template, create the nodegroup, by going to AWS Console > EKS > Compute > Node Groups > Add > Launch Template

Now inside our Wazuh server dashboard we can see our nodes being registered.

Lessons learned and a conclusion

While setting up a Client VPN with private certificates ensures a secure and private connection, it can become costly in the long run. A practical alternative is to leverage AWS Systems Manager Session Manager with port forwarding to reach the Wazuh dashboard. This approach shifts access control to the AWS service layer instead of the networking layer, reducing complexity and cost while still maintaining strong security

Creating a Security Incident Portal with Kiro and AWS

David💻 — Mon, 15 Sep 2025 13:28:56 +0000

This article aims to showcase how Kiro’s features can be used to build a simple security incident portal, hosted on AWS with services like Lambda, Secrets Manager, S3, and CloudFront, while leveraging MSAL Entra ID for authentication.

Requirements

AWS account
MSAL Entra ID
Kiro

Note: This project was made with Kiro before the release of their pricing plan.

The proposed architecture

What is Kiro?

Kiro IDE is an AI powered development environment designed to speed up software creation. Instead of starting with manual boilerplate code, you interact with Kiro in natural language. You can describe what you want to build, and Kiro generates the project structure, code, and configurations.
Find it here

What is Vibe coding?

Vibe coding is a development style where you start writing software through natural conversation or free form prompts instead of rigid plans or detailed specifications. The focus is on exploration and iteration, you describe what you want, review what’s generated, and refine it step by step.

Kiro Vibe Mode vs Spec

Kiro offers two ways to start your project:

Vibe: Chat first, then build. You provide a prompt with your requirements, Kiro generates code, and you give feedback on the output.
Spec: Plan first, then build. You give Kiro a detailed set of instructions, similar to a PRD (Product Requirements Document) that outlines the purpose and functionality of the product/feature.

In my experience, especially during Kiro’s early days, Spec mode quickly ran out of requests and often did a poor job completing specific tasks. Some requests timed out, others didn’t match the requirements, and the code started looking like spaghetti. This led me to restart the project from scratch.

That’s when I switched to Kiro Vibe mode. Here, I interacted with Kiro through specific prompts about what I needed. I began with the frontend project. Since I wanted to test Kiro’s capabilities, I was intentionally vague and only specified that I wanted a form to report security incidents. Kiro quickly proposed a solution stack: Vite + React. With continuous feedback and iteration, it took me about two days to build the frontend—though I was limited by Kiro’s daily request cap. Without that limitation, it probably would have been faster.

Note: This project, while necessary, started as a side project in my free time. The main goal was to explore how popular LLM tools could be leveraged for vibe coding and to see the results. Sure, I could have coded everything manually, but that would have required writing unit tests, creating user stories, designing in Figma, and more. With Kiro, I was able to focus on delivering an MVP as quickly as possible.

Walkthrough

After installing Kiro IDE, create a project. Feel free to organize both the backend and frontend into two folders.

Something about the risk of Autopilot

While Autopilot can be an awesome tool—allowing Kiro to update multiple files automatically—it can also be a double-edged sword. Letting changes go through without review might introduce unnecessary code or even break the codebase. In some cases, other LLM coding assistants have executed terminal commands that interacted with projects and even deleted databases !

I can’t stress enough that these types of tools should only be used in offline or development environments, not directly in production

Fortunately, Kiro’s default behavior is to prompt you before authorizing any script or command execution.

After some prompting

It is very important to keep in mind that if Autopilot is active, it can lead to massive changes in the codebase. This may result in some functionalities being abandoned or replaced with unnecessary code. To mitigate this risk, I recommend managing our project with git and maintaining a README.MD file for context use, this file is useful if we runout of context window, since it provides a quick reference that allows another session to continue working with the same background knowledge

Frontend structure

Note: The code will be at the final of this article in a git repository.

We start by building our frontend with the following prompts:

I would like to create a security incident portal where users can authenticate with their organization email using MSAL. The portal should support two roles: User (can only submit reports through a security report form) and Admin (can view submitted reports in a dashboard). Please generate the frontend project structure, including components for login, forms, common UI elements, and an admin dashboard.

Please organice the project in a good practice matter, be sure to separate the logic on different components

The user role should be able to fill a form with fields related to a IT security incident, be sure to add fields that details the case, the admin role should be able to view this cases in a dashboard with the option to resolve this reports with a modal view.

The admin should be also be able to download a report of this incidents in the dashboard tab, through a csv file, please add a button with the option to download the reports including the detailed information

Note: There was a process of debugging and asking other prompts for fixing some aspects

Our frontend is being described as the follow:

components/: All UI building blocks.

admin/: admin dashboard & modals.
auth/: login screen and Microsoft (MSAL) button.
common/: reusable UI bits (logo, spinner, success/error modals).
forms/: the security incident report form.

config/: App configuration and constants

constants.js → shared constants (app names, messages, etc.).
lambdaUrls.js → API/Lambda endpoints.
msalConfig.js → MSAL/Entra ID settings (clientId, authority, redirect).
roles.js → role names/permissions used for RBAC.

hooks/: Reusable logic as React hooks:

useRequests.js → fetch/POST helpers to your APIs.
useUserRole.js → derive the user’s role from MSAL claims or app state.

Main/Root files

App.jsx → The root UI shell (routes/layout). It wires providers, nav, and renders pages/components based on auth/role.
main.jsx → The entry point creates the React root and mounts (often wraps with MSAL/Context providers).
App.css / index.css → Global styles.
env.example → Sample environment variables to copy to your local .env.
eslint.config.js → Linting rules.
companylog.webp → Brand/logo asset.

src/
├─ assets/
├─ components/
│  ├─ admin/
│  │  ├─ SecurityDashboard.jsx
│  │  └─ SecurityReportModal.jsx
│  ├─ auth/
│  │  ├─ LoginScreen.jsx
│  │  └─ MicrosoftLoginButton.jsx
│  ├─ common/
│  │  ├─ CompanyLogo.jsx
│  │  ├─ ErrorModal.jsx
│  │  ├─ LoadingSpinner.jsx
│  │  └─ SuccessModal.jsx
│  └─ forms/
│     └─ PhishingReportForm.jsx
├─ config/
│  ├─ constants.js
│  ├─ lambdaUrls.js
│  ├─ msalConfig.js
│  └─ roles.js
├─ hooks/
│  ├─ useRequests.js
│  └─ useUserRole.js
├─ App.css
├─ App.jsx
├─ index.css
├─ main.jsx
├─ companylog.webp
├─ env.example
└─ eslint.config.js

Authentication

Before we can execute our code we have some parameters that need to be filled.

In this application we will use Entra ID MSAL authentication, since most organizations has a corporate email through Microsoft.

For this we go to Microsoft Entra Admin Center > App Registrations > New Registration

In the registration we will give it a name select our current single tenant, and for Redirect URI we will select Web and add our localhost

Note: We will later deploy this in a bucket using cloudfront and route53

After registering our app we will copy the ClientID and the TenantID

And replace it in our code at config > msalConfig.js

// msalConfig.js - MSAL authentication configuration
import { PublicClientApplication } from '@azure/msal-browser';

// Get configuration from environment variables with fallbacks
const clientId = import.meta.env.VITE_MSAL_CLIENT_ID || "<your-client-id>";
const tenantId = import.meta.env.VITE_MSAL_TENANT_ID || "<your-tenant-id>";

export const msalConfig = {
  auth: {
    clientId: clientId,
    authority: `https://login.microsoftonline.com/${tenantId}`,
    redirectUri: window.location.origin + "/",
  },
  cache: {
    cacheLocation: "sessionStorage",
    storeAuthStateInCookie: true,
  },
};

export const msalInstance = new PublicClientApplication(msalConfig);

Running our frontend

Now we can test out our frontend view by running the following command:

cd frontend
npm install
npm run dev

Our login landpage should look like this:

The form:

The dashboard:

Now that our that we check our frontend is working at a mock level let's proceed uploading our frontend to AWS.

For this we execute

npm run build

This will generate a dist folder in our project with the following content

dist/
├─ index.html
├─ vite.sg
├─ assets/
│  ├─ admin/
│  │  ├─ index.js
│  │  └─ index.css

Frontend from local to AWS

Now we are going to create an S3 bucket, we can configure it with the default settings, as we are going to use S3 origin access with cloudfront there is no need to make the bucket public we securely expose it through it.
We go into the AWS Console > S3 Bucket > We left everything as is.

Note: You might check what object locking and versioning can do, normally we handle our frontend through a CI/CD process, but for this example I will upload the files directly into the bucket.

After creating we bucket before we upload our files we will go into Properties > Static website hosting.

We will enabled it as Bucket hosting and set index.html as default

Our files in our S3

Now let's proceed with the cloudfront creation:

For this we give our distribution a name, we are going to use a custom domain since I already have a route53 and my certificate loaded at ACM I will use that, otherwise you can use the provided link at cloudfront or just use s3 directly.

Here we will use our bucket as a origin, be sure to select the s3 endpoint not the website, as we will configure the s3 endpoint with origin access, AWS cloudfront will provide a policy that should be added to the bucket.

The policy goes at the permission tab of our bucket at bucket policy, it should look similar to this

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::security-portal.company.net/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111882899112:distribution/E1DCXJC9B8PVOV"
                }
            }
        }
    ]
}

After that feel free to setup WAF and security features to the cloudfront distribution for this example, I will keep it as simple as possible.

After the distribution is created you have two options to register that alternative domain, you can copy the url provided by cloudfront and register it at your registar or route53 as an A record or CNAME or if. you use route53 you can directly add both required records by pressing the button Route Domains to Cloudfront

Finally we have our frontend ready, however there is one big task left. Entering the backend.

Note: Don't forget to add the new domain to MSAL config !

Backend structure

For our backend we will manage a simple architecture based on an small mysql rds database and a lambda, the lambda will be deployed on a VPC that has a peering connection between the VPC of the database, otherwise if your database is public or lives in the same VPC there might be no need to do this.

Our frontend is being described as the follow:

├─ database/
│  ├─ schema.sql/
├─ lambda/
│  ├─ node-modules/
│  ├─ index.js
│  ├─ package.json
│  ├─ package-lock.json

database/: Database sql script

schema.sql → full MySQL 8.0 DDL: tables (requests, request_comments, user_roles, request_audit_log), request_stats view, seed admins, sample data.

lambda/: Python 3.13 with URI Function and VPC

index.js → main Lambda handler & router (health, auth role lookup, list/create requests, stats, update status). Includes MySQL pool, JSON helpers, ID generators, Teams/Power Automate notifier, and CORS.
package.json → Node project manifest (runtime entrypoint, scripts, deps like mysql2/promise).
package-lock.json → exact dependency lock for reproducible builds.
node_modules/ → installed npm packages used by the Lambda at runtime.

For our database we are going to use the following script:

-- Security Incident Portal Database Schema
-- Production-ready schema for MySQL 8.0+
-- Database: SecurityIncidentPortal

-- Create the database if it doesn't exist
CREATE DATABASE IF NOT EXISTS SecurityIncidentPortal CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE SecurityIncidentPortal;

-- Main requests table for security incidents
CREATE TABLE requests (
    id VARCHAR(50) PRIMARY KEY,
    user_id VARCHAR(100) NOT NULL,
    user_info JSON NOT NULL,
    form_data JSON,
    request_type VARCHAR(50) NOT NULL,
    details JSON,
    reason TEXT,
    request_status VARCHAR(20) DEFAULT 'pending',
    priority_level VARCHAR(20) DEFAULT 'normal',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    approved_at TIMESTAMP NULL,
    completed_at TIMESTAMP NULL,
    assigned_to VARCHAR(100),
    assigned_by VARCHAR(100),

    INDEX idx_user_id (user_id),
    INDEX idx_request_type (request_type),
    INDEX idx_request_status (request_status),
    INDEX idx_priority_level (priority_level),
    INDEX idx_created_at (created_at),
    INDEX idx_assigned_to (assigned_to),

    CONSTRAINT chk_request_status 
      CHECK (request_status IN ('open', 'in-progress', 'resolved', 'closed')),
    CONSTRAINT chk_priority_level 
      CHECK (priority_level IN ('low', 'medium', 'high', 'critical')),
    CONSTRAINT chk_request_type
      CHECK (request_type IN (
        'phishing-email','suspicious-website','social-engineering',
        'malware','data-breach','identity-theft','other','phishing-report'
      ))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- Comments table for request discussions
CREATE TABLE request_comments (
    id VARCHAR(50) PRIMARY KEY,
    request_id VARCHAR(50) NOT NULL,
    user_id VARCHAR(100) NOT NULL,
    user_name VARCHAR(200) NOT NULL,
    message TEXT NOT NULL,
    is_internal BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    FOREIGN KEY (request_id) REFERENCES requests(id) ON DELETE CASCADE,
    INDEX idx_request_id (request_id),
    INDEX idx_user_id (user_id),
    INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- User roles table - For caching user roles and permissions
CREATE TABLE user_roles (
    user_id VARCHAR(100) PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    user_name VARCHAR(200),
    user_role VARCHAR(20) DEFAULT 'user',
    permissions JSON,
    last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

    INDEX idx_email (email),
    INDEX idx_user_role (user_role),

    CHECK (user_role IN ('user', 'it-support', 'admin'))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- Request audit log table - For tracking changes
CREATE TABLE request_audit_log (
    id INT AUTO_INCREMENT PRIMARY KEY,
    request_id VARCHAR(50) NOT NULL,
    user_id VARCHAR(100) NOT NULL,
    action_type VARCHAR(50) NOT NULL,
    old_values JSON,
    new_values JSON,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    FOREIGN KEY (request_id) REFERENCES requests(id) ON DELETE CASCADE,

    INDEX idx_request_id (request_id),
    INDEX idx_user_id (user_id),
    INDEX idx_action_type (action_type),
    INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- Insert a single default admin (generic email)
INSERT INTO user_roles (user_id, email, user_name, user_role, permissions) VALUES
('admin-user', 'bolivar.llerena@company.net', 'Admin User', 'admin',
 JSON_ARRAY('request:create','request:view-own','request:view-all','request:approve','request:assign','request:delete','notification:send','user:manage','analytics:view'))
ON DUPLICATE KEY UPDATE 
    user_name = VALUES(user_name),
    user_role = VALUES(user_role),
    permissions = VALUES(permissions);

-- Comprehensive statistics view
CREATE VIEW request_stats AS
SELECT 
    COUNT(*) as total_requests,
    SUM(CASE WHEN request_status = 'open' THEN 1 ELSE 0 END) as open_count,
    SUM(CASE WHEN request_status = 'in-progress' THEN 1 ELSE 0 END) as in_progress_count,
    SUM(CASE WHEN request_status = 'resolved' THEN 1 ELSE 0 END) as resolved_count,
    SUM(CASE WHEN request_status = 'closed' THEN 1 ELSE 0 END) as closed_count,
    SUM(CASE WHEN DATE(created_at) = CURDATE() THEN 1 ELSE 0 END) as today_count,
    SUM(CASE WHEN created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY) THEN 1 ELSE 0 END) as week_count,
    SUM(CASE WHEN created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) THEN 1 ELSE 0 END) as month_count,
    SUM(CASE WHEN request_type = 'phishing-email' THEN 1 ELSE 0 END) as phishing_email_count,
    SUM(CASE WHEN request_type = 'suspicious-website' THEN 1 ELSE 0 END) as suspicious_website_count,
    SUM(CASE WHEN request_type = 'social-engineering' THEN 1 ELSE 0 END) as social_engineering_count,
    SUM(CASE WHEN request_type = 'malware' THEN 1 ELSE 0 END) as malware_count,
    SUM(CASE WHEN request_type = 'data-breach' THEN 1 ELSE 0 END) as data_breach_count,
    SUM(CASE WHEN request_type = 'identity-theft' THEN 1 ELSE 0 END) as identity_theft_count,
    SUM(CASE WHEN request_type = 'other' THEN 1 ELSE 0 END) as other_count,
    SUM(CASE WHEN request_type = 'phishing-report' THEN 1 ELSE 0 END) as phishing_report_count,
    SUM(CASE WHEN priority_level = 'low' THEN 1 ELSE 0 END) as priority_low_count,
    SUM(CASE WHEN priority_level = 'medium' THEN 1 ELSE 0 END) as priority_medium_count,
    SUM(CASE WHEN priority_level = 'high' THEN 1 ELSE 0 END) as priority_high_count,
    SUM(CASE WHEN priority_level = 'critical' THEN 1 ELSE 0 END) as priority_critical_count,
    SUM(CASE WHEN request_type IN (
        'phishing-email','suspicious-website','social-engineering',
        'malware','data-breach','identity-theft','phishing-report','other'
    ) THEN 1 ELSE 0 END) as security_incidents_count,
    ROUND(AVG(CASE 
        WHEN request_status IN ('completed','resolved','closed') AND 
             (completed_at IS NOT NULL OR updated_at IS NOT NULL)
        THEN TIMESTAMPDIFF(HOUR, created_at, COALESCE(completed_at, updated_at))
        ELSE NULL 
    END), 2) as avg_processing_time_hours
FROM requests;

The SQL script defines normalized tables for incidents (requests), threaded discussions (request_comments), role-based access (user_roles), and an immutable change history (request_audit_log). It adds strategic indexes and CHECK constraints for data integrity and query performance, builds a request_stats view that powers dashboards (status/type/priority/time-window counts and average processing time), seeds an admin account,

With this script we fill basically use for the following API:

User should be able to fill a form with required and optional fields from different type such as string, timestamp, floats, emails
User should have two roles user and admin, admin is the only role that is capable of viewing the dashboard, add investigation notes and set incident reports to solved, canceled or closed
User should be able to see a small metric on how many reports exist, how many are critical, how many are solved

With this in mind we are going to proceed to create our RDS database and our lambda.

In the AWS Console, we search for Aurora and RDS > Databases > Create Database, for this example we are going to use MYSQL in a free tier environment with engine 8.0.x

As a good practice we should use secrets manager to manage our database password, this also enables us to program password rotation and other neat stuff.

For the instance type a t4g.micro is good enough depending on our workload, and the size feel free to edit it to your needs

For other configurations select your database vpc, feel free to tune your logs, backup and maintance window, after configuring and creating the database proceed to execute the .sql script.

Now we can create our lambda, we search for the service called Lambda > Create Function.

For our lambda, give it a name like security-api, let the lambda create the execution role and be sure to enable Function URL and VPC (if your database is not public)

Now for our lambda upload the code provided in the github repository at the end of this article and copy the url this url should be the one that needs to be replaced at our frontend

Note: The lambda uses environment variables however it is recommended to use secrets manager and handle this access through code.

Finally we have our security incident portal ready to go !

Lessons learned and a conclusion

While Kiro is a powerful tool that can help developers accelerate their SDLC process, it still requires close supervision. There is significant feedback and debugging needed, such as addressing unnecessary functions, security concerns, and a lack of unit tests. These challenges, however, can be mitigated by following a proper SDLC process, using Kiro to support each phase and ensuring a solid PRD is in place. I’m excited to see what the future holds there is still much potential yet to be revealed !

Repositories

Frontend
Backend

Implementing OWIN Authentication with Microsoft Entra ID in ASP.NET Framework

David💻 — Wed, 10 Sep 2025 02:26:15 +0000

This article purpose is to describe how to secure your ASP.NET Framework application using OWIN middleware and Microsoft Entra ID (Azure AD) authentication. This comprehensive guide walks you through creating protected endpoints while maintaining public health checks for load balancers.

Requirements

Visual Studio 2022
Azure Subscription

Walkthrough

Creating the App Service

Within our Azure subscription, we will create an App Service of type Web App.
In the template, we will fill in basic data:

Select our Azure subscription
Create a resource group if one doesn't already exist
Give our application a name
We will publish the code directly from Visual Studio 2022
Our Runtime will be ASP.NET V4.8
Choose the Region and plan that best suits our needs
For this example, we will select a less crowded region and proceed with the Free plan

Proceed with the "Review + Create" option.

Configuring the Default Domain

After our service has been created, we will navigate to the dashboard and copy the "Default Domain" value.

Registering the Application in Microsoft Entra ID

Now we will navigate within our Azure Portal to Microsoft Entra ID > Manage > App Registrations.
Within this window, we will register the application by clicking the "New Registration" option.

In this window, we will:

Register the name of our application
Define which Tenants can access the application
Register the URI by copying the App Service application URL as "Web"

Configuring Authentication

After having our application registered, in the same dashboard of our registered application, we navigate to Manage > Authentication.

In this window, we will activate the following options:

ID tokens (used for implicit and hybrid flows)
Access tokens (used for implicit and hybrid flows)

Creating the Application in Visual Studio 2022

We will create a new project with the following template:

ASP.NET Web Application (.NET Framework)
Select runtime: .NET Framework 4.8

In the next window:

Select type: MVC
Authentication: None (because Azure will handle the authentication)
Uncheck "Configure for HTTPS"

Installing Required Dependencies

Now we will proceed to install the necessary dependencies to run the project. Within the project:

Right-click > Manage NuGet Packages for Solution

Search for and install the following packages:

Microsoft.Owin.Security.OpenIdConnect
Microsoft.Owin.Security.Cookies
Microsoft.Owin.Host.SystemWeb
Microsoft.IdentityModel.Protocols.OpenIdConnect

Modifying Web.Config

After installing our dependencies, we start by modifying the Web.Config file.
Within appSettings, we proceed to modify the following values.

From Microsoft Entra ID, in App registrations, we look for our application and copy the following values:

ClientID
TenantID
RedirectUri (that we configured in App Service)

<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="ida:ClientId" value="<your-client-id>" />
  <add key="ida:Authority" value="https://login.microsoftonline.com/<your-tenant-id>/v2.0" />
  <add key="ida:RedirectUri" value="https://<your-application>.azurewebsites.net/" />
</appSettings>
<system.web>
  <authentication mode="None" />
  <compilation debug="true" targetFramework="4.8" />
  <httpRuntime targetFramework="4.8" />
  <customErrors mode="Off"/>
</system.web>

Creating Startup.cs

Now we will proceed with the creation of a file in the root called Startup.cs. What this file does is basically provide authentication control that sits in front of all requests.

using Microsoft.Owin;
using Microsoft.Owin.Security;
using Microsoft.Owin.Security.Cookies;
using Microsoft.Owin.Security.OpenIdConnect;
using Owin;
using System.Configuration;

[assembly: OwinStartup(typeof(TestAuthApplication.Startup))]

namespace TestAuthApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

            app.UseCookieAuthentication(new CookieAuthenticationOptions());

            app.UseOpenIdConnectAuthentication(
                new OpenIdConnectAuthenticationOptions
                {
                    ClientId = ConfigurationManager.AppSettings["ida:ClientId"],
                    Authority = ConfigurationManager.AppSettings["ida:Authority"],
                    RedirectUri = ConfigurationManager.AppSettings["ida:RedirectUri"],
                    ResponseType = "code id_token",
                    Scope = "openid profile email",
                    TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
                    {
                        ValidateIssuer = false
                    }
                });
        }
    }
}

Creating Controllers

Now we proceed to create two controllers: a health check which will allow us to return a 200 response to the load balancer without needing authentication, and a protected page.

HealthCheckController.cs (No Authentication Required)

Within Controllers > HealthCheckController.cs:

using System;
using System.Web.Mvc;

namespace TestAuthApplication.Controllers
{
    [AllowAnonymous]
    public class HealthCheckController : Controller
    {
        public ActionResult Index()
        {
            return Json(new
            {
                status = "healthy",
                timestamp = DateTime.UtcNow,
                service = "TestAuthApplication"
            }, JsonRequestBehavior.AllowGet);
        }

        public ActionResult Ping()
        {
            return Content("OK");
        }
    }
}

To prevent authentication, we define [AllowAnonymous].

ProtectedController.cs (Authentication Required)

Now we will proceed to create a protected page in Controllers > ProtectedController.cs:

using System.Web.Mvc;

namespace TestAuthApplication.Controllers
{
    [Authorize]
    public class ProtectedController : Controller
    {
        public ActionResult Index()
        {
            ViewBag.UserName = User.Identity.Name;
            return View();
        }

        public ActionResult SecureData()
        {
            return Json(new
            {
                message = "This is protected data",
                user = User.Identity.Name
            }, JsonRequestBehavior.AllowGet);
        }
    }
}

To require authentication, we define [Authorize].

Creating the View

Additionally, we can add a view for this in Views > Protected > Index.cshtml:

@{
    ViewBag.Title = "Protected Page";
}

<h2>Protected Page - Authentication Successful!</h2>
<p>Welcome, @User.Identity.Name!</p>
<p>You are successfully authenticated.</p>
<p>This page requires authentication to access.</p>

Publishing to Azure

With our project ready, we will now proceed to publish it:

Right-click on the project > Publish > Azure
Authenticate with the user account that has access to our Azure subscription
Select our resource group and app service
Click Publish

Testing the Application

Finally, we verify the access:

Page without authentication requirement

Health check endpoint should return 200 without login

User authenticated in the tenant

Successfully accesses protected pages

User authenticated but not in the tenant

Receives access denied message

Summary

Public endpoints (health check) that don't require authentication
Protected endpoints that require Azure AD authentication
OWIN middleware handling the authentication flow
Integration with Azure App Service for hosting

Engines to get you started in your web-based gaming development

David💻 — Mon, 23 Sep 2024 08:48:16 +0000

This is a submission for the Web Game Challenge: One Byte Explainer

Explainer

ct.js (openSource2D): Visual scripting language
Babylon.js (3DHTML): WebGL for high-quality 3D scenes
Phaser (openSource2D): Vast plugin ecosystem
nunuStudio (openSource, three.js): Node based language
RPG Maker (free non-commercial): Event system language

Additional Context

These engines can help get you kickstarted, most of them are friendly but powerful with a step learning curve, with a strong community behind them.

Create an AWS EKS Fargate v1.30 and play Prince Of Persia !

David💻 — Wed, 18 Sep 2024 16:35:13 +0000

In this article, I will provide a step by step guide on how to create an EKS cluster using eksctl (v1.30). I will also demonstrate how to deploy a game based on the MS-DOS version of Prince of Persia.

Requirements

AWS account / AWS CLI
Github account or any git repository
Docker
eksctl
helm

Walkthrough

Open Cloud Shell service in AWS.
If not already, install eksctl with the following command:

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin

Now, let's proceed to create our cluster with version 1.30, using fargate. Run the following command. (Be sure to create your cluster in the same region as your VPC)

eksctl create cluster --name gaming-cluster --version 1.30 --region us-east-1 --fargate

If you want to create your cluster in a specific VPC be sure to specify the corresponding subnets (otherwise this command is going to create a vpc dedicated to the eks)

eksctl create cluster --name gaming-cluster --version 1.30 --region us-east-1 --fargate --vpc-private-subnets subnet-private-1, subnet-private-2

This process might take around 20~25+ minutes.

Now let's associate an oidc provider in our cluster.

eksctl utils associate-iam-oidc-provider --region us-east-1 --cluster gaming-cluster --approve

Our cluster is now ready with a default fargate profile that contains the namespace default and kube-system

Let's create a fargate profile for our game application. (Be sure to also create the ns inside our k8s cluster)

eksctl create fargateprofile \
  --cluster gaming-cluster \
  --name fp-gaming \
  --namespace gaming \
  --region us-east-1

Now, let's add the AWS Load Balancer Controller to expose our application using AWS load balancers.

To do this we need to create an iam policy, a serviceaccount and install the plugin with helm.

Take this IAM policy example:

curl -o iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json

Create the IAM policy

aws iam create-policy \
    --policy-name AWSLoadBalancerControllerIAMPolicy-EKS \
    --policy-document file://iam-policy.json

Now let's create a service account for this controller

eksctl create iamserviceaccount --cluster=gaming-cluster --namespace=kube-system --name=aws-load-balancer-controller --attach-policy-arn=arn:aws:iam::<account_id>:policy/AWSLoadBalancerControllerIAMPolicy-EKS --approve

Great ! Now is helm turn, to install some useful charts, in this case the aws load balancer controller.

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Run the following commands:

helm repo add eks https://aws.github.io/eks-charts

kubectl apply -k "github.com/aws/eks-charts/stable/aws-load-balancer-controller/crds?ref=master"

helm upgrade -i aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=gaming-cluster --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller --set vpcId=<the same vpc as the cluster>

Awesome now we can access our cluster

aws eks update-kubeconfig  --name gaming-cluster --region us-east-1

Before we proceed let's create our gaming namespace

kubectl create ns gaming

We are almost there, now is the game turn.

For this I'm going to use this fork thanks to oklemenz, ultrabolido and jmechner

git clone https://github.com/bdllerena/PrinceJS

After cloning our image make sure to create an ECR repository (or use any of your choice to host our Prince of Persia image)

Now copy the push command, it should look like this

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.us-east-1.amazonaws.com

Inside our repository there should be a Dockerfile that looks like this.

Note: We use the --platform=linux/amd64 flag because our Kubernetes cluster supports this platform. Otherwise, if we build the Docker image with tools like Docker Desktop, it will make the image compatible with the local OS instead.

FROM --platform=linux/amd64 node:18

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080

CMD ["npm", "start"]

Inside our repository execute the following commands

docker build -t prince-of-persia .

After we built our image let's tag it and push it to ECR

docker tag prince-of-persia:latest <account_id>.dkr.ecr.us-east-1.amazonaws.com/prince-of-persia:latest    
docker push <account_id>.dkr.ecr.us-east-1.amazonaws.com/prince-of-persia:latest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prince-of-persia
  namespace: gaming
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prince-of-persia
  template:
    metadata:
      labels:
        app: prince-of-persia
    spec:
      containers:
        - name: prince-of-persia
          image: <account_id>.dkr.ecr.us-east-1.amazonaws.com/prince-of-persia:latest
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-type: external
  name: prince-of-persia
  namespace: gaming
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: prince-of-persia
  type: LoadBalancer

After checking that our image is the same that we pushed to ECR, execute our manifest !

kubectl apply -f manifest.yaml

This manifest is going to create a deployment with 1 replica (1 pod) and a service that creates a network load balancer as client-facing (public)

After some minutes, check if the service was created with this command

kubectl get svc -n gaming

Awesome ! if you want you can check the logs of the pod, and see if everything is up and running

kubectl get pods -n gaming
kubectl logs -f prince-of-persia-.... -n gaming

Finally let's enjoy our game by going to the svc that we created previously, it should look a bit like this

k8s-gaming-princeof-15fa57ff31-6933c5aaecd54910.elb.us-east-1.amazonaws.com

Optional

If you want to enable logging of your pods follow this steps

Create a namespace for aws-observability, and a fargate profile

kubectl create ns aws-observability

eksctl create fargateprofile \
  --cluster gaming-cluster \
  --name fp-observability \
  --namespace aws-observability \
  --region us-east-1

Verify that the execution role of this fargate profile has the necessary permissions to execute logs event into cloudwatch, otherwise create an inline policy inside that role with the following permissions.

Note: Be sure to add the specific name of the log group you are going to use

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:CreateLogGroup",
                "logs:DescribeLogStreams",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Now create a configmap like this an apply it, be sure to modify per your requirements, this configmap is going to start logging at a log group in cloudwatch named gaming-cluster

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-logging
  namespace: aws-observability
data:
  flb_log_cw: "false"  # set to true to ship Fluent Bit process logs to CloudWatch.

  filters.conf: |
    [FILTER]
        Name parser
        Match *
        Key_name log
        Parser crio
    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        Keep_Log Off
        Buffer_Size 0
        Kube_Meta_Cache_TTL 300s

  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match kube.*
        region us-east-1
        log_group_name gaming-cluster
        log_stream_prefix from-fluent-bit-
        log_retention_days 60
        auto_create_group true

  parsers.conf: |
    [PARSER]
        Name crio
        Format Regex
        Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$
        Time_Key time
        Time_Format %Y-%m-%dT%H:%M:%S.%L%z

kubectl apply -f observability.yaml

Be sure to rollout restart your deployments !

kubectl rollout restart deployment prince-of-persia -n gaming

Note: Is it recommended to only filter what is critical, modify the retention of the log group as it can get costly to get tons of logs

Hope this guide can be helpful ! Happy gaming !

Automate IT Operations with Nylas and Amazon Bedrock

David💻 — Tue, 03 Sep 2024 03:31:06 +0000

This article explores how IT operations can leverage Nylas APIs, AWS Lambda, and Amazon Bedrock to automate repetitive tasks and manage brief requirement queries efficiently. By integrating a Knowledge Base with Retrieval-Augmented Generation (RAG), the solution enables quick and accurate responses to common operational requests, streamlining processes and improving SLA compliance. This approach reduces onboarding time for new staff, enhances efficiency, and ensures that routine tasks are handled precisely, freeing up valuable time for more complex issues

What is a Knowledge Base?

A Knowledge Base in Amazon Bedrock, often used with Retrieval-Augmented Generation (RAG), is a structured repository of information that enhances the ability of AI models to generate accurate responses by pulling relevant data during the response process. RAG combines generative AI with specific data retrieval from the knowledge base, allowing the AI to generate contextually accurate and up-to-date answers, which is particularly useful in handling dynamic and domain-specific queries

What is Nylas?

Nylas is a platform that provides APIs for email, calendar, and contact management, enabling developers to seamlessly integrate communication capabilities into their applications. Nylas simplifies the process of reading, sending, and managing emails, scheduling calendar events, and accessing contact data from various providers, allowing businesses to automate workflows, improve productivity, and enhance communication processes with minimal backend setup

Requirements

AWS Account
Nylas Account
Gmail or any email account

Walkthrough

First, start by enabling your email account with Nylas. You need to enable your Grant ID and API Token be sure to note these values !

Next, inside your AWS Account, create an S3 bucket. It is fine to use the standard options; no extra configurations are necessary. After creating the S3 bucket, upload some PDF files for your knowledge base. For this, I created some examples that look like this:

How to Turn Off Instances in EC2
Step 1: Access the EC2 Dashboard
● Go to the AWS Management Console.
● Navigate to EC2 by searching for it in the search bar or selecting it from the list of AWS
services.
Step 2: Identify the Instance to Stop
● In the EC2 Dashboard, go to the Instances section.
● Look for the instance you wish to stop. You can use the search bar to filter by instance
ID, name, or other attributes.
Step 3: Check the Tags of the Instance
● Select the instance and go to the Tags tab.
● Look for a tag called "CanItBeTurnedOff". Ensure its value is "true". If the tag
does not exist or the value is not "true", do not turn off this instance.
Step 4: Stop the Instance
● If the tag value is "true", click on the Actions dropdown menu at the top right.
● Select Instance State > Stop Instance.
Step 5: Confirm the Action
● Confirm your choice in the popup dialog. The instance will begin to stop.
Step 6: Verify the Instance is Stopped
● Wait a few moments and refresh the instance state. Ensure the instance status is
stopped before proceeding with any other tasks.

Now, let's use the Knowledge Base service inside Amazon Bedrock. For the configurations, feel free to create or reuse a service role—it needs access to S3. For the Data Source, be sure to select S3

In the next window, be sure to select the S3 URI to the respective prefix or root folder where you uploaded your PDF examples

For the embedding model, I decided to use Amazon Titan Text Embedding v2 for its cost-effectiveness and reliability in determining vector dimensions

Review and create your model !

For testing, be sure to enable model access. I used Titan Text G1 - Premier

Now, our setup is almost ready to start writing the code, but before this, log in to your email account. For this example, I used Gmail

Inside Gmail, be sure to create or have at least one contact. The purpose of this contact is to showcase how we can scale requirements that the Knowledge Base can't respond to, involving a human counterpart who can guide us on properly executing the requirement

Great ! We have everything set up. Now let's create the code!

This code connects the query from your emails, sends that query (in this example, the email subject) to the Knowledge Base, and returns a response based on the documents in your S3. If the model can't respond, it escalates the requirement to an "N2" support account or another person with more experience

Variables:
NYLAS_API_KEY = Your Nylas api key
NYLAS_GRANT_ID = Grant ID
SUPPORT_EMAIL_N1 = The email you used in Nylas
AWS_REGION = The region where the knowledge base is
BEDROCK_MODEL_ARN = The model of the model you gave access to (In this case Amazon Premier Text, it should look a bit like this: arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-text-premier-v1:0
KNOWLEDGE_BASE_ID = The knowledge base ID that you created

from nylas import Client
from nylas.models.messages import ListMessagesQueryParams
from nylas.models.contacts import ListContactsQueryParams
import boto3
import os

nylas = Client(api_key=os.environ.get('NYLAS_API_KEY'))

# bedrock configuration be sure to create your knowledge base beforehand
region_name = os.environ.get('AWS_REGION')
model_arn = os.environ.get('BEDROCK_MODEL_ARN')
kb_id = os.environ.get('KNOWLEDGE_BASE_ID')
bedrock_agent_runtime_client = boto3.client("bedrock-agent-runtime", region_name=region_name)

# generate a response asking our RAG with the email content
def ask_bedrock_llm_with_knowledge_base(query: str) -> str:
    response = bedrock_agent_runtime_client.retrieve_and_generate(
        input={'text': query},
        retrieveAndGenerateConfiguration={
            'type': 'KNOWLEDGE_BASE',
            'knowledgeBaseConfiguration': {
                'knowledgeBaseId': kb_id,
                'modelArn': model_arn
            }
        }
    )
    return response.get('output', {}).get('text', 'No generated text found.')

# get this message if webhook nylas message.created is configured otherwise just pull the last message
def fetch_latest_message(nylas_client: Client, grant_id: str) -> list:
    query_params = ListMessagesQueryParams({'limit': 1})
    messages, _, _ = nylas_client.messages.list(grant_id, query_params)
    return messages

# you can fetch the contacts per company or description for this example we only have one contact
def fetch_contact(nylas_client: Client, grant_id: str) -> list:
    query_params = ListContactsQueryParams({'limit': 1})
    contacts, _, _ = nylas_client.contacts.list(grant_id, query_params)
    return contacts

def send_message(nylas_client: Client, grant_id: str, subject: str, body: str, recipient: str):
    request_body = {
        "subject": subject,
        "body": body,
        "to": [{"email": recipient}]
    }
    nylas_client.messages.send(grant_id, request_body=request_body)

def process_messages():
    grant_id = os.environ.get('NYLAS_GRANT_ID')
    messages = fetch_latest_message(nylas, grant_id)

    for message in messages:
        print(f"{message.subject}")
        response = ask_bedrock_llm_with_knowledge_base(message.subject)

        if "i could not find an exact answer to the question" in response.lower():
            contacts = fetch_contact(nylas, grant_id)
            for contact in contacts:
                send_message(
                    nylas,
                    grant_id,
                    f"Please {contact.given_name}, your help is needed with the following requirement",
                    message.subject,
                    contact.emails[0].email
                )
        else:
            send_message(
                nylas,
                grant_id,
                "Answer from RAG Model",
                response,
                os.environ.get('SUPPORT_EMAIL_N1')
            )


process_messages()

That's it ! If you want to get an idea on how this work be sure to check this post
Code is here

Nylas AI and Communications Challenge: Nylas and AIOps integration

David💻 — Mon, 02 Sep 2024 01:54:17 +0000

This is a submission for the Nylas Challenge: Galaxy Brain.

What we Built and Why

In IT operations, when a new user joins a team in a fast-paced industry, there often isn’t enough time for a thorough onboarding process. The constantly changing client requirements and evolving technologies make it challenging for new users to know how to proceed correctly, leading to missed SLAs or improperly executed processes.

That’s why we developed a solution to help streamline the learning curve for operations staff while handling basic or repetitive tasks, making the process smoother and more efficient.

Demo

Youtube Demo

Code

Github Code

Our Journey

We leveraged Nylas' set of APIs to streamline the management of these requirements, as they often come via email. This allows us to easily read incoming emails and respond immediately with our RAG model. If the requirement is a simple or repetitive task, we automate the process using an AWS Step Function that handles the task efficiently.

With this easy, out-of-the-box solution, we improve our SLA times significantly.

Credits:
@davidshaek
@steven_aizaga

Nylas AI and Communications Challenge: Nylas and AIOps integration

David💻 — Mon, 02 Sep 2024 01:53:36 +0000

This is a submission for the Nylas Challenge: AI Expedition.

What we Built and Why

That’s why we developed a solution to help streamline the learning curve for operations staff while handling basic or repetitive tasks, making the process smoother and more efficient.

Demo

Youtube Demo

Code

Github Code

Our Journey

With this easy, out-of-the-box solution, we improve our SLA times significantly.

Credits:
@davidshaek
@steven_aizaga

Forem: David💻

The AWS Badge-Dex: An Almost Complete Guide for 2026

AWS Certified Early Adopter

AWS Microcredentials

AWS Ambassador

AWS Quest

AWS re/Start

AWS Instructor

AWS Subject Matter Expert

AWS Educate

AWS Academy

AWS Solutions-Focused Immersion Days (Builders Quest)

AWS Knowledge (Skillbuilder)

AWS Certified

AWS Partner

AWS Cloud Club Captain

AWS Support Engineer

AWS Worldwide Field Enablement

AWS Builders League

AWS AWSome Awards

Other Badges

Implementing a Secure Data Governance Architecture on AWS with S3, Glue, Athena, and Lake Formation

The proposed architecture

Walkthrough

S3 Configuration and Security Controls

S3 Bucket Policy – Enforcing Security

Enabling Access Logging

Building the Data Catalog in AWS Glue

Adding Traceability with AWS CloudTrail

Applying Data Access Controls with Lake Formation

Querying Data with Amazon Athena

Visualizing Insights with Amazon QuickSight

Cost Estimation

Conclusion

Implementing OWIN Authentication and roles for AppService in ASP.NET Framework

Walkthrough

Creating the App Service

Configuring the Default Domain

Registering the Application in Microsoft Entra ID

Configuring Authentication

Creating the Application in Visual Studio 2022

Installing Required Dependencies

Modifying Web.Config

Creating Startup.cs

Creating Startup.Auth.cs

Creating Controllers

Publishing to Azure

Testing the Application

Summary

Automating EBS Volume Upsizing on AWS

The Problem

Walkthrough

Accesing through Sessiong Manager

Installing Amazon Cloudwatch Agent in EC2 AL2023

Lessons learned and a conclusion

Protecting our EKS Nodes with Wazuh

What is Wazuh?

Requirements

What is AWS Client VPN?

Walkthrough

Creating the VPC

Segmentation

The Peering between VPC

Certificates with ACM PCA

Security Groups

SG for Client VPN:

SG for Wazuh Server

Create Client VPN Endpoint

Launch Wazuh All-in-One

Configure the VPN Client

Test Access

Installing Wazuh in our EKS Node

Lessons learned and a conclusion

Creating a Security Incident Portal with Kiro and AWS

The proposed architecture

What is Kiro?

What is Vibe coding?

Kiro Vibe Mode vs Spec

Walkthrough

Something about the risk of Autopilot