Set up your cloud.Let your team ship.

1. Prepare the building blocks.

   Document storage, a vector index, model configuration, and guardrails can be provisioned independently.

2. Connect the knowledge base.

   Bedrock connects the document source and vector store. A separate ingestion step makes your documents searchable.

3. Bring the configuration together.

   The application needs the knowledge base, model, and guardrail configuration, plus permission to use them.

4. Deploy your assistant API.

   Lambda runs your application code, which retrieves context and calls the model with the configured response policies.

5. Publish the HTTPS endpoint.

   API Gateway connects to the Lambda function. Configure authorization for the clients that should reach it.

6. One view of the connected stack.

   Inspect the resources and their prerequisites together, from document storage to the application endpoint.

Illustrative architecture · deployment time compressed. Application code, data, and access configuration are supplied separately. The overview groups supporting resources; blue dots show deployment dependencies, not application traffic. Document ingestion is a separate step. The application invokes retrieval, the model, and its configured guardrail.

1. Start with your cloud network.

   The VPC and subnet provide the network foundation for your cluster.

2. Create the Kubernetes foundation.

   GKE and general-purpose nodes provide the home for the application and its supporting services.

3. Add capacity and vector search.

   Provision a GPU pool for the model. Qdrant runs separately on general-purpose capacity.

4. Deploy the model server.

   Your vLLM workload uses the GPU pool, with the model, storage, and readiness configuration you provide.

5. Connect your AI application.

   Deploy your container with the model and vector-search endpoints. Your code owns retrieval and inference behavior.

6. Publish the application route.

   A gateway, TLS configuration, and route expose your application while the model and vector store stay internal.

Illustrative architecture · deployment time compressed. Application code, data, and access configuration are supplied separately. The overview groups supporting resources; blue dots show deployment dependencies, not application traffic. vLLM is a custom Kubernetes workload, not a dedicated catalog component. Model access, weights, GPU quota, and application configuration are required.

1. Prepare the application foundation.

   Create the container environment and managed PostgreSQL database. Each has its own lifecycle.

2. Prepare messaging and access.

   Service Bus holds background work. Key Vault and managed identity support the application’s access configuration.

3. Connect the required configuration.

   Supply database access, queue settings, secrets, and scoped permissions before deploying the workloads.

4. Deploy the orders API.

   Your Container App serves requests and records orders using your application code and database schema.

5. Deploy the background jobs.

   Configure a Service Bus event trigger so Container Apps Jobs can run your worker code when work arrives.

6. See the entire application stack.

   Inspect the managed environment, database, messaging, and workloads together without managing a Kubernetes cluster.

Illustrative architecture · deployment time compressed. Application code, data, and access configuration are supplied separately. The overview groups supporting resources; blue dots show deployment dependencies, not application traffic.

1. Give the application its data stores.

   R2 holds files, D1 holds application records, and Workers KV holds configuration.

2. Deploy the background consumer.

   Bind the worker to the stores it needs. Your code handles metadata updates or other small asynchronous tasks.

3. Connect the queue to its consumer.

   The queue references the deployed background worker, so it knows which consumer should receive work.

4. Pass the bindings to the API.

   The producer needs its queue and data-store bindings before it can accept requests.

5. Publish the edge application.

   Deploy the API Worker with its bindings and configured domain. Your application code handles requests and enqueues work.

6. Follow the dependencies, end to end.

   The deployment starts with storage and the consumer. At runtime, requests flow from the API through the queue to the worker.

Illustrative architecture · deployment time compressed. Application code, data, and access configuration are supplied separately. The overview groups supporting resources; blue dots show deployment dependencies, not application traffic. Worker code and database migrations are supplied separately. KV holds configuration; D1 holds application records.

1. Create the private network.

   A VPC gives the application servers and database a shared private network.

2. Prepare application data and assets.

   Managed PostgreSQL stores customer data. Spaces holds the public assets your application publishes.

3. Start the application servers.

   The Droplet pool runs your image and bootstrap configuration. Keep persistent data outside the replaceable servers.

4. Publish the HTTPS endpoint.

   A load balancer terminates TLS and follows tagged servers as the pool scales. Configure health checks and network access.

5. Deliver public assets globally.

   The CDN serves public application assets from Spaces. Your application owns uploading and referencing those assets.

6. See the connected SaaS foundation.

   Inspect the network, servers, database, and delivery endpoints together. No Kubernetes cluster is required.

Illustrative architecture · deployment time compressed. Application code, data, and access configuration are supplied separately. The overview groups supporting resources; blue dots show deployment dependencies, not application traffic. Supply the application image and server bootstrap configuration. Load balancer membership follows server tags. The CDN serves public application assets, not private customer files.