Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/beettlle/pi-spineWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/beettlle/pi-spine/aws-fargate-best-practices)<a href="https://agentmods.dev/rules/beettlle/pi-spine/aws-fargate-best-practices"><img src="https://agentmods.dev/badge/rules/beettlle/pi-spine/aws-fargate-best-practices/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/beettlle/pi-spine/aws-fargate-best-practices"><img src="https://agentmods.dev/badge/rules/beettlle/pi-spine/aws-fargate-best-practices.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.03085 |
| Opus 5 | $0.00000 | $0.01543 |
| Sonnet 5 | $0.00000 | $0.00617 |
| Haiku 4.5 | $0.00000 | $0.00309 |
Grade A, and why
aws-fargate-best-practices scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
✅ Good: Fargate task health checks configured (`"healthCheck": {"command": ["CMD-SHELL", "curl -f http://localhost:8888/health || exit 1"], "interval": 30, "timeout": 5, "retries": 3, "startPeriod": 60}`), application he How it starts
The opening of the file, as written. The whole thing — 207 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Persona: AWS ECS/Fargate Specialist
- Role: Container orchestration expert. Philosophy: "Secure by default, right-sized by design."
- Traits: Security-first (non-root containers), Performance-aware (resource optimization), Observability-focused (comprehensive logging)
AWS Fargate Best Practices
This file contains Fargate-specific anti-patterns and best practices for container orchestration on AWS.
For general AWS patterns: See aws-general-best-practices.mdc
For project-specific Fargate patterns: See project-specific rules file or project-conventions.md
For universal anti-patterns: See general-llm-anti-patterns.mdc
Category 1: Task Definition Anti-Patterns (CRIT)
1.1 Hardcoded Secrets in Task Definitions (CRIT)
CRITICAL: Never pass secrets (database passwords, API keys) via environment variables in task definitions.
❌ Bad: "environment": [{"name": "DB_PASSWORD", "value": "secret123"}] (secrets in plaintext)
✅ Good: Use AWS Secrets Manager in task definitions ("secrets": [{"name": "DATABASE_PASSWORD", "valueFrom": "arn:aws:secretsmanager:..."}]), IAM task role has permission to read specific secrets only
⚠️ Why: Environment variables visible in task definitions, CloudWatch logs, and container inspection; secrets in plaintext violate security best practices
🔧 Fix: Store secrets in AWS Secrets Manager, reference using secrets field in task definition, use IAM permissions to restrict access
📍 See: aws-general-best-practices.mdc section 1.4
Detect: Secrets in environment field, plaintext passwords in CloudFormation/CDK, secrets in container environment variables, missing IAM permissions for Secrets Manager, secrets visible in CloudWatch Logs
1.2 Missing IAM Task Roles (CRIT)
CRITICAL: Fargate tasks must use IAM task roles, not hardcoded credentials or user access keys.
❌ Bad: Fargate task without task role, using root account credentials, passing AWS credentials via environment variables
✅ Good: Configure separate task execution role and task role (executionRoleArn for ECR/CloudWatch/Secrets Manager, taskRoleArn for application AWS API calls), separate task roles for web service and crawler/indexer service
⚠️ Why: Task execution role has different permissions than task role; separation enables least privilege; long-lived credentials are security risk
🔧 Fix: Create separate IAM roles for task execution and task, attach task role to task definition, grant only required permissions to each role
📍 See: aws-general-best-practices.mdc section 1.1
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 207 lines · 0 tokens per session scan A da5d913fef8c
aws-fargate-best-practices is a cursor rule published in the GitHub repository beettlle/pi-spine (3 stars, last pushed 5d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 3,085 tokens. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other cursor rules, from other repositories
aws-ecs
Definitive guidelines for building, deploying, and operating applications on AWS ECS, emphasizing immutable containers, secure secrets management, and robust operational patterns.
kubernetes
This guide defines definitive best practices for writing, organizing, and securing Kubernetes manifests and Operators, ensuring maintainable, performant, and reliable cloud-native deployments.
kubernetes
Kubernetes and OpenShift workload generation rules — security defaults, resource limits, probes.
build-deployment
Build, CMake, and Docker deployment.
kubernetes-helm
Kubernetes and Helm best practices including resource management, security, chart organization, and deployment patterns.
deployment
Rails Deployment with Kamal.