Skip to content

Add new Kiro Powers SDP Agent #98

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Stivenavila wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Add new Kiro Powers SDP Agent #98

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5c26353
Add files via upload
Stivenavila Apr 9, 2026
f23b2d2
Delete AWS-SDP directory
Stivenavila Apr 9, 2026
278ad63
Add files via upload
Stivenavila Apr 9, 2026
8d56b47
Update POWER.md
Stivenavila Apr 9, 2026
91f071f
Update POWER.md
Stivenavila Apr 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
139 changes: 139 additions & 0 deletions aws-sdp/POWER.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,139 @@
---
name: aws-sdp
description: AWS Service Delivery Program (SDP) documentation assistant. Helps AWS Partners create, complete and validate customer reference cases for APN designations.
version: 1.0.0
displayName: AWS SDP Agent for ITera
author: ITERA Cloud Architecture Team - Stiven Avila
keywords:
- SDP
- Service Delivery Program
- customer reference
- customer success
- APN
- AWS partner
- AWS Partner Network
- APN validation
- APN designation
- networking SDP
- EKS SDP
- ECS SDP
- Serverless SDP
- Database SDP
- Security SDP
- Migration SDP
- Data Analytics SDP
- Machine Learning SDP
- DevOps SDP
- SAP on AWS SDP
- Windows on AWS SDP
- VMware Cloud on AWS SDP
- Amazon Connect SDP
- Amazon EC2 for Windows Server SDP
- Amazon EC2 for Linux on AWS SDP
- Amazon RDS on AWS SDP
- Amazon Redshift on AWS SDP
- Amazon EMR on AWS SDP
- Amazon ElastiCache on AWS SDP
- Amazon DynamoDB on AWS SDP
- Amazon Neptune on AWS SDP
- Amazon DocumentDB on AWS SDP
- Amazon Keyspaces on AWS SDP
- Amazon Timestream on AWS SDP
- Amazon Quantum Ledger Database (QLDB) on AWS SDP
- Amazon Managed Streaming for Apache Kafka (MSK) on AWS SDP
- Amazon OpenSearch Service on AWS SDP
- Amazon Kinesis on AWS SDP
- Amazon Kinesis Data Firehose on AWS SDP
- Amazon Kinesis Data Analytics on AWS SDP
- Amazon Kinesis Video Streams on AWS SDP
- Amazon Athena on AWS SDP
- Amazon QuickSight on AWS SDP
- Amazon Managed Service for Apache Flink on AWS SDP
- Amazon Managed Service for Apache Flink on AWS SDP
- Amazon Managed Service for Apache Flink on AWS SDP
- Amazon Newtworking on AWS SDP
- case study
- partner case study
---

# AWS Service Delivery Program (SDP) — Power

You are an expert in AWS Service Delivery Program documentation. Your job is to help the ITERA team write, complete, and validate customer references to obtain and maintain SDP designations from AWS.

## Onboarding

When this power activates, follow these steps:

1. **Identify the context**: Is a new case being created, an existing one being completed, or one being validated before submission to AWS?
2. **Identify the target SDP**: Networking, EKS, ECS, Serverless, Database, Security, Migration, or other.
3. **Gather inputs**: Request or read available project documents (proposals, closure reports, technical specs, architecture diagrams).
4. **Guide the correct flow**: Use the steering files based on the task at hand.

## Critical Rules

- **NEVER fabricate data**: AWS manually verifies every case with the customer. Dates, Account IDs, services, and outcomes must be real and verifiable.
- **Always include Account IDs** when available — they increase credibility with AWS.
- **Architecture diagrams are mandatory**: Without a visual architecture, the case may be rejected.
- **The customer must be able to confirm** everything documented — write in language the customer would recognize as their own.
- **Measurable outcomes first**: AWS values concrete metrics over generic benefits.

## SDP Form Fields

Each customer reference must complete these fields:

