Using agentic AI to accelerate AWS architecture development and verification.

Enterprise cloud programs rarely fail because teams can’t build – they stall because teams can’t agree on what’s there. In our work with enterprises, we repeatedly see inherited platforms, inconsistent patterns and years of pragmatic fixes turn architecture decisions into assumptions that are hard to verify and even harder to repeat across environments.

Agentic AI can change that when paired with the right standards and governance. In this article, I share:

• How Kiro (an agentic, spec-driven IDE built on Amazon Bedrock) can help you modernise faster while improving architectural quality
• Why adopting an AI-driven development lifecycle (AI-DLC) is key to making these gains sustainable at enterprise scale

What’s Kiro?

Kiro is an agentic coding environment designed to take you from natural language intent to structured specifications (requirements, design and tasks) and then to working code, documentation and tests. Rather than relying on ‘prompt-and-pray', Kiro’s spec-driven workflow makes decisions explicit and reviewable.

It supports steering: persistent, human-readable markdown files that capture your conventions, patterns and standards so AI can apply them consistently across sessions and projects. In practice, Kiro behaves less like an autocomplete tool and more like a teammate that can help plan, implement and verify work – while keeping humans in control of critical decisions.

The problem: Enterprise AWS environments are fragmented and opaque

When we start an assessment, we rarely find a single, coherent ‘AWS environment’. Instead, we find a landscape – multiple accounts and regions, different network patterns (shared VPCs, isolated VPCs, transit gateways), varied identity models and a mix of platforms (containers, serverless, VMs, managed data services) operated with different maturity levels.

Add in a history of mergers and acquisitions, and you often have a patchwork of inherited landing zones, duplicated tooling, inconsistent security controls and undocumented dependencies between teams and workloads.

This comes with costs:

• Time is the immediate cost: Weeks spent interviewing teams, chasing diagrams and reconciling reality from repositories, tickets and configuration drift
• Delivery risk is the deeper cost: Without a reliable picture of what exists and why, it’s hard to demonstrate compliance, resilience and cost-efficiency – or to make changes confidently during migrations, landing zone evolution and platform consolidation

This is exactly the point where enterprise teams and their partners need a repeatable way to go from fragmented evidence to an agreed current state and a prioritised, verifiable improvement plan.

Using AI (and Kiro) to analyse, audit and verify architectures faster

AI becomes valuable in architecture work when it reduces ambiguity and increases throughput without removing accountability.

In practice, we use tools like Kiro to synthesise what’s scattered across repositories, runbooks, IaC, tickets and cloud inventories into the artefacts an architecture review can use – clear workload narratives, dependency summaries, ‘known unknowns’ and a focused set of questions for stakeholders. This accelerates the most expensive phase of modernisation: understanding the existing system well enough to change it safely.

A useful model we often apply is the AWS Well-Architected Framework Review: Preparation, Review, Improvement. Done well, a review is a structured, low-friction workshop focused on surfacing concrete risks and translating them into actions. AI can accelerate each phase:

• Preparation: It helps draft workload documentation and identify missing inputs
• Review: It helps structure evidence, flag inconsistencies and relate observations to best-practice questions (security, reliability, performance, cost, sustainability and operational excellence)
• Improvement: It turns findings into an actionable backlog of epics, tasks and verification steps that stay traceable to the original risks

Best practices for AI-assisted architecture development and verification

• Start with a reviewable spec, not a chat transcript: Capture intent as requirements, a design and a task plan so stakeholders can approve decisions before implementation begins
• Be explicit about evidence: If the AI claims ‘encryption is enabled’ or ‘RTO is met’, require the supporting configuration, policy, runbook or test output to be provided and reviewed.
• Use a consistent set of review questions: Anchor assessments to a known framework (like Well-Architected pillars) so outcomes remain comparable across teams and workloads
• Turn decisions into executable verification: Convert architecture requirements into automated checks wherever possible – IaC validation, policy-as-code guardrails, drift detection and repeatable test plans
• Keep discovery fast and decisions owned: Let AI accelerate inventory and synthesis but keep trade-offs (data classification, risk acceptance, recovery objectives, blast radius) explicitly owned and approved by accountable humans
• Deliver improvements iteratively: Give preference to a sequence of reversible changes with clear success criteria and rollback steps over a single high-risk rewrite
• Institutionalise learning: Feed review findings and post-incident learnings back into standards, templates and guardrails so every new project starts from a higher baseline

