aws-bestpractice-research

AWS Best Practice Research (with Optional Live Audit)

Research and compile comprehensive best-practice checklists for any AWS service using the aws-knowledge-mcp-server documentation search tools. Optionally audit live AWS resources against the compiled checklist.

Prerequisites

This skill requires the aws-knowledge-mcp-server tools to be available:

aws___search_documentation — search across AWS documentation topics
aws___read_documentation — read full documentation pages
aws___recommend — get related documentation recommendations

For the optional live audit (Step 8), the AWS CLI (aws) must be available and configured with credentials that have read access to the target service.

Workflow

Step 1: Identify Target Service and Audit Scope

Determine from user input:

AWS Service — e.g., ElastiCache Redis, RDS MySQL, MSK, EKS, Aurora, DynamoDB, etc.
Focus areas — HA/DR, security, or all (default: all)
Live audit info (optional) — does the user provide any of the following?
- AWS credentials (environment variables, profile, or credential file path)
- AWS Region (e.g., us-west-2)
- Resource identifiers (cluster name, instance ID, table name, etc.)

If the service is ambiguous, ask the user to clarify (e.g., "RDS MySQL or RDS PostgreSQL?").

Record whether a live audit is requested:

If the user provides credentials + region + resource info → run live audit after checklist
If the user provides partial info → ask for the missing pieces before proceeding
If the user provides no live resource info → skip live audit, produce checklist only

Step 2: Parallel Documentation Search

Run all 6 search queries in parallel using aws___search_documentation. Replace {SERVICE} with the actual service name (e.g., "ElastiCache Redis", "Amazon RDS MySQL", "Amazon MSK").

Query 1: "{SERVICE} best practices high availability disaster recovery"
  topics: ["general", "reference_documentation"]
  limit: 15

Query 2: "{SERVICE} Well-Architected reliability resilience best practices"
  topics: ["general", "reference_documentation"]
  limit: 15

Query 3: "{SERVICE} replication multi-AZ failover cluster mode backup"
  topics: ["reference_documentation", "troubleshooting"]
  limit: 15

Query 4: "{SERVICE} security encryption authentication access control"
  topics: ["general", "reference_documentation"]
  limit: 15

Query 5: "{SERVICE} Well-Architected security best practices"
  topics: ["general", "reference_documentation"]
  limit: 15

Query 6: "Security Hub controls for {SERVICE}"
  topics: ["general", "reference_documentation"]
  limit: 15

Step 3: Read Key Documentation Pages

From the search results, identify and read the most important pages in parallel using aws___read_documentation. Prioritize these document types:

Well-Architected Lens pages for the service (Reliability, Security, Performance, Operational Excellence pillars)
Security Hub controls page for the service
Official best practices page
Resilience / disaster recovery page
Overall best practices page

Read each with max_length: 15000 to get comprehensive content. Typically 3-5 page reads are needed.

If a Well-Architected Lens exists for the service, it is the single most valuable source — always read it.

Step 4: Extract and Categorize Check Items

From all gathered documentation, extract individual check items and organize them into 5 mandatory categories (see references/output-template.md for the exact format):

Category 1: High Availability Architecture Items about: cluster mode, replication, replicas per shard, Multi-AZ, AZ distribution, node types, quorum.

Category 2: Disaster Recovery Items about: automatic/manual backups, retention policies, RPO/RTO documentation, Global Datastore / cross-region replication, failover testing, replication lag monitoring.

Category 3: Failover Planning Items about: Test Failover API, FIS resilience testing, client timeout/topology config, SNS event notifications, graceful degradation, WAIT command.

Category 4: Security Configuration Items about: encryption at-rest/in-transit, authentication (AUTH/RBAC/IAM), subnet groups, security groups, KMS keys, dangerous command renaming, RBAC metrics monitoring, IAM control plane policies.

Category 5: Others Items not covered by the above 4 categories, including but not limited to: auto minor version upgrade, engine version, node type selection (Graviton), CloudWatch monitoring, reserved memory, connection pooling, read routing, expensive commands, slow log, IaC management, Auto Scaling, cost tags, client retry logic, performance tuning, operational best practices.

For each check item, record:

ID — category prefix + sequential number + priority suffix (e.g., HA-01-hi, DR-02-md, SEC-03-lo)
- Priority suffixes: -hi (High), -md (Medium), -lo (Low)
- This embeds priority directly in the ID for quick visual scanning
Check item name — concise, actionable
Description — what to check and why, specific thresholds or values where applicable
Source — which document/control it comes from (see source annotation rules below)
Priority — High / Medium / Low (also kept as a separate column for filtering)

Step 5: Compile Source Annotations

