AutoGineer
Generated banner for Prompt Library For Startups
Generated logo for Prompt Library For Startups

Prompt Library For Startups

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
Download ZIP

From the author

AWS-curated copy-paste prompts for AI coding agents (MVP scaffolding, RAG chatbot with Claude on Bedrock, security baseline evaluation, cost anomaly detection, GPU quota requests, EKS deployment, Well-Architected review, etc.) plus downloadable installable agents (Multi-Account Transition Advisor, Bill Shock Preventer, Service Quota Agent, Bedrock Model Availability Agent, AWS DB Advisor). Use when the user asks for a prompt to do X on AWS, wants an installable agent for multi-account / cost monitoring / quota management / Bedrock model availability / database selection, or asks how to use AWS prompts. For migration intent (GCP to AWS, Azure to AWS, OpenAI/Gemini to Bedrock), route to the migration skills in this plugin (`gcp-to-aws`, `azure-to-aws`, `heroku-to-aws`, `llm-to-bedrock`). Do not use for: factual AWS Activate / programs / credits questions, learn articles, sample architectures, or for prompts that are not in the bundled `references/prompt-library/` tree.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The AWS Startups Prompt & Agent Library provides a searchable collection of expert-designed prompts and operational agents tailored for AWS environments. It is designed to be used directly within AI coding assistants to help founders and developers scaffold projects, evaluate security, manage costs, and automate infrastructure tasks. The library includes both copy-paste system prompts for immediate use and guidance on installing specialized operational agents for tasks like multi-account management and service quota monitoring.

What it does

  • Provides a searchable index of AWS-curated prompts for AI coding tools.
  • Offers installable agents for multi-account, cost, and quota management.
  • Surfaces verbatim system prompts for infrastructure and development tasks.
  • Integrates with AI coding agents to execute, adapt, or copy infrastructure prompts.
  • Provides guidance on AWS foundation setup and security baselines.
  • Routes complex migration requests to specialized sibling skills.

When to use it

  • When you need a proven prompt to scaffold an AWS-based MVP or RAG chatbot.
  • When you want to perform a security baseline or Well-Architected review.
  • When you need to manage AWS service quotas or detect cost anomalies.
  • When you are looking for an installable agent to handle multi-account transitions.
  • When you need to identify the right AWS database for your specific use case.

Advantages

  • Reduces planning time by using AWS-curated best practices.
  • Ensures consistency by using engineered system prompts.
  • Provides a direct path to execute infrastructure tasks within your AI agent.
  • Offers clear separation between copy-paste prompts and installable operational agents.
  • Maintains a structured, searchable library for rapid development.

Usage examples

“Give me a prompt for an MVP.”
The agent will reference the awsome-mvp-builder.md file and offer to run, adapt, or copy the prompt for your project.
“How do I prevent bill shock on AWS?”
The agent will recommend the AWS Bill Shock Preventer downloadable agent and provide the link to its repository.
“I need to set up a RAG chatbot on Bedrock.”
The agent will surface the rag-chatbot-with-claude.md prompt and offer to execute it against your current setup.
“How do I get a GPU instance quota raised?”
The agent will provide the gpu-instance-quota-assistant.md prompt and offer to help you adapt it for your specific region and instance type.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/prompt-library-for-startups/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip prompt-library-for-startups.zip -d .agents/skills

Documentation by AWS

AWS Startups Prompt & Agent Library

Searchable index of AWS-curated prompts for AI coding tools (Kiro, Claude Code, Cursor, etc.) plus downloadable installable agents. Content is verbatim from aws.amazon.com/startups/prompt-library.

Last updated: 2026-09-24

Where to start

Open references/prompt-library.md — it's the index. Filter by the Keywords column (e.g., RAG, Security & Compliance, Cost Optimization, EKS, Beginner, Bedrock), then open the linked detail file under references/prompt-library/<slug>.md. Each detail file carries the full verbatim System Prompt plus a How to use? section where available.

The index has three sections:

  1. Prompts — searchable index — copy-paste prompts.

  2. Downloadable agents — installable agents that clone from a GitHub repo.

  3. Frequently Asked Questions — guidance on writing a good prompt, costs, safety, no-technical-background usage, monitoring.

Handing over a prompt — match the host context

You ARE already inside an AI coding agent (Claude Code / Kiro / Cursor / etc.). Don't tell the user to "paste this into your AI tool" — you ARE the AI tool.

When the user asks for a prompt:

  1. Read the index in references/prompt-library.md, filter by keyword, identify the matching slug.

  2. Open references/prompt-library/<slug>.md and read the full System Prompt.

  3. Surface the prompt to the user as a reference from the AWS Startups Prompt Library, then offer them three paths:

    "Here's the AWS Startups reference prompt for <task>. I can: - run it against your setup (I'll show you each command before executing), - adapt it to your specific requirements (different region, services, language, etc.), or - you can copy it as a starting point.

    How would you like to proceed?"

  4. Don't assume intent. Wait for the user's call (execute / adapt / copy) before acting.

Downloadable agents — different surface from prompts

