AI image generation on AWS — the models, the prompting, and the path to production.

IWhy image generation on AWS is a Bedrock decision first

You can run image models a dozen ways — a hosted API from a model lab, a GPU instance running an open checkpoint, a third-party SaaS. On AWS the centre of gravity is Amazon Bedrock, because it turns "which model" into a runtime parameter instead of an infrastructure project.

Bedrock exposes image models through the same InvokeModel surface it uses for text: you pass a JSON body, you get bytes (base64-encoded PNGs) back. There are no GPUs to provision, no checkpoints to download, no container to keep warm. The image model is a serverless endpoint behind your AWS account's IAM, billed per image generated rather than per GPU-hour rented. For most teams that is the decisive difference — the alternative, standing up your own diffusion serving stack on EC2 or SageMaker, only pays off at very high, very steady volume.

The trade you accept is the standard managed-service trade. You get the models AWS and its partners choose to host, at the versions they choose to expose, with the parameters they surface. You give up the ability to load an arbitrary community fine-tune or LoRA the day it drops on a model hub. For the overwhelming majority of commercial image work — product photography, marketing creative, thumbnails, synthetic data — the hosted models are more than sufficient, and the operational savings are large. Teams that genuinely need bespoke checkpoints or LoRA stacks self-host on SageMaker or raw EC2 with Inferentia/GPU; everyone else uses Bedrock.

The second reason AWS is a coherent home for image generation is everything downstream of the model. The images have to land somewhere (S3), be served fast and cheap to users (CloudFront), be moderated (Rekognition or Bedrock Guardrails), and sometimes be tracked for provenance (invisible watermarks). All of that is native AWS plumbing that sits naturally beside a Bedrock call. The model is one box in the diagram; the pipeline is the product.

A note on framing for the rest of this guide: "image generation" here means text-to-image and image-to-image inference for production use — generating, editing, and delivering pictures at scale — not training image models from scratch, which is a different (and far more expensive) discipline.

IIThe three model families on Bedrock — what each is for

Bedrock's image catalogue is three families, each with a clear centre of gravity. Picking well is mostly about matching the family to the job rather than chasing a single "best" model.

The honest summary: Nova Canvas is the default for most new builds because it pairs strong prompt adherence with built-in editing and conditioning; Titan is the cheap, dependable workhorse with the broadest track record and a built-in invisible watermark; Stable Image is the one you reach for when you want photographic realism or a specific artistic register that the Amazon models render more conservatively.

IIIThe three families, compared on the axes that matter

Quality is subjective and version-dependent; the durable differences are in control surface, watermarking, editing support and price. Those are the axes that should drive the choice.

IVPrompting that works — structure, style, negatives, seeds

There are no magic words. There is structure. A prompt is a specification, and the models reward specifications that name the right things in a sensible order, then subtract the unwanted with a negative prompt.

The reliable structure is subject → composition → lighting → medium/style → quality bar. "A ceramic coffee mug" is a subject. "A matte-white ceramic coffee mug, centred, three-quarter view, on a light oak table, soft diffused window light from the left, shallow depth of field, product photography, sharp focus, high detail" is a specification. The second prompt does not produce a better image because it is longer; it produces a better image because every clause removes a degree of freedom the model would otherwise resolve at random.

Order matters less than coverage, but front-loading the subject helps — the models weight earlier tokens slightly more. Keep clauses concrete and visual ("soft diffused window light") rather than abstract or emotional ("beautiful", "amazing"), which the models cannot render. Camera and lens language ("35mm", "macro", "wide angle") is genuinely effective for photographic output because it appears in the captioned training data. Medium words ("oil painting", "watercolour", "3D render", "vector illustration", "product photo") are the single biggest lever on overall look.

The negative prompt is the other half of the specification and the most under-used control. Rather than fighting an artefact by adding more positive words, name the artefact in the negative field: "blurry, low quality, distorted hands, extra fingers, watermark, text, jpeg artefacts, oversaturated". On the Amazon models this is the negativeText field; on Stability it is negative_prompt. A good negative prompt is reusable across a whole product line — build one, tune it once, apply it everywhere.

VEditing — inpainting, outpainting, variations, background removal

Generation is only half of production image work; the other half is editing what you generated (or what a photographer shot). The Amazon models expose these as first-class operations; Stability offers them through dedicated edit endpoints.

Treat the editing operations as a small, composable vocabulary. Most real workflows chain two or three of them — generate a base, remove the background, then outpaint a new scene around the subject — rather than relying on a single perfect generation. Building the pipeline around edits is what separates a demo from a system.