| Field | Key Notes |
|---|---|
| Name of the Publicly Available Case Study | Format: `[Customer] – [Solution] with [Main AWS Services]` |
| Customer Challenge | Customer's perspective — do not mention the partner |
| Proposed Solution | Detailed architecture, component by component |
| Third-party Applications or Solutions | ISVs, external vendors, non-AWS tools |
| How AWS is used | Table: AWS Service → Specific role in the solution |
| Engagement Start Date | Kickoff or signed proposal date |
| Engagement End Date | Formal closure report or delivery date |
| Date Project Went into Production | Real go-live date, must be verifiable |
| Result(s)/Outcomes | Prioritize measurable metrics |
| Architecture Diagrams | PNG/JPG/PDF — mandatory attachment |

## Available Steering Files

Refer to these files based on the task:

- `workflow-writing.md` — Step-by-step process for writing a case from project documents
- `fields-detail.md` — Detailed field-by-field guide with examples and common mistakes
- `outcomes-bank.md` — Bank of metrics and typical outcomes by SDP type
- `validation-checklist.md` — Checklist before submitting to AWS

## Quick Workflow

```
1. Read project documents (proposals, closure reports, technical specs)
↓
2. Extract: customer, AWS services, problem, solution, dates, outcomes
↓
3. Draft fields in order: Challenge → Solution → Services → Dates → Outcomes
↓
4. Build AWS services table
↓
5. Validate with checklist before submitting
↓
6. Generate final Word document (field by field matching the form)
```

## Supported SDPs and Expected Services

| SDP | Minimum Expected AWS Services |
|---|---|
| **Networking** | VPC, Transit Gateway, Direct Connect or VPN, Route 53, Network Firewall or WAF |
| **Containers EKS** | EKS, ECR, ELB, VPC, IAM, CloudWatch |
| **Containers ECS** | ECS, ECR, Fargate or EC2, ELB, VPC |
| **Serverless** | Lambda, API Gateway, DynamoDB or S3, IAM, CloudWatch |
| **Database RDS** | RDS or Aurora, VPC, Subnets, Security Groups, CloudWatch |
| **Security** | IAM, CloudTrail, Config, GuardDuty, Security Hub, WAF |
| **Migration** | MGN or DMS, S3, EC2, VPC |

## Notes About AWS Review

- AWS verifies with the customer: the case must be accurate
- Naming the customer's AWS account with an Account ID increases credibility
- Production dates are critical: the project must already be in production
- Without an attached architecture diagram, the case may be rejected
156 changes: 156 additions & 0 deletions aws-sdp/steering/fields-detail.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
# Detailed Field Guide — With Examples and Common Mistakes

## Field: Name of the Publicly Available Case Study

**Format**: `[Customer] – [Solution Description] with [Main AWS Services]`

**Good examples**:
- "Comfandi – Network Infrastructure Transformation on AWS with Transit Gateway, Site-to-Site VPN, Network Firewall, CloudFront, and Route 53"
- "Bancolombia – Microservices Platform on Amazon EKS with Multi-AZ High Availability"
- "EPM – Real-Time Analytics with Serverless Architecture on AWS Lambda and Kinesis"

**Common mistakes**:
- "Infrastructure project for financial customer" — too vague
- "AWS implementation for Comfandi" — doesn't mention services or solution
- Just reading the name should identify which SDP it applies to

---

## Field: Customer Challenge

**Ideal length**: 300–500 words

**What AWS wants to see**:
- A real business problem, not just a technical one
- The impact of NOT solving the problem
- Enough context to understand the scope of the engagement
- The customer's language (as if the customer wrote it)

**Common mistakes**:
- Mentioning the partner: "Comfandi contacted ITERA to..."
- Being generic: "they needed to improve their cloud infrastructure"
- Mixing challenge and solution in the same paragraph
- "The Fovis and Fosfec applications lacked centralized web perimeter protection, exposing them to OWASP threats with no network traffic visibility."

**Opening templates by industry**:

*Compensation fund / social sector:*
> "[Customer] is one of the [adjective] family compensation funds in Colombia, with operations in [region] serving more than [N] beneficiaries. Its technology infrastructure supports critical applications for [subsidies/health/education] that require continuous availability."

*Financial sector:*
> "[Customer] operates in [N] countries with a [services] platform processing [N] transactions daily. The growing demand for secure connectivity between cloud environments and legacy systems represented a significant operational risk."

---

## Field: Proposed Solution