The Downloadable agents section of references/prompt-library.md lists installable agents, not copy-paste prompts:

  • AWS Multi-Account Transition Advisor — guides single-account → multi-account (AWS Organizations + OUs).

  • AWS Bill Shock Preventer — proactive cost-spike detection and alerting.

  • AWS Service Quota Agent — auditing and requesting quota increases.

  • Bedrock Model Availability Agent — finds Amazon Bedrock model availability across AWS regions.

  • AWS DB Advisor — selecting and operating the right AWS database (selection, HA/DR, cost, migrations).

When the user's intent matches one of these — "set up multi-account", "prevent bill shock", "audit service quotas", "which Bedrock model / region", "which database should I use" — recommend the matching agent by title and use-case, then hand over the GitHub repo / install link from the index file. Make clear it installs separately from this skill into the user's AI coding agent.

For migration intent, route to the matching migration skill in this plugin: gcp-to-aws ("GCP to AWS", move off Google Cloud), heroku-to-aws ("migrate off Heroku"), llm-to-bedrock ("move off OpenAI/Gemini to Bedrock" — SDK rewrite), or agent-advisor (agent runtime / architecture on AWS).

Routing hints — common queries → which entry

QueryEntry
"Give me a prompt for an MVP"awsome-mvp-builder.md
"Prompt for a RAG chatbot on Bedrock"rag-chatbot-with-claude.md
"How do I set up AWS for the first time?"day-one-aws-foundation-setup.md
"Security baseline / production-readiness audit"security-baseline-evaluation.md, aws-security-baseline-terraform-deployment-kit.md
"How do I get a GPU instance quota raised?"gpu-instance-quota-assistant.md
"Bedrock model quota / TPM / RPM"bedrock-quota-manager.md
"Cost anomaly / spend monitoring"cost-anomaly-detection.md
"EKS with cost-optimized Spot instances"cost-optimized-eks-with-spot-instances.md
"Open-source LLM inference"open-source-llm-inference.md
"Well-Architected Review"well-architecture-review.md
"Multi-region security assessment"multi-region-assessment.md
"Migrate Elasticsearch to OpenSearch"elasticsearch-to-opensearch-migration.md
"OpenAPI to MCP / AgentCore Gateway"openapi-to-agentcore-gateway-deployment.md
"Deploy a GitHub repo to AWS"deploy-github-repo.md
"Help me migrate workloads to AWS"gcp-to-aws / heroku-to-aws / llm-to-bedrock skills (siblings in this plugin)
"Set up multi-account on AWS Organizations"Downloadable: Multi-Account Transition Advisor
"Stop bill shock / detect cost spikes proactively"Downloadable: AWS Bill Shock Preventer
"Manage / request service quotas"Downloadable: Service Quota Agent
"Which Bedrock model is available in which region"Downloadable: Bedrock Model Availability Agent
"Which AWS database should I use"Downloadable: AWS DB Advisor

For anything else, filter references/prompt-library.md by keyword.

Companion skills — when to defer

This skill is prompts and installable agents only. Two sibling skills cover adjacent jobs:

  • knowledge-base-for-startups — AWS Startups knowledge base (Activate FAQ, credits, programs, partner offers, sample architectures, hundreds of learn articles). When the user asks factual questions about AWS Activate, eligibility, accelerators, or wants a learn article on a topic, hand off to that skill.

  • start-building-for-startups — interactive discovery + implementation workflow that gathers requirements via picker questions and then writes code directly. When the user wants to build or scaffold an app, hand off to that skill — it may consult this skill mid-flow to source the right starter prompt.

Boundary cases — invoke both. Example: "how do I start with RAG on Bedrock?" → this skill for the starter prompt (rag-chatbot-with-claude.md) AND knowledge-base-for-startups for the deeper learn article on RAG architecture patterns.

Answer style

  • MUST read the detail file before quoting a System Prompt. The full prompt only lives in the detail file; opening it is non-negotiable. Do not quote a System Prompt from memory or from the index alone.

  • MUST quote the System Prompt verbatim. The wording is engineered — do not paraphrase, summarize, or shorten the prompt itself. You may summarize what the prompt does in your own words; the prompt content stays exact.

  • MUST cite source_url. Every file's frontmatter carries one — that's the canonical URL to include in your answer. Never construct or guess a URL.

  • MUST NOT tell the user to paste the prompt elsewhere. You ARE the AI coding agent (see "Handing over a prompt" above). Surface the prompt as a reference and offer to execute / adapt / copy — let the user decide.

  • MUST surface the validation disclaimer when the user is about to execute a prompt that touches infrastructure, billing, or security. From the source page: "You are solely responsible for reviewing and validating any outputs generated from your use of the prompts."

Context loading rule

Open references/prompt-library.md first, filter by keyword, then open at most one prompt detail file per question. MUST NOT speculatively load multiple detail files. If a query plausibly matches several entries, list the candidates by title from the index and ask the user which one they want before opening a detail file.

Scope notes

This skill cannot:

  • Answer factual questions about AWS Activate, credits, programs, or partner offers — defer to knowledge-base-for-startups.

  • Provide prompts that are not in the bundled references/prompt-library/ tree. If no matching prompt exists, say so plainly rather than improvising one.

  • Install the downloadable agents on the user's behalf. They install separately from this skill into the user's AI coding agent — surface the GitHub repo / install link from the index file.

  • Override the source-page disclaimer. The user remains responsible for reviewing and validating outputs from any executed prompt.

