DEV Community: Disha Gupta

AWS Kiro: The Future of AI-Powered Software Development

Disha Gupta — Tue, 19 May 2026 16:21:04 +0000

The software development industry is entering a new era where Artificial Intelligence is becoming deeply integrated into coding workflows. One of the latest innovations in this field is AWS Kiro, an AI-powered agentic Integrated Development Environment (IDE) introduced by Amazon Web Services (AWS).

Unlike traditional AI coding assistants that mainly generate code snippets or autocomplete suggestions, AWS Kiro focuses on spec-driven development. It helps developers transform ideas into structured specifications, implementation plans, production-ready code, automated tests, and documentation.

Kiro is designed for:

Software developers
DevOps engineers
Cloud architects
Security professionals
Enterprise engineering teams

Its goal is to reduce repetitive work while improving software quality and development speed.

What is AWS Kiro?

According to AWS documentation, Kiro is an “agentic coding environment” that works as an intelligent software engineering partner. It combines AI reasoning, automation, and cloud-native workflows to assist developers throughout the entire software lifecycle.

Kiro is built on AWS AI technologies and integrates with:

Amazon Bedrock
Cloud services
APIs
Infrastructure tools
Development pipelines

It supports:

AI-assisted coding
Automated debugging
Documentation generation
Software planning
Unit testing
Architecture design
Workflow automation

AWS positions Kiro as a next-generation development platform rather than just a chatbot for coding.

Key Features of AWS Kiro

1. Spec-Driven Development

One of Kiro’s biggest innovations is its structured workflow approach.

Instead of directly generating random code from prompts, Kiro first creates:

Requirements
Design specifications
Task breakdowns
Test plans
Documentation

This helps teams maintain cleaner architecture and avoid technical debt.

Example Workflow

Feature Request:
  Build a secure login system

Kiro Generates:
  - Requirements document
  - API design
  - Database schema
  - Authentication flow
  - Unit tests
  - Deployment checklist

This structured process makes software development more reliable and scalable.

2. AI Coding Agents

Kiro includes autonomous AI agents capable of handling development tasks with minimal supervision.

These agents can:

Write production-ready code
Refactor applications
Generate test cases
Analyze bugs
Review pull requests
Maintain project context

This reduces developer workload and accelerates project delivery.

Example Python Snippet Generated by AI

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/health')
def health_check():
    return jsonify({"status": "healthy"})

if __name__ == '__main__':
    app.run(debug=True)

Kiro can also explain the code, generate tests for it, and suggest deployment configurations automatically.

3. Deep AWS Integration

Kiro is especially useful for cloud-native development because of its integration with AWS services.

It can assist with:

AWS Lambda
Amazon EC2
Amazon S3
Kubernetes
Infrastructure as Code
CI/CD pipelines
Security configurations

For DevOps engineers, this means faster automation and infrastructure deployment.

Example Terraform Configuration

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "demo_bucket" {
  bucket = "kiro-demo-bucket"
}

Kiro can generate, validate, and optimize infrastructure code like this automatically.

VS Code Compatibility

AWS Kiro is based on Code OSS, which means developers familiar with Visual Studio Code can easily adapt to it.

It supports:

Themes
Extensions
Keyboard shortcuts
Developer plugins

This reduces the learning curve for developers transitioning from traditional IDEs.

Automated Testing and Documentation

A major challenge in software engineering is maintaining proper documentation and testing coverage. Kiro automates both.

Example Unit Test

def test_health_check(client):
    response = client.get('/health')
    assert response.status_code == 200

Kiro can:

Generate unit tests
Create API documentation
Produce architecture summaries
Suggest security improvements

This improves software reliability and reduces manual effort.

Benefits of AWS Kiro

Faster Development

AI-powered automation significantly reduces coding time.

Better Software Quality

Structured specifications and automated testing improve reliability.

Reduced Technical Debt

Spec-driven workflows encourage better architecture and planning.

Improved Collaboration

Teams can work from shared specifications and generated documentation.