**Level of detail expected by AWS**:

| Element | Poor | Good |
|---|---|---|
| Service name | "database" | "Amazon Aurora PostgreSQL-Compatible" |
| Configuration | "multi-zone" | "3 availability zones: us-east-1a, 1b, 1c" |
| Network | "private VPC" | "VPC CIDR 10.249.36.0/22 with private subnets under Control Tower" |
| Security | "with WAF" | "AWS WAF with 1 Web ACL, 9 custom rules, and 1 Managed Rule Group" |

**Introductory paragraph template**:
> "[Partner] designed and implemented a [type: network/container/serverless] architecture on AWS that [what it solves]. The solution integrates the following components..."

**Services table template** (always include):
```
| AWS Service | Role in the Solution |
|---|---|
| AWS Transit Gateway | Central routing hub between N VPCs across [customer]'s accounts |
| AWS Site-to-Site VPN | N encrypted tunnels connecting [A] to [B] |
```

---

## Field: Third-party Applications or Solutions

**When it applies**:
- External CI/CD tools (Jenkins, GitLab, GitHub Actions)
- Third-party monitoring (Datadog, New Relic, Grafana)
- Identity providers (Keycloak, Okta, Active Directory)
- On-premises systems connected to the solution
- External providers connected via VPN/Direct Connect
- IaC tools: Terraform, Pulumi, Ansible (if part of the delivered solution)

**If no third parties**:
> "No third-party solutions were used. The solution was implemented 100% on native AWS services."

---

## Field: How AWS Is Used as Part of the Solution

**Recommended format**: table + integration flow paragraph

**Tip**: Be specific per service. Examples:

| Vague | Specific |
|---|---|
| "Amazon VPC for networking" | "Amazon VPC with CIDR 10.249.36.0/22, private subnets across 3 AZs under Control Tower" |
| "CloudWatch for monitoring" | "CloudWatch for ingesting VPC Flow Logs (20 GB/month) and network traffic auditing" |
| "S3 for storage" | "Amazon S3 as the origin for static assets distributed via CloudFront" |

---

## Date Fields

### Important rules:
- `Start ≤ End ≤ Production` — AWS checks for consistency
- If there are multiple sub-projects, document the full range
- Use the closure report date as the end reference when available
- The project MUST already be in production — if not, it doesn't qualify for SDP

### When there are multiple phases:
```
Start date: [date of the first sub-project]
End date: [date of the last closure]
Production date: [go-live date of the main component]
```

---

## Field: Results/Outcomes

### Value hierarchy for AWS:
1. Business metrics (USD saved, % cost reduction, time-to-market)
2. Measurable technical metrics (latency, uptime %, throughput RPS)
3. perational improvements (reduced tickets, eliminated processes)
4. Security improvements (achieved compliance, mitigated risks)

### Templates by outcome type:

**Connectivity/Networking**:
> "Connectivity across [N] AWS accounts was consolidated via Transit Gateway, replacing bilateral peering management with a hub-and-spoke model with a single control point."

**Security**:
> "The centralized WAF with [N] active rules protects [N] applications against OWASP Top 10 threats, with full traffic visibility through VPC Flow Logs."

**High availability**:
> "The multi-AZ architecture guarantees continuous 7x24x365 availability with automatic failover in case of availability zone failures."

**Content delivery**:
> "CloudFront reduced static content delivery latency for [application] users in [region], with functional tests approved in both QA and production environments."

---

## Field: Architecture Diagrams

**Accepted formats**: PNG, JPG, PDF

**Diagram checklist**:
- [ ] All AWS services in the case appear in the diagram
- [ ] Data/connectivity flow between components is shown
- [ ] Separate AWS accounts are identified (if applicable)
- [ ] Availability zones are shown (if there is HA)
- [ ] Connections to external/on-premises systems are shown

**Recommended tools**:
- draw.io / diagrams.net (free, official AWS icons available)
- Official AWS Architecture Icons: https://aws.amazon.com/architecture/icons/
- Cloudcraft (AWS-specialized)
- Lucidchart

**If the diagram doesn't exist**: flag it explicitly in the document and create a task for the technical team to produce it before submitting to AWS.
Loading