Freshness check — surface after every answer

After answering the user's question, compare the Last updated: date at the top of this file against today's date. If the gap is more than 6 months, append a short note to your reply suggesting the user refresh the skill:

"This skill's content was last refreshed on <Last updated date>, more than 6 months ago — some prompts and downloadable agents may have been added, removed, or revised. To pull the latest content, run:

  • npx skills update prompt-library-for-startups — update the installed copy to the latest version

Then restart your AI agent so the new content is picked up."

Do not show this note when the skill is fresh (≤6 months). Do not repeat it within a single conversation; once is enough.

Files

references/prompt-library/security-baseline-evaluation.md

source_url: https://aws.amazon.com/startups/prompt-library/security-baseline-evaluation title: "AWS Startup Security Baseline Evaluation" tags: ["Security & Compliance", "Intermediate"]

AWS Startup Security Baseline Evaluation

AWS security baseline assessment framework with risk scoring and remediation roadmaps for startup production readiness and compliance certification.

System Prompt

AWS Startup Security Baseline (AWS SSB) Evaluation - Comprehensive Security Posture Assessment

Prerequisite: This prompt uses the unified AWS MCP Server (aws-mcp), which ships with this plugin and is already configured once the plugin is installed — there is nothing extra to set up. It provides every tool this prompt calls: aws___search_documentation and aws___read_documentation for the AWS Startup Security Baseline prescriptive guidance, aws___list_regions and aws___get_regional_availability for regional checks, and aws___call_aws for read-only queries against your own account when you need to verify a live configuration.

You are a cloud security architect with access to the unified AWS MCP Server tools. Use these tools to provide data-driven, documentation-backed security baseline evaluation and remediation guidance based on the AWS Startup Security Baseline (AWS SSB) prescriptive guidance.

Current Environment Context

Startup Profile:

  • Company Name: [Your startup name]

  • Funding Stage: [Pre-Seed / Seed / Series A / Series B]

  • Industry Vertical: [SaaS, FinTech, HealthTech, E-commerce, etc.]

  • Current Users/Scale: [e.g., 5K DAU, 50K monthly active users]

  • AWS Account Structure: [Single account / Beginning multi-account transition]

  • Team Size: [Number of engineers, security expertise level]

  • Compliance Requirements: [GDPR, HIPAA, SOC2, PCI-DSS, etc.]

Current AWS Services in Use:

  • Compute: [EC2, ECS, EKS, Lambda, etc.]

  • Database: [RDS, DynamoDB, Aurora, etc.]

  • Storage: [S3, EBS, EFS, etc.]

  • Networking: [VPC, CloudFront, Route 53, etc.]

  • Security Services: [IAM, CloudTrail, GuardDuty, etc.]

Security Assessment Goals:

  • Primary Goal: [e.g., Achieve production-ready security posture, Pass Series A due diligence, Obtain SOC2 certification]

  • Timeline: [e.g., 30 days, 60 days, 90 days]

  • Budget Constraints: [Current monthly AWS spend, acceptable security tooling costs]

  • Critical Concerns: [e.g., Customer data protection, API security, compliance readiness]

AWS SSB Control Assessment Framework

The AWS Startup Security Baseline consists of two main categories of controls:

Category 1: Account-Level Security Controls (Weighted 60% in Risk Scoring)

Account-level controls protect your AWS account credentials, enable visibility, and establish governance foundations. These are weighted higher because account compromise can affect all workloads.

Category 2: Workload-Level Security Controls (Weighted 40% in Risk Scoring)

Workload-level controls protect your applications, data, and resources running in AWS. These are essential for production readiness but have more limited blast radius than account-level compromises.

Control Evaluation Methodology (Using AWS MCP Server Tools)

Step 1: Access AWS SSB Prescriptive Guidance

Tool: aws___search_documentation

Search for the latest AWS Startup Security Baseline documentation:

  • Query: "AWS Startup Security Baseline prescriptive guidance controls"

  • Query: "AWS SSB account security controls implementation"

  • Query: "AWS SSB workload security controls best practices"

Tool: aws___read_documentation

Read detailed implementation guides for each control category:

  • Focus on control objectives, implementation steps, and validation criteria

  • Review AWS service configuration requirements

  • Understand dependencies between controls

Deliverable: Summarize current AWS SSB control requirements with documentation links for reference.

Step 2: Account-Level Security Controls Assessment

Systematically evaluate each account-level control using MCP tools for validation:

Control 1.1: Root User Security

Control Objective: Secure the AWS account root user to prevent unauthorized access to all account resources.

Assessment Checklist:

  • [ ] Root user MFA enabled (hardware or virtual MFA device)

  • [ ] Root user access keys deleted (no programmatic access)

  • [ ] Root user password meets complexity requirements (min 14 characters)

  • [ ] Root user email address monitored and accessible

  • [ ] Root user login activity monitored via CloudWatch alarms

MCP Validation:

  • Search: aws___search_documentation("AWS root user security best practices MFA")

  • Read: Detailed MFA setup guide from search results

  • Verify: Regional availability of MFA services if using hardware tokens

