6.1 Amazon Bedrock Prompt Flows & Visual Orchestration

6.1 Amazon Bedrock Prompt Flows & Visual Orchestration

This independent study guide by OpenExamPrep helps candidates prepare for the AWS Certified Generative AI Developer - Professional (AIP-C01) examination. In modern cloud architectures, enterprise generative AI applications rarely rely on a single, isolated foundation model invocation. Production solutions require multi-step pipelines: ingesting user input, validating parameters, routing queries based on intent, retrieving contextual grounding from knowledge bases, invoking specialized foundation models with tailored prompt templates, and transforming or persisting outputs.

Amazon Bedrock Prompt Flows provides a managed, visual, low-code orchestration service specifically designed to build, test, version, and deploy these multi-step generative AI workflows. Developers can construct directed acyclic graphs (DAGs) in the Amazon Bedrock console or programmatically via the AWS SDKs and AWS CloudFormation, linking diverse functional nodes with explicit data connections.

---

Orchestration Spectrum: Prompt Flows vs. Agents vs. Step Functions

A critical competency evaluated on the AIP-C01 exam is selecting the appropriate orchestration service based on workload predictability, operational overhead, and autonomous reasoning requirements.

[!IMPORTANT] When an exam question specifies deterministic execution, predictable latency, or strict compliance guardrails without autonomous model-driven tool selection, choose Amazon Bedrock Prompt Flows. If the scenario requires the application to dynamically decide which tools to execute based on open-ended user requests, choose Amazon Bedrock Agents.

---

Prompt Flow Node Architecture & Capabilities

A Bedrock Prompt Flow is modeled as an interconnected network of nodes. Each node represents a distinct operational step with strictly typed inputs and outputs:

1. Flow Input Node (FlowInput)

• Acts as the entry point for data entering the flow.
• Accepts runtime payloads passed via the InvokeFlow API.
• Can define multiple named inputs with specific data types (String, Number, Boolean, Object, Array).
• Validates input structure against expected schemas before initiating downstream processing.

2. Flow Output Node (FlowOutput)

• Acts as the terminal point of an execution path.
• Emits final processed responses back to the invoking client.
• A single flow can have multiple Flow Output nodes corresponding to different terminal branches (e.g., standard summary output vs. error notification output).

3. Prompt Node (Prompt)

• Executes a foundation model inference using a defined prompt template.
• Can reference prompt templates managed in the Amazon Bedrock Prompt Management catalog or define inline prompts.
• Supports dynamic variable injection using double curly brace syntax ({{variable_name}}).
• Configured with model-specific inference parameters: temperature, top_p, max_tokens, and stopSequences.
• Supports system prompts to enforce persona, formatting constraints, and safety guidelines.

4. Condition Node (Condition)

• Evaluates branching expressions to route execution along distinct paths.
• Uses expression operators (equal to, greater than, less than, contains, starts with, boolean logic) to evaluate upstream node outputs.
• Enables deterministic routing without invoking an LLM for classification. For example, routing high-priority customer requests to a frontier model (Claude 3.5 Sonnet) and routine queries to a lightweight model (Amazon Nova Micro).

5. Collector Node (Collector)

• Synchronizes and gathers concurrent inputs from multiple upstream branches.
• Merges divergent execution paths back into a consolidated, structured array payload.
• Acts as a barrier synchronization point: the Collector node waits until all connected upstream branches complete before passing the unified array to downstream nodes.

6. Iterator Node (Iterator)

• Takes an incoming array of items (e.g., list of documents, customer reviews, or question items) and splits the array into individual items.
• Emits each item individually to downstream nodes, enabling item-by-item processing in parallel or sequential workflows.
• Frequently paired with a downstream Collector node to achieve fan-out / fan-in array processing patterns.

7. Knowledge Base Node (KnowledgeBase)

• Directly interfaces with Amazon Bedrock Knowledge Bases for managed retrieval-augmented generation (RAG).
• Accepts a search query string as input.
• Queries the underlying vector store (e.g., OpenSearch Serverless, Aurora pgvector, Pinecone) using vector or hybrid search.
• Outputs retrieved text passages, relevance scores, and source attribution metadata citations without requiring a custom Lambda lookup.

8. Lambda Function Node (LambdaFunction)

• Executes custom business logic by invoking an AWS Lambda function.
• Used for external database queries, CRM lookups, mathematical calculations, custom data validation, or calling external REST APIs.
• The Lambda function receives the input payload from upstream nodes and must return a JSON-serializable output conforming to the expected node output schema.

9. Storage Node (Storage)