Standardisation with steering files: Making AI output consistent and repeatable

The biggest barrier to using AI in enterprise engineering is consistency, not capability. One team gets an excellent output, another gets something risky or off-pattern. In delivery organisations like ours, that variability is a non-starter: customers need predictable outcomes, and engineering teams need repeatable ways of working. This is where standardisation and context engineering matter.

Kiro’s steering files provide a practical mechanism: markdown documents that encode ‘how we do things here’, so the AI starts every engagement and project with the same baseline expectations. Steering can be applied per workspace (customer or workload-specific) and globally (Nordcloud-wide defaults), making reliable AI behaviour scalable across environments.

In practice, steering files can define clear personas (roles) and the expected artefacts and quality gates for each role. That means different teams (and different projects) can approach work in the same way, even when underlying customer environments vary.

Because steering is human-readable markdown, it becomes a bridge between engineering leadership and day-to-day execution – standards can be reviewed, versioned and improved like any other delivery artefact. For customers, this translates to consistent quality across multiple teams and workstreams. For delivery teams, it reduces onboarding time, avoids ‘hero knowledge’ and makes outcomes less dependent on who happens to be on the keyboard – while still allowing customer-specific nuance where it matters.

We often see value in maintaining ‘default hats’ for common delivery modes

• Software development mode: Defines coding standards, testing requirements, documentation expectations, dependency policies and what ‘done’ means (for example, unit tests required, ADR updates required, security checks must pass)
• Infrastructure development mode: Defines preferred IaC tooling, account/region conventions, tagging and cost allocation rules, baseline security controls, and the validation steps to run before merge (linting, policy checks, drift baselines)
• Architecture verification/review mode: Defines how to perform a structured assessment (questions to ask, evidence to collect, how to record risks, how to produce a prioritised improvement plan aligned to internal or AWS frameworks)
• Root cause analysis (RCA) mode: Defines a fact-first workflow that reproduces, captures timelines, forms and tests hypotheses, documents contributing factors, proposes remediations, and generates follow-up verification tests to prevent recurrence

Making it work at scale: Adopting an AI-DLC

To make AI effective in enterprises, teams typically need more than a tool, they need a way of working that is built for AI’s speed. AI-DLC reframes delivery so AI can execute systematically with human oversight, while humans focus on clarifying intent, approving key decisions and validating outcomes.

Instead of stretching traditional SDLC rituals to fit AI, AI-DLC encourages structured workflows like explicit specs, rapid clarification loops and continuous verification so quality doesn’t collapse under higher velocity. In our experience, the highest impact comes when AI-DLC is treated as an operating model change with clear guardrails, measurable controls and practical enablement for teams who need to adopt the new flow.

Example case: Automating an AWS Well-Architected Review across an AWS environment

Here’s a simple example of how we can operationalise Kiro in a Nordcloud-style engagement to accelerate architecture reviews across a customer’s AWS footprint.

The enterprise has multiple business units, hundreds of AWS accounts across several regions and a steady flow of platform changes driven by acquisitions. The goal is to run an AWS Well-Architected Framework Review as a repeatable capability so teams can continuously validate workloads and shared platform components (identity, networking, logging, governance) against the 6 WAR pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimisation and Sustainability.

Step 1: Define review behaviour in a steering file

We start by creating a dedicated steering file in the project repository, for example .kiro/steering/wafr.md. This markdown file acts as the ‘rules of engagement’ for the AI when a team member asks for a Well-Architected Review.

In technical terms, it defines the inputs (accounts, regions, workload identifiers, data classifications, RTO/RPO targets), the question set (mapped to the 6 pillars) and the evidence model (which AWS signals count as proof). It also standardises the outputs so every review produces the same artefacts:

• Scope and inventory rules: Which AWS accounts/OUs, regions, tags (e.g., Workload=Payments) and environments (prod/non-prod) are included
• Authentication and guardrails: Cross-account role names to assume, read-only permissions boundary, rate limits and 'no destructive calls' policy
• Evidence sources: Which services to query per pillar (e.g., AWS Config for configuration state, CloudTrail for change history, CloudWatch for SLO signals, Trusted Advisor for recommendations, security hub for… and so on)
• Report template: A fixed structure per pillar (questions → evidence → assessment → risk → recommendations → verification steps)
• Risk model: Severity, likelihood, business impact and a simple RAG status so stakeholders can triage quickly
• Escalation rules: When evidence is missing or contradictory, when to stop and request human inputs rather than guess