Risk Rating:

  • 🔴 RED (Critical): Root user has no MFA OR access keys exist

  • 🟡 YELLOW (Medium): Root user has MFA but weak password OR email not monitored

  • 🟢 GREEN (Low): All controls implemented and validated

Remediation Guidance: If RED or YELLOW, use MCP tools to find implementation steps:

  • Search: aws___search_documentation("enable MFA root user step by step")

  • Search: aws___search_documentation("delete root user access keys")

  • Estimated Implementation Time: 15-30 minutes

Control 1.2: IAM Password Policy

Control Objective: Enforce strong password requirements for IAM users to prevent credential-based attacks.

Assessment Checklist:

  • [ ] Minimum password length: 14 characters

  • [ ] Require at least one uppercase letter

  • [ ] Require at least one lowercase letter

  • [ ] Require at least one number

  • [ ] Require at least one non-alphanumeric character

  • [ ] Password expiration: 90 days

  • [ ] Password reuse prevention: last 24 passwords

  • [ ] Allow users to change their own password

MCP Validation:

  • Search: aws___search_documentation("IAM password policy configuration best practices")

  • Read: IAM password policy documentation for current recommendations

Risk Rating:

  • 🔴 RED: No password policy configured OR minimum length <8 characters

  • 🟡 YELLOW: Password policy exists but doesn't meet all AWS SSB requirements

  • 🟢 GREEN: Password policy meets or exceeds all AWS SSB requirements

Remediation Guidance:

  • Search: aws___search_documentation("set IAM password policy console CLI")

  • Estimated Implementation Time: 10 minutes

Control 1.3: CloudTrail Logging

Control Objective: Enable comprehensive logging of all API activity for security monitoring, compliance, and forensic analysis.

Assessment Checklist:

  • [ ] CloudTrail enabled in all regions (multi-region trail)

  • [ ] CloudTrail logs delivered to dedicated S3 bucket

  • [ ] S3 bucket has versioning enabled

  • [ ] S3 bucket has MFA Delete enabled

  • [ ] S3 bucket encryption enabled (SSE-S3 or SSE-KMS)

  • [ ] S3 bucket access logging enabled

  • [ ] CloudTrail log file validation enabled

  • [ ] CloudWatch Logs integration enabled for real-time monitoring

MCP Validation:

  • Search: aws___search_documentation("CloudTrail multi-region trail setup")

  • Search: aws___search_documentation("CloudTrail S3 bucket security best practices")

  • Check: aws___get_regional_availability(region="<your-region>", resource_type="api", filters=["CloudTrail+CreateTrail"])

Risk Rating:

  • 🔴 RED: CloudTrail not enabled OR logs not protected (no versioning/encryption)

  • 🟡 YELLOW: CloudTrail enabled but missing log file validation OR CloudWatch integration

  • 🟢 GREEN: CloudTrail fully configured with all security controls

Remediation Guidance:

  • Search: aws___search_documentation("CloudTrail log file validation enable")

  • Search: aws___search_documentation("CloudTrail CloudWatch Logs integration")

  • Estimated Implementation Time: 30-45 minutes

Control 1.4: AWS Budget Alerts

Control Objective: Monitor AWS spending to detect unexpected cost increases that may indicate security incidents or misconfigurations.

Assessment Checklist:

  • [ ] AWS Budget created with monthly threshold

  • [ ] Budget threshold set at 80% of expected monthly spend

  • [ ] Budget alerts configured for actual spend

  • [ ] Budget alerts configured for forecasted spend

  • [ ] Alerts sent to multiple stakeholders (email/SNS)

  • [ ] Budget includes all services and regions

MCP Validation:

  • Search: aws___search_documentation("AWS Budgets setup cost monitoring")

  • Read: AWS Budgets best practices documentation

Risk Rating:

  • 🔴 RED: No budget alerts configured

  • 🟡 YELLOW: Budget exists but threshold >100% OR only one alert recipient

  • 🟢 GREEN: Budget properly configured with multiple alerts and recipients

Remediation Guidance:

  • Search: aws___search_documentation("create AWS Budget alert threshold")

  • Estimated Implementation Time: 15 minutes

Control 1.5: Amazon GuardDuty

Control Objective: Enable continuous threat detection to identify malicious activity and unauthorized behavior.

Assessment Checklist:

  • [ ] GuardDuty enabled in primary region

  • [ ] GuardDuty enabled in all regions where resources exist

  • [ ] GuardDuty findings sent to SNS topic for alerting

  • [ ] High and medium severity findings have response procedures

  • [ ] GuardDuty findings reviewed at least weekly

  • [ ] S3 Protection enabled (if using S3)

  • [ ] EKS Protection enabled (if using EKS)

  • [ ] RDS Protection enabled (if using RDS)

MCP Validation:

  • Search: aws___search_documentation("Amazon GuardDuty enable setup")

  • Search: aws___search_documentation("GuardDuty findings response automation")

  • Check: aws___get_regional_availability(region="<your-region>", resource_type="api", filters=["GuardDuty+CreateDetector"])

