AI Rules Across the AWS Deployment Landscape
AWS offers multiple deployment paths: Amplify (frontend hosting, similar to Vercel), CodePipeline + CodeBuild (CI/CD pipelines), CDK/CloudFormation (Infrastructure as Code), ECS/Fargate (container deployments), Lambda (serverless functions), and Elastic Beanstalk (managed application platform). Each path: has a different integration point for AI rules validation. The common principle: validate rules before deployment, fail the build if rules are missing or outdated.
The universal approach: the prebuild script (node scripts/validate-rules.js) works on every AWS deployment path that runs npm scripts. Amplify: runs prebuild automatically. CodeBuild: runs prebuild as part of the buildspec. ECS: runs during docker build. Lambda: runs during the packaging step. The prebuild script: the most portable solution, works across all AWS services.
AWS-specific rules: beyond validation, the CLAUDE.md should include AWS-specific conventions: IAM permissions (least privilege, never use root credentials), environment variables (from SSM Parameter Store or Secrets Manager, not hardcoded), logging (structured JSON for CloudWatch, include request IDs for tracing), and error handling (AWS SDK errors have specific patterns that differ from generic HTTP errors).
Step 1: Amplify and CodeBuild Integration
AWS Amplify: the simplest AWS deployment for frontend apps. Amplify reads amplify.yml (or uses auto-detected build settings). Integration: add the prebuild validation to the amplify.yml build phase. preBuild: commands: ['node scripts/validate-rules.js']. The validation runs before the build. If it fails: the deployment stops. Amplify also supports custom build images â but for rule validation, the standard Node.js image is sufficient.
CodeBuild (used by CodePipeline): define the validation in buildspec.yml. phases: pre_build: commands: ['node scripts/validate-rules.js']. The pre_build phase runs before the build phase. If the pre_build command exits with a non-zero code: the build fails, and CodePipeline stops the deployment. The validation: integrated into the pipeline as a first-class step.
CodePipeline with approval gates: for organizations that want human review of rule changes, add a Manual Approval action after the build stage and before the deploy stage. The approval: triggered when CLAUDE.md changes are detected (using a Lambda function that compares the current and previous versions). The approver: the tech lead or security lead, depending on the rule category. AI rule: 'CodePipeline approval gates: only for rule changes, not for every deployment. A Lambda function detects CLAUDE.md changes and triggers the gate conditionally.'
A manual approval gate on every deployment: slows the pipeline unnecessarily (most deployments do not change rules). A conditional gate: triggered only when CLAUDE.md changes are detected. Implementation: a Lambda function in the pipeline compares the current CLAUDE.md with the previous version. If different: trigger the approval gate. If identical: skip the gate and deploy immediately. Most deployments: deploy without waiting for approval. Rule changes: get human review.
Step 2: CDK and Container Deployments
AWS CDK (Infrastructure as Code): CDK builds and deploys the application as part of the infrastructure deployment. Integration: add the validation as a build command in the CDK pipeline. In the CodeBuildStep: commands: ['node scripts/validate-rules.js', 'npm run build']. The validation: runs before the application build, within the CDK pipeline. If it fails: the CDK deployment stops.
ECS/Fargate (container deployments): the application runs in Docker containers. The validation: included in the Dockerfile (as a build stage) or in the CodeBuild step that builds the Docker image. Dockerfile approach: COPY CLAUDE.md . then RUN node scripts/validate-rules.js as the first build stage. CodeBuild approach: validate rules before running docker build. Both approaches: ensure the container image is only built if rules are valid.
Lambda deployments: Lambda functions are packaged as zip files or container images. For zip-based deployments: the validation runs during the packaging step (before the zip is created). For container-based Lambda: the validation runs during docker build (same as ECS). For SAM/CDK-based Lambda: the validation runs in the CodeBuild step before the SAM build. AI rule: 'Lambda rule validation: happens at packaging time, not at invocation time. By the time the Lambda runs: the rules are already validated and the code is convention-compliant.'
The AI generates: const client = new S3Client({ credentials: { accessKeyId: 'AKIA...', secretAccessKey: '...' } }). This is the most common AWS security violation in AI-generated code. The CLAUDE.md rule: 'Never hardcode AWS credentials. Use IAM roles (EC2/ECS/Lambda get credentials from the instance metadata automatically). The SDK reads credentials without explicit configuration when running on AWS.' With this rule: the AI generates const client = new S3Client({}) â which uses the IAM role automatically.
Step 3: AWS-Specific Rules for CLAUDE.md
IAM and credentials: 'Never hardcode AWS credentials. Use IAM roles for EC2/ECS/Lambda (the SDK reads credentials from the instance metadata). For local development: use AWS profiles (aws configure). For CI/CD: use OIDC federation with GitHub Actions or CodePipeline service roles. The AI must never generate code with AccessKeyId or SecretAccessKey as string literals.'
Configuration from SSM/Secrets Manager: 'Application configuration: read from AWS SSM Parameter Store (for non-sensitive config) or AWS Secrets Manager (for secrets like database passwords, API keys). Use the AWS SDK's SSM client or Secrets Manager client. Cache configuration values (do not call SSM on every request). The AI generates configuration loading code that uses SSM/Secrets Manager, not environment variables hardcoded in task definitions.'
CloudWatch logging: 'Log format: structured JSON with fields: timestamp, level, message, requestId (from the Lambda context or ECS request), service (application name), and custom fields. Use a structured logger (pino, winston with JSON transport). CloudWatch Logs Insights: queries structured JSON efficiently. Unstructured log.info(message) logs: searchable but not queryable by field.' AI rule: 'AWS-specific rules ensure: the AI generates code that works correctly on AWS infrastructure from the first deployment, using AWS-native patterns for credentials, configuration, and logging.'
Environment variables in ECS task definitions or Lambda configuration: visible in the AWS Console, stored in CloudFormation templates (potentially in git), and not rotatable without redeployment. SSM Parameter Store: encrypted at rest, access-controlled by IAM, version-tracked, and changeable without redeploying the application. The AI rule: 'Read configuration from SSM Parameter Store. Cache values in memory (refresh every 5 minutes). Do not read from process.env for sensitive configuration.' This pattern: is AWS-native and more secure than environment variables.
AWS AI Rules Summary
Complete AWS AI rules sync setup.
- Universal: prebuild script works on Amplify, CodeBuild, ECS, Lambda â any AWS service running npm
- Amplify: prebuild in amplify.yml. Fails deployment if rules are missing
- CodeBuild/CodePipeline: pre_build phase in buildspec.yml. Optional approval gates for rule changes
- CDK: validation in CodeBuildStep commands. Runs before app build within the CDK pipeline
- ECS/Fargate: Dockerfile first stage or CodeBuild pre-build. Container only built if rules valid
- Lambda: validation at packaging time (zip or container). Not at invocation time
- AWS rules: IAM roles (never hardcode credentials), SSM/Secrets Manager (not env var literals), CloudWatch JSON logging
- Portability: the same prebuild script works on AWS, Vercel, Netlify, Railway, and any npm-based platform