Ideal for DevOps and Cloud Engineers

Kiro is especially powerful for:

Kubernetes workflows
AWS deployments
Infrastructure automation
CI/CD pipelines
DevSecOps practices

For students learning cloud and DevOps, Kiro can act as an intelligent learning assistant.

Challenges and Limitations

Despite its capabilities, Kiro still has limitations.

Some developers reported issues such as:

Incorrect implementations
Hallucinated code
Context confusion
Over-automation risks

AI-generated code still requires:

Human review
Security validation
Architecture oversight

This means Kiro should be treated as an intelligent assistant rather than a complete replacement for software engineers.

AWS Kiro vs Traditional AI Coding Tools

Feature	AWS Kiro	Traditional AI Coding Assistants
Development Style	Spec-driven	Prompt-driven
Documentation	Automatic	Limited
Testing	Integrated	Partial
Cloud Integration	Deep AWS support	Basic
Autonomous Agents	Yes	Limited
Project Planning	Built-in	Minimal
Enterprise Focus	Strong	Moderate

Future of AI Development

AWS Kiro represents a shift toward autonomous software engineering, where AI systems assist developers throughout the entire development lifecycle.

In the future, tools like Kiro may become central to:

Cloud-native engineering
DevSecOps automation
AI-assisted infrastructure management
Enterprise software delivery

As AI technology evolves, developers who understand both cloud computing and AI-assisted development tools will likely have a strong advantage in the industry.

Conclusion

AWS Kiro is more than just another coding assistant. It introduces a structured, AI-driven approach to software engineering that combines planning, coding, testing, and documentation into a unified workflow.

By focusing on specification-driven development and autonomous AI agents, Kiro aims to improve software quality, reduce technical debt, and accelerate cloud-native development.

For developers, DevOps engineers, and students interested in cloud computing and AI-powered development, AWS Kiro represents an exciting glimpse into the future of software engineering.

How I Built an AI-Powered Cloud Security Guardian using AWS — From Idea to Docker in 30 Days

Disha Gupta — Thu, 14 May 2026 19:03:31 +0000

How I Built an AI-Powered Cloud Security Guardian — From Idea to Docker in 30 Days
By Disha Gupta |(Cloud Security & GRC) |https://www.linkedin.com/in/disha-gupta-6588102b9/

The Problem That Kept Me Up at Night

Every week I read another breach report. Misconfigured S3 bucket. IAM user with Administrator Access left active. SSH port 22 open to 0.0.0.0/0. Security groups that nobody audited in six months.

The frustrating part? These aren't sophisticated zero-days. They're checklist failures. Things that should have been caught automatically.

So I decided to build the tool I wished existed — one that could scan any AWS account on demand, apply machine learning to risk-score every resource, detect anomalies in CloudTrail logs, and surface remediation advice in real time. I called it "AI Cloud Security Guardian".

Here's exactly how I built it, what each AWS service does in the architecture, and what I learned the hard way.

What the Platform Does

Before getting into the technical stack, here's what Guardian actually does when you use it:

You log into the SOC-themed dashboard
You enter your AWS IAM credentials — they're never stored, only used for that session
Guardian connects to your AWS account via boto3 and discovers every EC2 instance, S3 bucket, IAM user, IAM role, and security group
A rule engine runs 9 misconfiguration checks against every resource
A Random Forest ML model scores each resource from 0.0 to 1.0 based on 6 security features
An Isolation Forest model runs anomaly detection on CloudTrail logs
Alerts are generated, prioritized by severity, and surfaced in the dashboard with AI-generated remediation steps

The entire backend is FastAPI + Python. The frontend is React + TypeScript + Tailwind. Everything runs in Docker. And it connects to real AWS accounts — not mocked data.

AWS Services Used and Why

AWS STS — GetCallerIdentity

The very first AWS API call Guardian makes is sts:GetCallerIdentity. Before scanning anything, it verifies that your credentials are valid and tells you exactly which account and IAM identity you're using.