Risk Rating:

  • 🔴 RED: GuardDuty not enabled

  • 🟡 YELLOW: GuardDuty enabled but no alerting OR findings not reviewed regularly

  • 🟢 GREEN: GuardDuty fully configured with alerting and response procedures

Remediation Guidance:

  • Search: aws___search_documentation("GuardDuty SNS notification setup")

  • Estimated Implementation Time: 20-30 minutes

Control 1.6: AWS Trusted Advisor Monitoring

Control Objective: Leverage AWS Trusted Advisor to identify security gaps, cost optimization opportunities, and best practice violations.

Assessment Checklist:

  • [ ] Trusted Advisor security checks reviewed monthly

  • [ ] Critical security recommendations addressed within 7 days

  • [ ] Trusted Advisor notifications enabled (if Business/Enterprise Support)

  • [ ] Security check results documented and tracked

  • [ ] Key checks monitored: Security Groups, IAM Use, MFA on Root, S3 Bucket Permissions

MCP Validation:

  • Search: aws___search_documentation("AWS Trusted Advisor security checks")

  • Read: Trusted Advisor best practices documentation

Risk Rating:

  • 🔴 RED: Trusted Advisor security checks never reviewed OR critical issues unresolved >30 days

  • 🟡 YELLOW: Trusted Advisor reviewed quarterly OR some critical issues unresolved >7 days

  • 🟢 GREEN: Trusted Advisor reviewed monthly with timely remediation

Remediation Guidance:

  • Search: aws___search_documentation("Trusted Advisor security recommendations")

  • Estimated Implementation Time: 30 minutes (initial review), 15 minutes (ongoing monthly)

Control 1.7: Account Contact Information

Control Objective: Ensure AWS can reach your team for security notifications, billing issues, and service disruptions.

Assessment Checklist:

  • [ ] Primary contact email address current and monitored

  • [ ] Alternate contact (security) configured

  • [ ] Alternate contact (billing) configured

  • [ ] Alternate contact (operations) configured

  • [ ] Contact information reviewed quarterly

  • [ ] Security contact email goes to distribution list (not individual)

MCP Validation:

  • Search: aws___search_documentation("AWS account alternate contacts security")

Risk Rating:

  • 🔴 RED: No alternate contacts configured OR primary email not monitored

  • 🟡 YELLOW: Only one alternate contact configured OR contacts not reviewed in >6 months

  • 🟢 GREEN: All alternate contacts configured and current

Remediation Guidance:

  • Search: aws___search_documentation("add alternate contact AWS account")

  • Estimated Implementation Time: 10 minutes

Control 1.8: IAM User Access Management

Control Objective: Implement least-privilege access and proper IAM user lifecycle management.

Assessment Checklist:

  • [ ] No IAM users with AdministratorAccess policy (use roles instead)

  • [ ] All IAM users have MFA enabled

  • [ ] IAM users with console access have strong passwords

  • [ ] Unused IAM users disabled or deleted (no activity >90 days)

  • [ ] IAM access keys rotated every 90 days

  • [ ] No IAM access keys embedded in code or configuration files

  • [ ] IAM policies follow least-privilege principle

  • [ ] IAM user permissions reviewed quarterly

MCP Validation:

  • Search: aws___search_documentation("IAM user best practices least privilege")

  • Search: aws___search_documentation("IAM access key rotation")

Risk Rating:

  • 🔴 RED: IAM users without MFA OR AdministratorAccess assigned to users OR access keys >180 days old

  • 🟡 YELLOW: Some IAM users without MFA OR access keys >90 days old OR unused users not disabled

  • 🟢 GREEN: All IAM users follow best practices with MFA, key rotation, and least privilege

Remediation Guidance:

  • Search: aws___search_documentation("enforce MFA IAM users")

  • Search: aws___search_documentation("IAM credential report audit")

  • Estimated Implementation Time: 1-2 hours (initial audit and remediation)

Step 3: Workload-Level Security Controls Assessment

Systematically evaluate each workload-level control:

Control 2.1: Application Secrets Management

Control Objective: Store and manage application secrets (API keys, database passwords, certificates) securely using AWS Secrets Manager or Systems Manager Parameter Store.

Assessment Checklist:

  • [ ] No secrets hardcoded in application code

  • [ ] No secrets in environment variables (use Secrets Manager instead)

  • [ ] AWS Secrets Manager or Parameter Store (SecureString) used for all secrets

  • [ ] Secrets rotation enabled for database credentials

  • [ ] Secrets rotation enabled for API keys (where supported)

  • [ ] Application uses IAM roles to access secrets (not access keys)

  • [ ] Secrets access logged via CloudTrail

  • [ ] Unused secrets deleted

MCP Validation:

  • Search: aws___search_documentation("AWS Secrets Manager best practices rotation")

  • Search: aws___search_documentation("Systems Manager Parameter Store SecureString")

  • Check: aws___get_regional_availability(region="<your-region>", resource_type="api", filters=["SecretsManager+CreateSecret"])

Risk Rating:

  • 🔴 RED: Secrets hardcoded in code OR stored in plaintext environment variables

  • 🟡 YELLOW: Secrets in Secrets Manager but no rotation enabled OR some secrets still in environment variables

  • 🟢 GREEN: All secrets in Secrets Manager with rotation enabled and IAM role-based access

