aws-platform-engineering

Files (15)

• SKILL.md
• aws_pe_mcp_server.py
• adr.md.tmpl · templates/
• base-image-policy.md.tmpl · templates/
• bedrock-service.tf.tmpl · templates/
• container-scan-scout.yml.tmpl · templates/
• container-scan-trivy.yml.tmpl · templates/
• dependabot-container.yml.tmpl · templates/
• ecr-scan-on-push.tf.tmpl · templates/
• ecs-fargate-service.tf.tmpl · templates/
• github-actions-oidc.yml.tmpl · templates/
• golden-path.md.tmpl · templates/
• landing-zone.md.tmpl · templates/
• static-egress-vpc.tf.tmpl · templates/
• terraform-module.tf.tmpl · templates/

SKILL.md (first lines)

# AWS Platform Engineering — Cursor skill

Eight bound capabilities, each backed by a template under `templates/`.
Capabilities are listed in the order an agent typically reaches for them.
Capability removal or addition lands via a successor ADR (per ADR-005 §Compliance).

This skill is the *generation* layer for the AWS Platform Engineer persona at
[`.cursor/agents/aws-platform-engineer.md`](../../agents/aws-platform-engineer.md).
The persona owns *intent*; this skill owns *artifacts*.

> Sources marked **`AWS-prescriptive`** are normative — capabilities marked this
> way encode AWS prescriptive guidance verbatim and the agent is not free to
> deviate without a written justification cited in the generated artifact.

---

## Capability index

| # | Capability | Template | `AWS-prescriptive`? |
|---|---|---|---|
| 1 | `bootstrap-landing-zone-skeleton` | [`templates/landing-zone.md.tmpl`](templates/landing-zone.md.tmpl) | yes — SRA + landing-zone guide |
| 2 | `generate-terraform-module` | [`templates/terraform-module.tf.tmpl`](templates/terraform-module.tf.tmpl) | partial — module shape per CAF Platform |
| 3 | `generate-actions-oidc-workflow` | [`templates/github-actions-oidc.yml.tmpl`](templates/github-actions-oidc.yml.tmpl) | yes — CAF Platform "no long-lived credentials" |
| 4 | `generate-adr` | [`templates/adr.md.tmpl`](templates/adr.md.tmpl) | yes — AWS prescriptive ADR process |
| 5 | `generate-platform-service-skeleton` | [`templates/ecs-fargate-service.tf.tmpl`](templates/ecs-fargate-service.tf.tmpl) | partial — ALB layout per ALB/subnet guide |
| 6 | `generate-bedrock-service-skeleton` | [`templates/bedrock-service.tf.tmpl`](templates/bedrock-service.tf.tmpl) | partial — GenAI blueprint |
| 7 | `generate-static-egress-vpc` | [`templates/static-egress-vpc.tf.tmpl`](templates/static-egress-vpc.tf.tmpl) | yes — static-outbound-IP pattern |
| 8 | `generate-golden-path-doc` | [`templates/golden-path.md.tmpl`](templates/golden-path.md.tmpl) | yes — AWS IDP guide vocabulary |
| 9 | `generate-container-scan-workflow` (Trivy — primary) | [`templates/container-scan-trivy.yml.tmpl`](templates/container-scan-trivy.yml.tmpl) | yes — container supply chain |
| 10 | `generate-container-scan-scout-workflow` (Docker Scout — alternative) | [`templates/container-scan-scout.yml.tmpl`](templates/container-scan-scout.yml.tmpl) | partial — alternative tool, same artifact contract |
| 11 | `generate-ecr-scan-on-push` | [`templates/ecr-scan-on-push.tf.tmpl`](templates/ecr-scan-on-push.tf.tmpl) | yes — ECR Enhanced + Inspector V2 |
| 12 | `generate-base-image-policy` | [`templates/base-image-policy.md.tmpl`](templates/base-image-policy.md.tmpl) | yes — pin by digest; minimal/distroless; non-root; HEALTHCHECK |
| 13 | `generate-dependabot-container` | [`templates/dependabot-container.yml.tmpl`](templates/dependabot-container.yml.tmpl) | partial — keep pinned digests current |