• Inpainting (replace inside a mask) — Supply an image plus a mask and a prompt; the model regenerates only the masked region to match the prompt while blending into the surroundings. Used to swap a product colour, remove an unwanted object, fix a flawed area, or change a label. On Nova Canvas/Titan this is a taskType on the same model; masks can be a painted image or, on Nova, a text mask ("the mug") that the model resolves itself.
• Outpainting (extend beyond the frame) — Supply an image and a mask describing the new area; the model paints a coherent extension outward. The workhorse for reformatting one asset into many aspect ratios — turn a square product shot into a 16:9 banner or a vertical story without re-shooting. Critical for ad pipelines that need every creative in five sizes.
• Image variation — Supply a reference image and (optionally) a prompt; the model produces alternates that preserve the subject and overall composition while varying the rest. Used to generate a family of on-brand options from one approved hero, or to refresh an existing asset without starting from a text prompt.
• Background removal — A dedicated operation (native in Nova Canvas and Titan v2) that segments the subject and returns a transparent-background PNG. The bread-and-butter of ecommerce — a clean cut-out product on transparency that can be composited onto any backdrop downstream.
• Image conditioning (guided layout) — On Nova Canvas, pass a reference image with a conditioning mode (canny edges or segmentation) so generation follows the reference's structure while the prompt drives style and content. Used to keep a fixed layout — a packshot composition, a UI frame, a floor plan — while restyling everything inside it.
• Image-to-image (style/strength transfer) — Start from an input image rather than pure noise and let a strength parameter control how far the model departs from it. Lower strength keeps the source largely intact (subtle restyle); higher strength uses it as loose inspiration. Available across the families with model-specific field names.

VIProduction patterns — batch, storage, and S3 + CloudFront delivery

A single InvokeModel call is a toy. A production image system is a pipeline: request handling, batch generation, durable storage, fast delivery, and moderation. Here is the shape that works on AWS.

The canonical architecture is small and boring, which is the point. A request arrives at API Gateway and a Lambda function; the Lambda calls Bedrock InvokeModel for the chosen model; the returned base64 image is decoded and written to an S3 bucket with a content-addressable key; the object is served to end users through a CloudFront distribution sitting in front of that bucket. Metadata — prompt, negative prompt, seed, model ID, parameters — is written to DynamoDB so any image can be traced and regenerated. That is the entire backbone.

For anything beyond interactive single-image generation, decouple the request from the work with a queue. The user (or upstream job) drops a generation request onto SQS; a fleet of Lambda or Fargate workers pulls from the queue, calls Bedrock, and writes results to S3. This absorbs spikes, gives you natural retry and dead-letter handling for the occasional throttle or content-filter rejection, and lets you respect Bedrock's per-model rate limits with a simple concurrency cap on the consumer. Generating a thousand product images is a queue-drain, not a thousand synchronous calls.

Delivery is where cost and latency are won or lost. S3 is durable but is object storage, not a CDN — serving images straight from S3 to a global audience is slow and pricey on egress. Put CloudFront in front: it caches images at edge locations close to users, collapses repeat requests, and makes S3-to-CloudFront data transfer free, so you pay the cheaper CDN egress rate instead of raw S3 egress. For user-generated or sensitive imagery, serve through signed CloudFront URLs or origin access control so the S3 bucket itself stays private. Set long cache TTLs (generated images are immutable — the same key never changes) and you serve most traffic from cache for pennies.

VIIWhat it actually costs — per image, end to end

Image generation is priced per image, not per token, which makes the unit economics unusually easy to reason about. The model call is usually the largest line item, but storage and delivery are not zero at scale.

The model cost is a function of three things: which model, which resolution, and (on the Amazon models) which quality tier. As a rough 2026 map: Titan standard at 512×512 is the cheapest meaningful option (around $0.008/image); Titan premium and Nova Canvas at standard resolutions sit in the $0.04–$0.06 band; Stable Image Core is roughly $0.03–$0.04; SD 3.5 around $0.04–$0.07; and Stable Image Ultra at the top is roughly $0.08–$0.12. Higher resolution and premium tiers push toward the top of each range. Always confirm against the live Bedrock pricing page, but the ordering — Titan cheapest, Ultra dearest — is stable.