Use consistent source tags throughout the checklist:

Tag	Meaning
`WA-REL` / `WA-RELn`	Well-Architected Lens — Reliability Pillar (question N)
`WA-SEC` / `WA-SECn`	Well-Architected Lens — Security Pillar
`WA-PE` / `WA-PEn`	Well-Architected Lens — Performance Efficiency Pillar
`WA-OE` / `WA-OEn`	Well-Architected Lens — Operational Excellence Pillar
`WA-CO`	Well-Architected Lens — Cost Optimization Pillar
`Security Hub [{Service}.N]`	AWS Security Hub CSPM control (e.g., `[ElastiCache.1]`)
`re:Post`	AWS re:Post knowledge center article
`Official Docs`	Service user guide / official documentation
`AWS Blog`	AWS Database Blog or other official blog
`Whitepaper`	AWS whitepaper

Step 6: Generate Checklist Output

Output the checklist using the exact format defined in references/output-template.md.

The output must include:

Title with service name
One table per category (5 tables)
Source annotation legend
Key reference links section

Step 7: Offer Next Steps

After presenting the checklist, suggest:

"I can save this checklist as a reference file for future audits."
"I can export this to a spreadsheet if you prefer."

If the user has already provided live audit info in Step 1, skip the suggestion and proceed directly to Step 8.

If the user has not provided live audit info, also suggest:

"If you provide AWS credentials and resource identifiers, I can audit a live resource against this checklist."

Step 8: Live Resource Audit (Optional)

Only execute this step if the user has provided credentials, region, and resource identifiers. If none were provided, skip this step entirely.

See references/audit-workflow.md for the detailed per-service audit procedure. The general flow is:

8.1 Prepare Environment

If the user provided a credential file path (e.g., env.sh), source it:

source <credential-file-path>

Verify access by running a simple describe command against the target service and region.

8.2 Collect Resource Configuration

Run the service-specific AWS CLI commands to gather the full configuration of the target resource. Execute independent commands in parallel to save time.

For ElastiCache Redis, the key commands are (see references/audit-workflow.md for the full list):

aws elasticache describe-replication-groups
aws elasticache describe-cache-clusters --show-cache-node-info
aws elasticache describe-cache-subnet-groups
aws elasticache describe-cache-parameters
aws elasticache list-tags-for-resource
aws elasticache describe-snapshots
aws elasticache describe-events

For other services, use the equivalent describe/list commands.

8.3 Map Configuration to Checklist

For each check item in the checklist, determine the audit status:

Status	Meaning
🟢 PASS	The resource configuration meets or exceeds the recommendation
🔴 FAIL	The resource configuration does not meet the recommendation
🟡 WARN	Cannot be fully verified from infrastructure alone (e.g., client-side settings), or partially meets the recommendation
⚪ N/A	The check does not apply to this resource (e.g., Global Datastore check when cross-region DR is not required)

For each item, record:

The check ID and name (from the checklist)
The audit status (PASS / FAIL / WARN / N/A)
A specific finding describing what was observed (include actual values)

8.4 Generate Audit Report

Output the audit results using the format defined in references/audit-output-template.md:

Resource Summary — key properties of the audited resource (engine, version, node type, topology, etc.)
Audit Results by Category — one table per category with Status + Finding columns
Audit Summary — counts of PASS/FAIL/WARN/N/A per category
Critical Issues — list of all FAIL items with Priority=High, with specific remediation guidance
Recommendations — grouped by urgency (Immediate / Short-term / Medium-term)

8.5 Offer Remediation

After presenting the audit results, suggest:

Which FAIL items can be fixed in-place (e.g., enabling backups, adding tags)
Which FAIL items require resource recreation (e.g., encryption at rest)
Whether you can help execute the remediation commands

Important Guidelines

Be comprehensive: Search broadly, read deeply. The value of this skill is completeness. It's better to include a check item and mark it as lower priority than to miss it.
Always cite sources: Every check item must have a source annotation. Users need to know where each recommendation comes from.
Use parallel searches: All 6 initial searches should run in parallel to save time. Page reads should also be parallelized where possible.
Focus on actionable items: Each check item should be something the user can verify against their actual configuration. Avoid vague recommendations.
Include specific thresholds: When documentation specifies numbers (e.g., "at least 2 replicas", "reserved-memory-percent >= 25%"), include them in the check description.
Note service-specific nuances: If a check only applies under certain conditions (e.g., "only if cluster mode enabled"), note that in the description.
Live audit is optional: Never fail or block if the user doesn't provide credentials. The checklist alone is a complete, valuable deliverable.
Respect language: Always output in the same language as the user's conversation.