What this prompt does
This prompt makes the AI design an S3 + CloudFront delivery architecture for serving [content_type] for your [application_type]. It configures [bucket_name] with versioning, [encryption_type] encryption, lifecycle rules for [lifecycle_strategy], and blocked public access; sets up a CloudFront distribution with OAC and [cache_behaviors] behaviors (including [media_cache_ttl] for media); configures [domain] with ACM and Route 53; adds a security-headers policy; creates a CI/CD invalidation step for [invalidation_paths]; optimizes cost with compression and [price_class]; enables logging to [log_bucket]; and attaches WAF with [waf_rules].
The structure works because it treats the bucket as private and serves everything through CloudFront via Origin Access Control, which closes the public-bucket hole most leaky setups have. Getting cache behaviors and the security-headers policy right the first time avoids the cache-busting and header-rewrite cleanup common on inherited projects. Tailoring the design to [content_type] and [application_type] matters because a React SPA with user uploads needs different cache and lifecycle rules than a purely static site, and the prompt accounts for that split rather than treating all assets the same.
When to use it
- You are putting a CDN in front of an app's static assets or a single-page build.
- You want the origin bucket fully private with access only through CloudFront via OAC.
- You need distinct cache behaviors for static assets, dynamic content, and media with
[media_cache_ttl]. - You need a security-headers response policy (CSP, HSTS, X-Frame-Options) applied at the edge.
- You want a CI/CD step that invalidates
[invalidation_paths]on every deploy so users get fresh files. - You need WAF protection with rate limiting and
[waf_rules]in front of public content.
Example output
Expect an architecture spec covering the S3 bucket config (versioning, [encryption_type], lifecycle, public-access block), the CloudFront distribution with OAC and [cache_behaviors] cache behaviors, a custom-domain setup with ACM and Route 53, a response-headers policy, a CI/CD invalidation snippet for [invalidation_paths], cost settings (compression, [price_class], Intelligent Tiering), access-logging to [log_bucket], and a WAF web ACL with [waf_rules].
Pro tips
- Use OAC and block all public access on
[bucket_name]; serving a public bucket directly is the leaky-bucket pattern this design exists to avoid. - Set cache behaviors deliberately — long TTLs for fingerprinted static assets, no-cache for HTML, and
[media_cache_ttl]for media — so deploys are not served stale. - Invalidate only
[invalidation_paths]that actually change (like /index.html), not /*, since broad invalidations cost more and undercut caching. - Define the security-headers policy as a reusable CloudFront response-headers policy rather than setting headers per-origin, which is easier to audit.
- Match
[price_class]to where your users are; PriceClass_100 is cheaper but excludes some regions, so do not pick it if you serve a global audience. - Use
[lifecycle_strategy]to transition old media to cheaper storage classes, but confirm retrieval latency from Glacier is acceptable for your access pattern. - Enable access logging to
[log_bucket]from the start; reconstructing traffic patterns or debugging a cache-hit problem is far easier with logs you already have than ones you wish you had turned on.