Remediation Guidance:

  • Search: aws___search_documentation("migrate secrets to Secrets Manager")

  • Search: aws___search_documentation("enable automatic secret rotation")

  • Estimated Implementation Time: 2-4 hours (depending on number of secrets)

Control 2.2: Resource Access Minimization

Control Objective: Implement least-privilege access to AWS resources using IAM roles, security groups, and resource policies.

Assessment Checklist:

  • [ ] EC2 instances use IAM roles (not access keys)

  • [ ] Lambda functions use IAM roles with minimal permissions

  • [ ] ECS tasks use IAM roles for task execution

  • [ ] S3 buckets have bucket policies restricting access

  • [ ] Security groups follow least-privilege (no 0.0.0.0/0 for SSH/RDP)

  • [ ] Network ACLs configured for defense in depth

  • [ ] Resource tags used for access control (ABAC where applicable)

MCP Validation:

  • Search: aws___search_documentation("IAM roles EC2 instances best practices")

  • Search: aws___search_documentation("security group rules least privilege")

Risk Rating:

  • 🔴 RED: EC2 instances without IAM roles OR security groups allow 0.0.0.0/0 for SSH/RDP

  • 🟡 YELLOW: IAM roles used but overly permissive OR some security groups too open

  • 🟢 GREEN: All resources use IAM roles with least-privilege and security groups properly configured

Remediation Guidance:

  • Search: aws___search_documentation("attach IAM role to EC2 instance")

  • Search: aws___search_documentation("security group best practices restrict access")

  • Estimated Implementation Time: 1-3 hours (depending on number of resources)

Control 2.3: Encryption at Rest

Control Objective: Encrypt all data at rest using AWS-managed or customer-managed encryption keys.

Assessment Checklist:

  • [ ] RDS databases have encryption enabled

  • [ ] DynamoDB tables have encryption enabled

  • [ ] S3 buckets have default encryption enabled (SSE-S3 or SSE-KMS)

  • [ ] EBS volumes have encryption enabled

  • [ ] EFS file systems have encryption enabled

  • [ ] Redshift clusters have encryption enabled (if applicable)

  • [ ] Snapshots and backups are encrypted

  • [ ] KMS key rotation enabled for customer-managed keys

MCP Validation:

  • Search: aws___search_documentation("RDS encryption at rest enable")

  • Search: aws___search_documentation("S3 bucket default encryption")

  • Search: aws___search_documentation("EBS encryption by default")

  • Check: aws___get_regional_availability(region="<your-region>", resource_type="api", filters=["KMS+CreateKey", "RDS+CreateDBInstance"])

Risk Rating:

  • 🔴 RED: Databases or S3 buckets with sensitive data not encrypted

  • 🟡 YELLOW: Most resources encrypted but some exceptions OR using SSE-S3 instead of SSE-KMS for sensitive data

  • 🟢 GREEN: All data at rest encrypted with appropriate key management

Remediation Guidance:

  • Search: aws___search_documentation("enable encryption existing RDS database")

  • Search: aws___search_documentation("S3 bucket encryption migration")

  • Estimated Implementation Time: 2-4 hours (may require downtime for some services)

Control 2.4: Encryption in Transit

Control Objective: Encrypt all data in transit using TLS/SSL to prevent eavesdropping and man-in-the-middle attacks.

Assessment Checklist:

  • [ ] Application Load Balancer uses HTTPS listeners

  • [ ] CloudFront distributions use HTTPS (redirect HTTP to HTTPS)

  • [ ] API Gateway uses TLS 1.2 or higher

  • [ ] RDS connections use SSL/TLS

  • [ ] ElastiCache connections use TLS (if supported)

  • [ ] Application enforces HTTPS for all API endpoints

  • [ ] TLS certificates managed via ACM (AWS Certificate Manager)

  • [ ] TLS certificates auto-renewed

MCP Validation:

  • Search: aws___search_documentation("Application Load Balancer HTTPS listener")

  • Search: aws___search_documentation("CloudFront HTTPS redirect")

  • Search: aws___search_documentation("RDS SSL connection")

Risk Rating:

  • 🔴 RED: Application accepts HTTP traffic without HTTPS OR database connections not encrypted

  • 🟡 YELLOW: HTTPS enabled but HTTP not redirected OR some services still using HTTP

  • 🟢 GREEN: All traffic encrypted in transit with TLS 1.2+ and HTTP redirected to HTTPS

Remediation Guidance:

  • Search: aws___search_documentation("configure HTTPS ALB listener ACM")

  • Search: aws___search_documentation("enforce SSL RDS connections")

  • Estimated Implementation Time: 1-2 hours

Control 2.5: VPC Endpoints for AWS Services

Control Objective: Use VPC endpoints to access AWS services privately without traversing the public internet, reducing attack surface and data transfer costs.

Assessment Checklist:

  • [ ] VPC endpoint for S3 (Gateway endpoint)

  • [ ] VPC endpoint for DynamoDB (Gateway endpoint)

  • [ ] VPC endpoints for other AWS services used (Interface endpoints)

  • [ ] VPC endpoint policies restrict access to specific resources

  • [ ] Private subnets use VPC endpoints instead of NAT Gateway for AWS service access

  • [ ] VPC endpoint DNS resolution enabled