• Persists intermediate or final flow artifacts directly into an Amazon S3 bucket.
• Enables compliance archiving, audit logging of intermediate model reasoning steps, and asynchronous decoupled handoffs to external analytical systems.

---

Data Connections, Schema Contracts & Topology Rules

Connections between nodes in a Bedrock Prompt Flow define how data propagates through the pipeline:

• Data Compatibility: The data type emitted by an upstream node's output port must match the data type expected by the downstream node's input port (e.g., connecting a String output to a String input).
• Directed Acyclic Graph (DAG) Constraint: Prompt Flows strictly enforces acyclic topology. Circular dependencies, recursion, and backward loops are prohibited. For complex iteration, long-running coordination, or service-level retries, compare Step Functions or application orchestration with the current Flow feature set instead of assuming one mandatory service.
• Multiple Inputs: Nodes such as Prompt nodes can receive multiple inputs from different upstream nodes, mapping them to distinct prompt template variables.

---

Prompt Flow Lifecycle: Building, Versioning & Aliases

In enterprise software development lifecycles, separating development modifications from stable production workloads is mandatory. Amazon Bedrock Prompt Flows implements a robust versioning and aliasing model:

[Working Draft (DRAFT)]
         │
         ▼ (CreateFlowVersion)
  [Version 1 (Immutable)]  ───►  [Alias: DEV]
         │
         ▼ (CreateFlowVersion)
  [Version 2 (Immutable)]  ───►  [Alias: PROD (100%)] or [Canary Routing (80/20)]

Working Draft (DRAFT)

When a developer creates or edits a flow, changes occur within the mutable DRAFT version. The draft version can be tested iteratively in the Bedrock console or via test API calls. However, production applications should never directly invoke the DRAFT version, as ongoing modifications can introduce breaking schema changes or untested prompt regressions.

Immutable Versions

Calling the CreateFlowVersion API (or publishing a version in the console) creates a static, numbered, immutable snapshot (e.g., 1, 2, 3) capturing the exact graph definition, node configurations, prompt templates, and model parameters at that moment in time. Once created, a version cannot be edited.

Flow Aliases (FlowAlias)

A Flow Alias is a named pointer (e.g., DEV, STAGING, PROD) that points to a specific published numerical version.

• Zero-Downtime Cutover: Updating a production release is achieved by repointing the PROD alias from Version 1 to Version 2 via the UpdateFlowAlias API, requiring zero changes in client applications.
• Instant Rollback: If a regression is detected in production, the alias can be immediately repointed to the prior stable version.
• Routing Configurations: Aliases support routing configurations, allowing traffic splitting (e.g., 90% to Version 1, 10% to Version 2) for canary deployments and A/B prompt testing.

Runtime Invocation via InvokeFlow API

Applications invoke a Prompt Flow at runtime using the InvokeFlow API provided by the bedrock-agent-runtime service endpoint:

aws bedrock-agent-runtime invoke-flow \
    --flow-identifier "FLOW123456" \
    --flow-alias-identifier "ALIASPROD12" \
    --inputs '[{"content": {"document": "Customer review text..."}, "nodeName": "FlowInputNode", "nodeInputName": "customerFeedback"}]'

The InvokeFlow API returns an event stream containing the output events as nodes complete execution, allowing client applications to receive streaming responses or collect the final payload from the Flow Output node.

---

Common Exam Traps & High-Stakes Scenarios

• Trap: Selecting Bedrock Agents for Deterministic Workflows. If an exam question describes a scenario where business logic requires a fixed sequence of steps (e.g., "always check policy first, then categorize, then summarize"), selecting Bedrock Agents is incorrect. Bedrock Agents use non-deterministic ReAct reasoning loops where the LLM decides the execution path. A published Flow version fixes the reviewed graph definition, but foundation-model output and external dependencies remain probabilistic. Deterministic topology is not deterministic generation.
• Trap: Invoking the DRAFT Version in Production. AIP-C01 questions test production readiness. Invoking the DRAFT version or failing to use Flow Aliases introduces operational risk and violates AWS Well-Architected guidelines.
• Trap: Attempting Backward Loops in Prompt Flows. Prompt Flows does not support circular loops or while-conditions. If an exam scenario requires looping until a condition is met (e.g., re-prompting until code compiles), AWS Step Functions or Bedrock Agents must be used.
• Trap: Manual Array Processing without Iterator/Collector. When a scenario involves processing a list of items concurrently and summarizing the aggregate, look for the pairing of Iterator (fan-out) and Collector (fan-in) nodes.