Step 2: Enable low-level verification via AWS APIs (cross-account, evidence-first)

In the steering file, we define how Kiro is allowed to validate claims using approved integrations (for example, AWS MCP servers to validate findings/templates/designs received from customer environments bia read-only access).

A typical pattern is:

• Kiro starts in a 'tooling' account, enumerates target accounts via AWS Organisations and then assumes a read-only role (e.g., WellArchitectedReadOnlyRole) in each account
• From there, it collects evidence with service APIs across the platform. For example:
  • Guardrails: AWS Control Tower (guardrails)
  • Access patterns: IAM and IAM Identity Centre (access patterns)
  • Network topology: VPC, Transit Gateway and Route 53
  • Change history and configuration state: CloudTrail and AWS Config
  • SLO/SLA signals: CloudWatch
  • Security posture: Security Hub, GuardDuty and Inspector
  • Data protection baselines: KMS and S3
  • Workload services: EKS/ECS, Lambda, ELB, RDS and DynamoDB

The key is that every assessment statement is tied to one or more collected facts so the review is reproducible, auditable and can be re-run after improvements.

Step 3: Produce a consistent pillar-by-pillar report (traceable findings) and recommendations

The steering file dictates exactly how Kiro structures the review across the 6 pillars and how it maps evidence to Well-Architected questions. In delivery, we typically enforce a finding format like WAFR-SEC-003 (pillar + sequence), including:

• Affected resources
• Evidence snippets
• Impact
• Recommended remediation
• Verification steps

This makes it easy to turn findings into backlog items and to re-run the review after changes. Moreover, the steering file should guide the AI to generate different proposed fixes for finding (as IaC where possible).

For an environment-wide review, the checks can be very concrete.

• Operational Excellence: Ownership and on-call readiness, runbooks, alerting tied to SLOs, deployment standards (CI/CD, IaC) and change hygiene (CloudTrail patterns)
• Security: Identity and access (least privilege, MFA/SSO posture), segmentation and egress control (VPC design), threat detection and vulnerability management (Security Hub/GuardDuty/Inspector), encryption standards (KMS) and auditability (CloudTrail retention); and we can map these to customer processes such as joiner/mover/leaver, privileged access workflows and change control
• Reliability: Multi-AZ and multi-region patterns where needed, backup and restore coverage (AWS Backup), DR testing evidence, service quota management and blast-radius reduction (account boundaries)
• Performance Efficiency: Autoscaling signals, right compute choices (containers/serverless/instances), caching and network performance considerations
• Cost Optimisation: Idle resources, right-sizing, savings plans coverage, storage lifecycle policies and chargeback/showback readiness via tagging
• Sustainability: Scaling policies, turning off non-prod, efficient storage tiering and reducing over-provisioned always-on capacity

Step 4: Operationalise across teams (templates, CI and continuous assurance)

After a few iterations, we treat the steering file as a delivery asset: we store it in a GitHub repository template (or a central standards repo) and bootstrap every new platform, application or operations project with it.

Practically, this enables repeatability in 3 ways:

1. Engineers can trigger a WAF Review on demand from Kiro and get a report that follows the same structure every time
2. Teams can schedule periodic re-reviews (e.g., monthly) to detect drift
3. Reviews can be integrated into delivery by generating machine-readable outputs (e.g., JSON for dashboards) alongside a stakeholder-friendly markdown report, and by creating remediation work items with clear acceptance criteria and verification steps

Over time, this is how you move from 'occasional review' to continuous architecture assurance across a large AWS footprint.

Don’t slow down, be systematic

If your AWS landscape feels too complex, it's not a signal to slow down – it’s a signal to become more systematic. Kiro can help you:

• Turn fuzzy intent into reviewable specs
• Accelerate discovery and assessment
• Translate architectural best practices into concrete verification steps

Steering files and well-defined personas make those outcomes repeatable across projects and customer environments. A pragmatic starting point is a pilot: pick one workload, run a lightweight architecture review, capture your standards as steering files and iterate toward an AI-DLC-style workflow where every change ships with evidence.

From there, you can scale the approach across portfolios with a repeatable assessment and modernisation playbook. If you’d like help making this happen in your organisation, contact me using the form below.