---

## 1. `bootstrap-landing-zone-skeleton` — `AWS-prescriptive`

**When to use.** A new tenant or a major workload requires a fresh AWS landing
zone (e.g., a new regulated environment, a new business unit). The output is a
*scaffold doc* + a top-level `infrastructure/landing-zones/<name>/` directory
shape that an operator can take to Control Tower (preferred) or to a custom
Organizations + Landing Zone Accelerator deployment.

**Inputs.**

- `landing_zone_name` — short kebab-case identifier (e.g., `pharm-prod`).
- `tenant` — Catalyst tenant slug (per `tenant/*` label).
- `regions` — primary + DR regions (e.g., `us-east-1` + `us-west-2`).
- `account_baseline` — `control-tower` (default) or `organizations`.

**Output shape.** A markdown scaffold doc + directory layout matching the SRA:

```
infrastructure/landing-zones/<name>/
├── README.md                         # rendered from template
├── org/
│   ├── ous.tf                        # Workloads / Infrastructure / Security OUs
│   ├── scps/
│   │   ├── deny-leave-org.json
│   │   ├── deny-root-actions.json
│   │   └── deny-disable-cloudtrail.json
│   └── delegated-admin.tf            # Security Tooling = delegated admin
├── accounts/
│   ├── org-management/               # billing, SCPs, Org-trail
│   ├── security-tooling/             # GuardDuty, Security Hub, Inspector, Macie, Access Analyzer
│   ├── log-archive/                  # Org CloudTrail S3 + KMS
│   ├── network/                      # TGW, central egress, NFW, DNS
│   ├── shared-services/              # SSO, image factory, internal mirrors
│   └── workloads/<app>-<env>/        # one per (app x env)
└── docs/
    └── golden-paths/                 # rendered via capability #8
```

**Guardrails.**

- The skeleton MUST instantiate the SRA OU shape verbatim
  ([SRA architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html)).
- Security services live in the **Security Tooling** account as the delegated
  admin
  ([SRA — Security Tooling](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)).
- CloudTrail organization trail writes to the **Log Archive** account only,
  with bucket policy denying writes by anyone outside the organization.
- `account_baseline=control-tower` is the default; `organizations` is allowed
  but the scaffold doc must call out which Control Tower features the operator
  is foregoing (account factory, account customization, drift detection,
  centralised guardrails) and what they will replace those with (e.g., LZA).
- All seven landing-zone foundational features MUST be addressed in the
  scaffold doc
  ([Understanding landing zones](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html)):
  multi-account architecture, security baseline, identity, governance, data
  security, network design, logging.

**Composition.** Pair with capabilities #2 (per-account modules), #3 (CI for
each account), #8 (golden-path docs for the developer-facing services).

---

## 2. `generate-terraform-module`

**When to use.** Any new reusable infra primitive (a VPC, an RDS cluster, an
S3 bucket pattern, an SQS DLQ pattern, etc.) lands as a Terraform module under
`infrastructure/modules/` first; consumer code wires modules together.

**Inputs.**

- `module_name` — kebab-case (e.g., `s3-encrypted-bucket`).
- `module_type` — `resource` (single-purpose) or `composite` (multi-resource).
- `aws_provider_version` — pinned (e.g., `~> 5.60`).
- `inputs` — list of `{ name, type, description, default? }` objects.
- `outputs` — list of `{ name, description }` objects.

**Output shape.**

```
infrastructure/modules/<resource|composite>/<module-name>/
├── README.md
├── versions.tf
├── variables.tf

From Cloud-Byte-Consulting/Catalyst, BSD-3-Clause.

More from Cloud-Byte-Consulting/Catalyst