sts = session.client("sts")
identity = sts.get_caller_identity()

Returns: Account ID, ARN, UserId

This is the cheapest possible AWS API call — it's always allowed for any valid credential, costs nothing, and gives us a fast-fail before running a 60-second full scan with bad keys. If this call fails, Guardian immediately tells you exactly why — invalid key, expired token, wrong region — instead of failing silently mid-scan.

What I learned: Always validate credentials with STS before any other AWS operation. It saves enormous debugging time and gives users clear error messages.

Amazon EC2 — DescribeInstances + DescribeSecurityGroups

For EC2, Guardian uses two boto3 calls:

DescribeInstances discovers every running instance and collects:

Instance ID, type, and state
Public IP (is it internet-exposed?)
Associated security group IDs
IAM instance profile (does it have proper permissions?)
Key pair name (is access documented?)

DescribeSecurityGroups checks every inbound rule for the most dangerous misconfiguration in AWS — port exposure to 0.0.0.0/0:

def _check_open_to_world(rules):
for rule in rules:
for ipv4 in rule.get("IpRanges", []):
if ipv4.get("CidrIp") == "0.0.0.0/0":
return True # CRITICAL finding
return False

When Guardian finds SSH (port 22) or RDP (port 3389) open to the entire internet, it fires a Critical alert immediately. This single check has caught the most serious findings in real account scans.

Detection rules triggered:

SG_001 — Open to 0.0.0.0/0 (Critical)
EC2_001 — Public IP with no IAM instance profile (Medium)
EC2_002 — Running instance with no key pair (Low)

Amazon S3 — Multi-API Bucket Analysis

S3 is where most data breaches start. Guardian runs five separate API calls per bucket:

API Call	What We Check	Severity if Missing
`get_public_access_block`	All 4 Block Public Access flags	Critical
`get_bucket_encryption`	SSE-S3 or SSE-KMS enabled	High
`get_bucket_logging`	Access logs configured	Medium
`get_bucket_versioning`	Object versioning enabled	Info
`get_bucket_location`	Region (for context)	—

The public access check is the most important. AWS has four separate flags for blocking public access (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets). Guardian checks that ALL four are enabled — if even one is False, the bucket is marked as potentially public:

fully_blocked = all([
cfg.get("BlockPublicAcls", False),
cfg.get("IgnorePublicAcls", False),
cfg.get("BlockPublicPolicy", False),
cfg.get("RestrictPublicBuckets", False),
])
data["is_public"] = not fully_blocked

What I learned: The absence of a public access block configuration is different from having it set to False. If get_public_access_block throws a NoSuchPublicAccessBlockConfiguration exception, the bucket has no protection at all — Guardian treats that as is_public = True.

AWS IAM — Privilege and MFA Analysis

IAM scanning is where Guardian finds the highest-severity issues. Three API calls cover the critical checks:

ListAttachedUserPolicies — checks every user for AdministratorAccess. One IAM user with full admin and no MFA is game over if their credentials leak.

ListMFADevices — for any user with console access, Guardian checks if MFA is enabled. No MFA on a console user is an automatic High finding.

GetLoginProfile — determines if a user has console access at all. Service accounts should never have console passwords.

The most dangerous combination in AWS:

Console access + AdministratorAccess + no MFA

if user.has_console_access and user.is_admin and not user.has_mfa:
# This is a three-alarm fire
generate_critical_alert(user)

The IAM scan also covers roles — any role with AdministratorAccess attached gets flagged as High, because a compromised EC2 instance or Lambda function with that role has unlimited blast radius.

Detection rules triggered:

IAM_001 — User with AdministratorAccess (Critical)
IAM_002 — Console user without MFA (High)
IAM_003 — Role with AdministratorAccess (High)

AWS CloudTrail — Log Analysis for Anomaly Detection

This is where the ML comes in. CloudTrail logs every API call made in your AWS account. Guardian ingests these events and runs them through an Isolation Forest — an unsupervised ML algorithm that identifies statistical outliers without needing labeled training data.