The pipeline costs are small per image but real in aggregate. S3 storage is a few cents per GB-month; a generated PNG is typically a fraction of a megabyte, so a million stored images is on the order of low-hundreds of dollars per month of storage. The cost that surprises teams is egress: serving images directly from S3 to users runs at S3 egress rates, whereas serving through CloudFront both caches (so most requests never hit S3) and bills at lower CDN egress rates with free S3-to-CloudFront transfer. At any real traffic level the CDN pays for itself many times over.

The honest end-to-end framing: for a typical marketing or ecommerce workload generating tens of thousands of images a month and serving them behind a CDN, the all-in AWS cost is dominated by the per-image model fee, with storage and delivery as a modest tail. The lever with the most leverage is generating drafts cheap and reserving premium/high-res for finals — that one discipline routinely halves the model bill.

VIIIWatermarking, safety and licensing — the facts before you ship

The model and the prompt get the attention; watermarking, content safety and usage rights are what actually gate a launch. These are not optional polish — they are the difference between a pilot and something a brand or a regulated business can put its name on.

Watermarking and provenance: images from Amazon Nova Canvas and Titan carry an invisible, machine-detectable watermark by default, and AWS provides a way to check whether an image was produced by these models. This is genuinely useful — it lets you (and downstream parties) verify provenance and is increasingly relevant as AI-content disclosure expectations harden. Stability's models on Bedrock do not embed an invisible watermark by default, so if provenance tracking matters for your use case you either choose an Amazon model or add your own provenance metadata (for example, C2PA-style content credentials) in your pipeline.

Content safety: every image-generation path needs a moderation layer, both inbound (block prompts that request disallowed content) and outbound (catch outputs that slipped through). The Amazon models apply built-in moderation and will refuse certain requests; do not rely on that alone. Add your own controls — Amazon Bedrock Guardrails for prompt-level policy, and Amazon Rekognition's moderation labels on generated images to flag unsafe content before it is stored or served. For user-generated workflows this is mandatory, not optional, and it is far cheaper to run a moderation pass than to clean up after a bad image ships.

Licensing and usage rights: the commercial-use terms come from the model provider, surfaced through Bedrock's model access flow, and they are not uniform across the three families — Amazon's models and Stability's models carry their own terms, and some require accepting an end-user licence agreement before access is granted. Before you build a business on generated imagery, read the specific terms for the specific model you will ship, confirm commercial use is permitted for your scenario, and keep records of which model produced which asset (that DynamoDB metadata again). "It came out of an AI" is not a licence; the model provider's terms are.

• Watermark by default? — Yes for Nova Canvas and Titan (invisible, detectable). No for Stability models — add your own provenance if required.
• Inbound moderation — Built-in refusals on the Amazon models + Bedrock Guardrails for your own prompt policy. Never trust the model's defaults as your only line.
• Outbound moderation — Run Rekognition moderation labels on generated images before storing/serving, especially for user-generated or public-facing output.
• Commercial licence — Provider-specific and surfaced at model-access time; some require accepting an EULA. Verify per model before shipping; retain model-ID metadata per asset.

IXUse cases — ecommerce and marketing, concretely

The abstractions land when you map them to real jobs. Two domains drive most commercial image-generation volume on AWS, and each uses a recognisable subset of the toolkit.

Ecommerce is the highest-volume use case and the one where the editing toolkit matters most. The pattern: shoot or generate a product, run background removal to a transparent cut-out, then outpaint or composite the subject into many lifestyle scenes and many aspect ratios without a new shoot. Image variation produces on-brand alternates for testing; inpainting swaps colourways or fixes flaws; conditioning keeps a consistent packshot layout across an entire catalogue. The economic story is stark — replacing a fraction of a studio shoot with generated and edited imagery removes a per-SKU cost that scales with catalogue size, and the per-image AWS cost is cents.

Marketing creative leans more on generation quality and reformatting. The pattern: generate hero imagery (often Stable Image Ultra or Nova Canvas for the look), then outpaint each approved hero into the full set of channel formats (square, story, banner, wide) so one creative idea ships everywhere consistently. Seeds give controlled A/B variants from a single concept; negative prompts enforce brand consistency (no text, no clutter, a specific palette) across a campaign. The win is speed and volume — a campaign's worth of on-brief, correctly-sized creative in an afternoon instead of a week.

Two more that recur: thumbnail and content imagery at scale (blogs, listings, courses) where Titan's low unit cost dominates and quality requirements are moderate; and synthetic data generation, where image-to-image and controlled seeds produce labelled training variations for downstream computer-vision models. Both are volume plays where the per-image economics and the batch pipeline — not the single-image quality ceiling — decide whether the project is viable.