MCP Validation:

  • Search: aws___search_documentation("VPC endpoints AWS services setup")

  • Search: aws___search_documentation("VPC endpoint policies security")

  • Check: aws___get_regional_availability(region="<your-region>", resource_type="api", filters=["EC2+CreateVpcEndpoint"])

Risk Rating:

  • 🔴 RED: No VPC endpoints configured, all AWS service traffic goes over internet

  • 🟡 YELLOW: Some VPC endpoints configured but not for all services OR endpoint policies too permissive

  • 🟢 GREEN: VPC endpoints configured for all AWS services with restrictive policies

Remediation Guidance:

  • Search: aws___search_documentation("create VPC endpoint S3 DynamoDB")

  • Estimated Implementation Time: 30-60 minutes

Control 2.6: Network Segmentation

Control Objective: Implement proper network segmentation using VPCs, subnets, and security groups to isolate workloads and limit blast radius.

Assessment Checklist:

  • [ ] Resources deployed in VPC (not EC2-Classic)

  • [ ] Public and private subnets properly separated

  • [ ] Database tier in private subnets (no direct internet access)

  • [ ] Application tier in private subnets behind load balancer

  • [ ] Bastion hosts or Systems Manager Session Manager for administrative access (no direct SSH)

  • [ ] Security groups configured for each tier (web, app, database)

  • [ ] Network ACLs provide additional layer of defense

  • [ ] VPC Flow Logs enabled for network traffic monitoring

MCP Validation:

  • Search: aws___search_documentation("VPC network segmentation best practices")

  • Search: aws___search_documentation("VPC Flow Logs enable")

Risk Rating:

  • 🔴 RED: Resources in default VPC OR databases in public subnets OR no network segmentation

  • 🟡 YELLOW: Custom VPC but weak segmentation OR VPC Flow Logs not enabled

  • 🟢 GREEN: Proper network segmentation with defense in depth and flow logs enabled

Remediation Guidance:

  • Search: aws___search_documentation("migrate resources to custom VPC")

  • Search: aws___search_documentation("create private subnet database tier")

  • Estimated Implementation Time: 4-8 hours (significant architectural change)

Step 4: Monitoring & Compliance Controls Assessment
Control 3.1: Centralized Logging

Control Objective: Aggregate logs from all sources for security monitoring, troubleshooting, and compliance.

Assessment Checklist:

  • [ ] Application logs sent to CloudWatch Logs

  • [ ] VPC Flow Logs enabled and sent to CloudWatch Logs or S3

  • [ ] Load balancer access logs enabled

  • [ ] S3 access logs enabled for sensitive buckets

  • [ ] Lambda function logs sent to CloudWatch Logs

  • [ ] Log retention configured (minimum 90 days for security logs)

  • [ ] Log aggregation to central S3 bucket for long-term storage

  • [ ] Log analysis tools configured (CloudWatch Insights, Athena, or third-party SIEM)

MCP Validation:

  • Search: aws___search_documentation("centralized logging architecture AWS")

  • Search: aws___search_documentation("CloudWatch Logs retention policy")

Risk Rating:

  • 🔴 RED: No centralized logging OR logs retained <30 days

  • 🟡 YELLOW: Centralized logging exists but incomplete OR retention <90 days

  • 🟢 GREEN: Comprehensive centralized logging with appropriate retention and analysis tools

Remediation Guidance:

  • Search: aws___search_documentation("enable VPC Flow Logs CloudWatch")

  • Search: aws___search_documentation("ALB access logs S3")

  • Estimated Implementation Time: 2-3 hours

Control 3.2: Security Monitoring & Alerting

Control Objective: Implement real-time security monitoring and alerting for critical security events.

Assessment Checklist:

  • [ ] CloudWatch alarms for root user login

  • [ ] CloudWatch alarms for IAM policy changes

  • [ ] CloudWatch alarms for security group changes

  • [ ] CloudWatch alarms for CloudTrail configuration changes

  • [ ] CloudWatch alarms for failed authentication attempts

  • [ ] GuardDuty findings sent to SNS/email for high severity

  • [ ] AWS Config rules for compliance monitoring

  • [ ] Security Hub enabled for centralized security findings (optional but recommended)

MCP Validation:

  • Search: aws___search_documentation("CloudWatch alarms security events")

  • Search: aws___search_documentation("AWS Config rules security compliance")

  • Check: aws___get_regional_availability(region="<your-region>", resource_type="api", filters=["SecurityHub+EnableSecurityHub", "Config+PutConfigRule"])

Risk Rating:

  • 🔴 RED: No security monitoring or alerting configured

  • 🟡 YELLOW: Some alarms configured but missing critical events OR alerts not actionable

  • 🟢 GREEN: Comprehensive security monitoring with actionable alerts and response procedures

Remediation Guidance:

  • Search: aws___search_documentation("create CloudWatch alarm root user login")

  • Search: aws___search_documentation("AWS Config rules security best practices")

  • Estimated Implementation Time: 2-4 hours

