{"slug": "aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud", "title": "AWS Bedrock with Spring AI: Moving from Local Models to the Cloud", "summary": "A developer's guide demonstrates how to integrate AWS Bedrock with Spring AI, moving from local model inference to managed cloud-based AI. The article explains the architectural shift, configuration steps, and the benefits of using Spring AI's abstractions for provider-agnostic development.", "body_md": "In the previous parts of this series, we explored how to build AI-powered applications with Spring AI and run models locally. Local inference is great for experimentation, development, privacy-focused use cases, and understanding how LLM applications work.\n\nBut production AI systems often need more.\n\nThey need access to powerful foundation models, managed infrastructure, scalability, reliability, and the ability to switch between models without managing GPU servers yourself.\n\nThis is where **AWS Bedrock** comes in.\n\nIn this article, we'll explore how to integrate **AWS Bedrock with Spring AI** and move from local AI inference to a managed cloud-based architecture.\n\nAWS Bedrock is a fully managed AWS service that provides access to foundation models from multiple AI providers through AWS infrastructure.\n\nInstead of downloading and running a model locally, your application sends requests to AWS Bedrock.\n\nThe architecture changes from this:\n\n```\nSpring Boot Application\n        ↓\n    Spring AI\n        ↓\nLocal Model Runtime\n(Ollama / Local LLM)\n```\n\nTo this:\n\n```\nSpring Boot Application\n        ↓\n    Spring AI\n        ↓\n AWS Bedrock API\n        ↓\n Foundation Model\n```\n\nYour application no longer needs to manage the underlying AI infrastructure.\n\nAWS handles the model hosting, scaling, availability, and infrastructure required to run inference.\n\nLocal models are incredibly useful, but they come with limitations.\n\nFor example:\n\nAWS Bedrock solves many of these infrastructure challenges.\n\nWith Bedrock, you can focus more on your application instead of managing model servers.\n\nYour architecture becomes more like this:\n\n```\nClient\n   ↓\nSpring Boot API\n   ↓\nSpring AI\n   ↓\nAWS Bedrock\n   ↓\nFoundation Model\n```\n\nThis makes it easier to build cloud-native AI applications.\n\nSpring AI provides abstractions for working with different AI providers.\n\nYour application interacts with high-level APIs such as `ChatClient`\n\ninstead of manually writing HTTP requests for every model provider.\n\nFor example:\n\n```\nString response = chatClient.prompt()\n        .user(\"Explain AWS Bedrock in simple terms\")\n        .call()\n        .content();\n```\n\nThe application code can remain relatively similar even when the underlying AI provider changes.\n\nFor example, you might start with:\n\n```\nSpring AI → Ollama → Local Model\n```\n\nAnd later move to:\n\n```\nSpring AI → AWS Bedrock → Cloud Model\n```\n\nThis abstraction is one of the major advantages of using Spring AI.\n\nYour business logic should ideally depend on AI capabilities rather than being tightly coupled to a specific provider.\n\nBefore your Spring Boot application can communicate with AWS Bedrock, you need access to AWS and the required permissions.\n\nAt a high level, the process looks like this:\n\n```\nAWS Account\n    ↓\nEnable Model Access\n    ↓\nConfigure IAM Permissions\n    ↓\nConfigure AWS Region\n    ↓\nSpring Boot Application\n    ↓\nSpring AI + AWS Bedrock\n```\n\nThe exact models available can vary depending on your AWS region and account configuration.\n\nYou also need appropriate AWS credentials and permissions for invoking models.\n\nFor local development, credentials can be provided through the AWS credential provider chain, environment variables, profiles, or other supported AWS authentication mechanisms.\n\nA typical environment configuration might look like this:\n\n```\nAWS_ACCESS_KEY_ID=your-access-key\nAWS_SECRET_ACCESS_KEY=your-secret-key\nAWS_REGION=your-region\n```\n\nHowever, in production, avoid hardcoding credentials in your application configuration.\n\nPrefer IAM roles and managed identity mechanisms whenever possible.\n\nSpring AI provides integrations for AWS Bedrock models.\n\nThe dependency you use depends on the specific Spring AI version and Bedrock model integration you want to work with.\n\nFor example, your Maven configuration may include a Spring AI AWS Bedrock starter:\n\n```\n<dependency>\n    <groupId>org.springframework.ai</groupId>\n    <artifactId>spring-ai-starter-model-bedrock-converse</artifactId>\n</dependency>\n```\n\nSpring AI's dependency management should also be configured using the appropriate BOM for your version.\n\nFor example:\n\n```\n<dependencyManagement>\n    <dependencies>\n        <dependency>\n            <groupId>org.springframework.ai</groupId>\n            <artifactId>spring-ai-bom</artifactId>\n            <version>YOUR_SPRING_AI_VERSION</version>\n            <type>pom</type>\n            <scope>import</scope>\n        </dependency>\n    </dependencies>\n</dependencyManagement>\n```\n\nThe important idea is that Spring Boot auto-configuration can create the required AI components once the correct dependencies and AWS configuration are available.\n\nYour application configuration tells Spring AI how to connect to AWS Bedrock.\n\nA simplified configuration might look something like this:\n\n```\nspring:\n  ai:\n    bedrock:\n      aws:\n        region: us-east-1\n```\n\nDepending on the Spring AI version and model integration, additional configuration may be required for the selected model, credentials, generation settings, or Bedrock Converse API.\n\nFor example, you may configure values such as:\n\nConceptually:\n\n```\nspring:\n  ai:\n    model:\n      chat: bedrock-converse\n\n    bedrock:\n      aws:\n        region: us-east-1\n```\n\nThe exact property names can vary between Spring AI releases, so always check the documentation for the version you are using.\n\nOnce the integration is configured, we can expose a simple API.\n\nFirst, inject `ChatClient.Builder`\n\n:\n\n```\n@RestController\n@RequestMapping(\"/api/chat\")\npublic class ChatController {\n\n    private final ChatClient chatClient;\n\n    public ChatController(ChatClient.Builder builder) {\n        this.chatClient = builder.build();\n    }\n\n    @GetMapping\n    public String chat(@RequestParam String message) {\n\n        return chatClient.prompt()\n                .user(message)\n                .call()\n                .content();\n    }\n}\n```\n\nNow a request such as:\n\n```\nGET /api/chat?message=Explain Spring AI\n```\n\nfollows this flow:\n\n```\nHTTP Request\n     ↓\nChatController\n     ↓\nChatClient\n     ↓\nSpring AI\n     ↓\nAWS Bedrock\n     ↓\nFoundation Model\n     ↓\nGenerated Response\n     ↓\nSpring Boot API\n```\n\nThe controller does not need to know the low-level details of the Bedrock API.\n\nSpring AI handles the integration layer.\n\nThe most important change is not just replacing one dependency with another.\n\nThe architecture itself changes.\n\n```\nUser\n ↓\nSpring Boot\n ↓\nSpring AI\n ↓\nOllama\n ↓\nLocal LLM\n```\n\nHere, you are responsible for the machine running the model.\n\nYou need to think about:\n\n```\nUser\n ↓\nLoad Balancer\n ↓\nSpring Boot Application\n ↓\nSpring AI\n ↓\nAWS Bedrock\n ↓\nFoundation Model\n```\n\nNow the model infrastructure is managed separately from your application.\n\nYour Spring Boot application becomes a consumer of AI infrastructure rather than the host of the model itself.\n\nThis separation can significantly simplify production architecture.\n\nOne major benefit of Bedrock is access to multiple foundation models.\n\nDifferent models can be better suited for different workloads.\n\nFor example:\n\n```\nChat Application\n        ↓\n   General Model\n\nDocument Analysis\n        ↓\n Long Context Model\n\nStructured Extraction\n        ↓\n Model with Strong\n Structured Output\n\nComplex Reasoning\n        ↓\n Higher Capability Model\n```\n\nThis means model selection becomes an architectural decision.\n\nYou should consider factors such as:\n\nThe best model is not always the largest or most expensive one.\n\nA production system may even route different requests to different models.\n\nOne common mistake is placing model-specific configuration throughout the application.\n\nInstead of this:\n\n```\nif (provider.equals(\"bedrock\")) {\n    // Bedrock logic\n}\n\nif (provider.equals(\"ollama\")) {\n    // Ollama logic\n}\n```\n\nTry to keep provider-specific infrastructure separate from your application logic.\n\nFor example:\n\n```\nApplication Layer\n       ↓\nSpring AI Abstraction\n       ↓\nProvider Configuration\n       ↓\nAWS Bedrock / Ollama / Other Models\n```\n\nThis makes it easier to change providers later.\n\nYour application should ideally focus on:\n\n```\nWhat should the AI do?\n```\n\nInstead of:\n\n```\nHow does this specific provider's HTTP API work?\n```\n\nWhen working with AWS Bedrock, authentication becomes part of your architecture.\n\nYour application needs permission to invoke models.\n\nFor production environments, the preferred approach is generally to use AWS IAM roles instead of embedding access keys inside application properties.\n\nFor example:\n\n```\nSpring Boot on AWS\n       ↓\nIAM Role\n       ↓\nTemporary Credentials\n       ↓\nAWS Bedrock\n```\n\nThis is safer than:\n\n```\napplication.yml\n       ↓\nHardcoded AWS Keys\n```\n\nYou should also think about:\n\nMoving AI to the cloud also means thinking carefully about what data leaves your application.\n\nWith local models, the main cost is often infrastructure.\n\nYou pay for:\n\n```\nGPU\nRAM\nCompute\nStorage\nServers\n```\n\nWith managed inference, cost is often related to model usage.\n\nConceptually:\n\n```\nApplication Request\n        ↓\nInput Tokens\n        +\nOutput Tokens\n        ↓\nInference Cost\n```\n\nThis means AI applications should treat token usage as an engineering concern.\n\nYou may need:\n\nFor example, sending unnecessary context to a model can increase both latency and cost.\n\nA good AI architecture should therefore optimize the entire request pipeline.\n\nProduction AI systems need more than application logs.\n\nYou may want to monitor:\n\n```\nRequest\n   ↓\nPrompt Size\n   ↓\nModel\n   ↓\nLatency\n   ↓\nToken Usage\n   ↓\nCost\n   ↓\nResponse\n```\n\nThis helps answer important questions:\n\nAs your AI application grows, observability becomes essential.\n\nYou don't necessarily need to abandon local models completely.\n\nA practical architecture could use different providers for different environments.\n\n```\nDevelopment\nSpring Boot\n     ↓\n   Ollama\n     ↓\n Local Model\nProduction\nSpring Boot\n     ↓\nSpring AI\n     ↓\nAWS Bedrock\n     ↓\nCloud Model\n```\n\nThis gives developers a fast and inexpensive local development workflow while allowing production to use managed cloud infrastructure.\n\nThe important part is keeping your application architecture flexible enough to support both.\n\nAWS Bedrock gives us access to powerful foundation models without managing the underlying AI infrastructure ourselves.\n\nBut moving AI into production introduces new challenges.\n\nHow do we manage conversation history?\n\nHow do we provide the model with our own documents?\n\nHow do we build applications that can retrieve relevant information before generating a response?\n\nIn **Part 7**, we'll take the next step and explore **RAG with Spring AI**.\n\nWe'll look at how documents move through the RAG pipeline:\n\n```\nDocuments\n    ↓\nChunking\n    ↓\nEmbeddings\n    ↓\nVector Database\n    ↓\nSimilarity Search\n    ↓\nRelevant Context\n    ↓\nLLM\n    ↓\nAnswer\n```\n\nThis is where AI applications start becoming truly connected to your own data.\n\n**Next up: Building RAG Applications with Spring AI.**", "url": "https://wpnews.pro/news/aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud", "canonical_source": "https://dev.to/ayshriv/aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud-54md", "published_at": "2026-08-27 06:55:35+00:00", "updated_at": "2026-08-27 07:18:23.287779+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["AWS Bedrock", "Spring AI", "AWS", "Ollama"], "alternates": {"html": "https://wpnews.pro/news/aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud", "markdown": "https://wpnews.pro/news/aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud.md", "text": "https://wpnews.pro/news/aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud.txt", "jsonld": "https://wpnews.pro/news/aws-bedrock-with-spring-ai-moving-from-local-models-to-the-cloud.jsonld"}}