The feature extraction aggregates per-user behavior across a time window:

features = {
"api_call_count": 1, # volume of API calls
"failed_logins": 1, # AccessDenied errors
"hour_of_day": 3, # off-hours = suspicious
"is_new_region": True, # never seen this region before
"bytes_transferred": 0,
"unique_resources": 1,
}

Isolation Forest works by randomly partitioning the feature space. Anomalous data points — like a user suddenly making 5,000 API calls from a new region at 3 AM with 50 Access Denied errors — are isolated quickly because they're far from the normal distribution. The algorithm assigns an anomaly score where lower = more anomalous.

What Guardian flags:

Unusual API call volume (potential credential theft / cryptomining)
Access from a previously unseen AWS region (potential account takeover)
Off-hours access patterns (lateral movement)
Repeated AccessDenied errors (brute force / privilege escalation attempt)

Why Isolation Forest over supervised ML? Because you almost never have labeled "malicious" CloudTrail logs to train on. Isolation Forest requires no labels — it just learns what "normal" looks like and flags deviations. This is exactly how real SIEM tools work.

The ML Risk Scoring Engine

Beyond rule-based detection, every resource gets a continuous risk score from 0.0 to 1.0 using a "Random Forest classifier".

The model uses 6 features derived from each resource:

FEATURES = [
"public_access", # 0/1 — internet-exposed?
"open_ports", # count of world-open inbound rules
"encryption_enabled", # 0/1 — data encrypted at rest?
"iam_privilege_level", # 0=none, 1=read, 2=write, 3=admin
"mfa_enabled", # 0/1 — MFA enforced?
"logging_enabled", # 0/1 — audit trail active?
]

The model is trained on synthetic data at startup and saved to disk with joblib. In a production deployment with real historical findings, you'd replace the synthetic training data with actual labeled security findings from past scans — making the model progressively more accurate with each scan.

Risk levels:

Critical — score ≥ 0.75
High — score ≥ 0.55
Medium — score ≥ 0.35
Low — score ≥ 0.15
Minimal — score < 0.15

Security Architecture Decisions

Building a tool that handles AWS credentials forced me to think carefully about security at every layer.

Credentials Never Touch Storage

The most important design decision: AWS credentials are never stored anywhere. Not in the database. Not in logs. Not in the browser's localStorage. They exist only in:

The user's browser state (React useState) for the duration of the modal
The HTTP request body while in transit
Python function parameters during the scan
Cleared immediately after the scan completes

After scan completes — credentials go out of scope and are GC'd
def run_full_scan_with_credentials(access_key_id, secret_access_key, ...):
... scan happens ...
return result
access_key_id and secret_access_key are never written anywhere

The backend logs only the key prefix (AKIA...8chars...) for debugging — never the full key or secret.

JWT in Memory, Not localStorage

The dashboard JWT token lives in a module-level JavaScript variable — not localStorage or sessionStorage. This prevents XSS attacks from stealing the token, at the cost of losing the session on page refresh (acceptable for a security tool).

// In-memory only — XSS cannot read this via document.cookie or localStorage
let _accessToken: string | null = null

An auto-logout timer is set from the JWT's exp claim with a 30-second buffer. When the token is about to expire, the user is automatically logged out.

Input Validation at Every Layer

Frontend: Regex validation on the Access Key ID format, length checks on all fields
Backend: Pydantic field_validator on every credential field before any AWS call
JSON parsing: safeJsonParse() blocks __proto__ and constructor keys to prevent prototype pollution in user-submitted log data

The Tech Stack

Backend:

FastAPI — async Python web framework, auto-generates OpenAPI docs
SQLAlchemy + SQLite (dev) / PostgreSQL (prod) — ORM for findings storage
boto3 — AWS SDK, all credential operations
scikit-learn — Random Forest (risk scoring) + Isolation Forest (anomaly detection)
Pydantic v2 — request validation and settings management
JWT via python-jose — stateless authentication

Frontend:

