aws-toolkit

Design and operate AWS the way a Solutions Architect does. The default move is managed-first: prefer the service that removes undifferentiated heavy lifting, so owning a server becomes the last resort. The hard part is choosing the most managed option that still meets the constraint, scoping the IAM policy, containing the blast radius, and proving the control before an auditor or an attacker finds it.

This skill is advisory and authors IaC by default. A provision or apply is an external mutation that runs only behind a reviewed plan and explicit, recorded approval, never freehand from a step here.

Climb the determinism ladder: express a rule as an AWS CLI command, a Config rule, or a Service Control Policy before you write it as prose, and turn a checklist into a lint or policy-as-code gate. Judgment takes the last rung.

Steps

1. State the workload and its bar. Write what the workload must do, its traffic and state shape, its data classification, the environment (production carries the higher bar), and the compliance regime in scope. The constraints recorded here are what every later managed-service choice is measured against. This step is done when the workload, its data classification, and its environment are written down.

2. Choose the most managed service that meets the constraint. Walk the compute and data decisions through the managed-first reference: Lambda before Fargate before EC2 for compute; DynamoDB or Aurora Serverless before RDS before a self-managed database; S3, SQS, SNS, EventBridge, Cognito, and Step Functions for the glue. Reach for a server only where a recorded constraint from step 1 rules the managed option out. This step is done when each compute and data component names its chosen service, and each self-managed choice names the constraint that forced it.

3. Apply the six Well-Architected pillars. Take a named stance on operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability, per the Well-Architected reference. A pillar with no stance counts as a gap. This step is done when each of the six pillars carries a written stance for this workload.

4. Lay the security baseline. Grant access through IAM roles, never long-lived keys. Scope every policy to explicit actions and resource ARNs, encrypt at rest with KMS and in transit with TLS, close the network, and turn on CloudTrail, Config, and GuardDuty, per the security-baseline reference. This step is done when no policy carries * in Action or Resource, every data store declares a KMS key, and CloudTrail is on for the account.

5. Author as IaC and attach cost controls. Express every resource in Terraform or CDK with pinned versions and remote, locked state, and keep the console out of the change path: click-ops leaves no diff for a reviewer to read. Set an AWS Budget with an alert and apply the mandatory tag set, then pull the cost levers (right-size, Graviton, Savings Plans or Spot, S3 lifecycle) named in the Well-Architected cost section. This step is done when terraform validate (or cdk synth) passes clean, the budget alert exists, and every resource carries the required tags.

6. Review against Well-Architected and the red flags. Check the design against each pillar's failure modes and the security red flags: public S3, wildcard IAM, hardcoded keys, no CloudTrail, a server where a managed service fits, click-ops. Run a policy-as-code scan over the IaC (checkov by default, tfsec or trivy config only where checkov is absent), so a misconfiguration red flag surfaces from a deterministic scanner and the same repo is always judged by the same tool. This step is done when the scan reports no unaddressed HIGH finding and each remaining red flag is marked absent or recorded as an accepted risk with a named owner.