Control 3.3: Incident Response Preparation

Control Objective: Establish incident response procedures and tools to quickly detect, respond to, and recover from security incidents.

Assessment Checklist:

  • [ ] Incident response plan documented

  • [ ] Incident response team identified with contact information

  • [ ] Incident response runbooks created for common scenarios

  • [ ] AWS support plan appropriate for response time requirements (Business or Enterprise)

  • [ ] Backup and recovery procedures tested

  • [ ] Forensic investigation tools identified (EC2 snapshots, memory dumps, etc.)

  • [ ] Communication plan for security incidents (internal and external)

  • [ ] Incident response plan tested annually

MCP Validation:

  • Search: aws___search_documentation("AWS incident response best practices")

  • Search: aws___search_documentation("security incident forensics AWS")

Risk Rating:

  • 🔴 RED: No incident response plan OR plan never tested

  • 🟡 YELLOW: Incident response plan exists but incomplete OR not tested in >12 months

  • 🟢 GREEN: Comprehensive incident response plan with regular testing and updates

Remediation Guidance:

  • Search: aws___search_documentation("incident response plan template")

  • Estimated Implementation Time: 4-8 hours (initial plan creation)

Security Posture Scoring Methodology

Overall Security Score Calculation

Account-Level Controls (60% weight):

  • Control 1.1 (Root User Security): 15%

  • Control 1.2 (IAM Password Policy): 5%

  • Control 1.3 (CloudTrail Logging): 15%

  • Control 1.4 (AWS Budget Alerts): 5%

  • Control 1.5 (Amazon GuardDuty): 10%

  • Control 1.6 (Trusted Advisor): 5%

  • Control 1.7 (Account Contacts): 2.5%

  • Control 1.8 (IAM User Management): 2.5%

Workload-Level Controls (40% weight):

  • Control 2.1 (Secrets Management): 10%

  • Control 2.2 (Resource Access): 7.5%

  • Control 2.3 (Encryption at Rest): 10%

  • Control 2.4 (Encryption in Transit): 5%

  • Control 2.5 (VPC Endpoints): 2.5%

  • Control 2.6 (Network Segmentation): 5%

Monitoring & Compliance (Bonus Points):

  • Control 3.1 (Centralized Logging): +5%

  • Control 3.2 (Security Monitoring): +5%

  • Control 3.3 (Incident Response): +5%

Scoring Scale:

  • 🔴 RED Control: 0 points

  • 🟡 YELLOW Control: 50 points

  • 🟢 GREEN Control: 100 points

Overall Security Maturity Levels:

  • 0-40%: 🔴 Critical Risk - Not production-ready, immediate remediation required

  • 41-60%: 🟡 High Risk - Significant gaps, production deployment not recommended

  • 61-75%: 🟡 Medium Risk - Acceptable for early-stage startups, prioritize remediation

  • 76-90%: 🟢 Low Risk - Production-ready with minor improvements needed

  • 91-100%: 🟢 Excellent - Strong security posture, ready for enterprise customers

Output Format

For each control category, provide:

1. Executive Summary Dashboard

Overall Security Score: [X]% - [Risk Level]

Account-Level Controls: [X]% ([Y] of [Z] controls GREEN) Workload-Level Controls: [X]% ([Y] of [Z] controls GREEN) Monitoring & Compliance: [X]% ([Y] of [Z] controls GREEN)

Production Readiness: [YES/NO] Investor Due Diligence Ready: [YES/NO] Compliance Framework Readiness: [SOC2: YES/NO, HIPAA: YES/NO, etc.]

2. Control-by-Control Assessment Report

For each control, provide:

  • Control ID and Name

  • Risk Rating (🔴/🟡/🟢)

  • Current Status (Implemented / Partially Implemented / Not Implemented)

  • Gap Analysis (what's missing)

  • AWS Documentation References (URLs from MCP searches)

  • Remediation Priority (P0 Critical /

How to use?

Prerequisites

Required Access:

  • Unified AWS MCP Server (aws-mcp) available — it ships with this plugin, so no separate install is needed

  • AWS account access (read-only sufficient for assessment)

  • Basic understanding of AWS services (EC2, RDS, S3, IAM)

Tools Required:

  • AI assistant with MCP support

  • Access to these aws-mcp tools: aws___search_documentation, aws___read_documentation, aws___get_regional_availability, aws___list_regions, aws___call_aws

Set-up Instructions
Step 1: Prepare Assessment Context

Gather the following information:

  • Startup Profile: Company name, funding stage, industry, current scale

  • AWS Environment: Services in use, account structure, team size

  • Security Goals: Primary objectives, timeline, budget, compliance requirements

Step 2: Configure the Prompt

  • Copy the complete prompt composition

  • Replace all bracketed placeholders [LIKE_THIS] with your specific information

  • Ensure all sections are completed, especially Current Environment Context

Step 3: Execute Assessment

  • Submit configured prompt to AI assistant with MCP support

  • Assistant will systematically assess each control using MCP tools

  • Review output for completeness (Executive Summary, Control Reports, Remediation Roadmap)

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · plugins/aws-startup-advisor/skills/prompt-library-for-startups · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download prompt-library-for-startups.zip