React 18 + TypeScript — component framework
Tailwind CSS — utility-first styling with custom SOC terminal design tokens
React Query (TanStack) — server state management with caching
Recharts — risk score visualization (bar charts, donut charts, radar charts)
Axios — HTTP client with request/response interceptors
DOMPurify — XSS sanitization for any server-returned strings

DevOps:

Docker — multi-stage builds (builder → slim runtime) for both services
Docker Compose — orchestrates PostgreSQL + FastAPI + Nginx as one stack
Kubernetes — 7 manifests covering namespace, secrets, deployments, ingress, and HPA autoscaling
Nginx — reverse proxy in the frontend container, eliminates CORS entirely in production

Challenges and What I Actually Learned

Challenge 1: The Variable Name Collision That Caused Every Scan to 500

For days, every scan attempt returned a 500 Internal Server Error. The backend logs showed a TypeError: 'bool' is not callable. After hours of debugging, I found it:

BROKEN — parameter named scan_security_groups shadows the function
def run_full_scan(scan_security_groups: bool = True):
...
"security_groups": scan_security_groups(session) # calling a bool!

The function scan_security_groups() and the boolean parameter scan_security_groups had the same name. Python used the parameter, not the function. Fixed by prefixing all internal scanner functions with _do_:

"security_groups": _do_scan_security_groups(session) if scan_security_groups else []

Lesson: In Python, function parameters shadow module-level names within their scope. Name your parameters explicitly to avoid conflicts with functions they might call.

Challenge 2: CORS That Wasn't Actually CORS

The frontend was getting blocked by CORS policy — but the backend had allow_origins=["*"] set. After wasting an afternoon, I realized the issue: FastAPI's CORSMiddleware with allow_origins=["*"] is incompatible with allow_credentials=True. Setting both is illegal per the CORS spec and FastAPI silently breaks the middleware.

The final fix wasn't even CORS middleware — it was switching to a Vite proxy in development. The browser calls localhost:5173/api/scan/aws, Vite forwards it to localhost:8000/scan/aws server-side. The browser never makes a cross-origin request. CORS doesn't apply.

Lesson: The right fix for CORS in development is a proxy, not CORS headers. Save CORS configuration for production where you actually need it.

Challenge 3: TypeScript Strict Mode vs Docker Build

The code compiled fine locally with VS Code's TypeScript server being lenient. But the Docker build ran tsc in strict mode and found 15 errors — unused parameters, import.meta.env type issues, missing module declarations, type assertion errors.

The fix was a combination of:

Setting "strict": false and "noUnusedLocals": false in tsconfig.json for the build
Accessing import.meta.env via (import.meta as any).env to bypass the strict type check
Removing "references" from tsconfig.json so the build didn't look for tsconfig.node.json inside the Docker container

Lesson: Always test your Docker build on CI before you think you're done. Local TypeScript compilation and Docker-in-builder-stage compilation can behave very differently.

The Minimum IAM Policy

For anyone who wants to scan their own account, here's the exact minimum permission set needed:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:GetCallerIdentity",
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"s3:ListAllMyBuckets",
"s3:GetBucketPublicAccessBlock",
"s3:GetBucketEncryption",
"s3:GetBucketLogging",
"iam:ListUsers",
"iam:ListRoles",
"iam:ListMFADevices",
"iam:ListAttachedUserPolicies",
"iam:GetLoginProfile",
"cloudtrail:LookupEvents"
],
"Resource": "*"
}
]
}

Create a dedicated IAM user with only this policy. Never use root credentials or your personal admin account.

The full project — backend, frontend, Docker, and Kubernetes manifests — is on GitHub -https://github.com/Dianger16/AWS-CLOUD-SOC.git

Stack summary: FastAPI · boto3 · scikit-learn · React · TypeScript · Tailwind · Docker · Kubernetes

If you're working on cloud security, GRC, or DevSecOps and want to collaborate or discuss the architecture, I'm always open to connect.-"https://www.linkedin.com/in/disha-gupta-6588102b9/"