MongoDB Atlas for Government on AWS Achieves FedRAMP® Moderate Authorization

Salman Baset and Imani Tate
February 8, 2023

MongoDB has achieved the formal FedRAMP® Moderate Authorized designation for MongoDB Atlas for Government (US), the most secure way for the US Government to deploy, run, and scale MongoDB in the cloud. Additionally, MongoDB has worked with an independent auditor to validate our ability to support customers subject to Criminal Justice Information Services (CJIS) requirements regarding how sensitive data is created, viewed, modified, transmitted, disseminated, stored, and destroyed.

MongoDB Atlas for Government

Atlas for Government is an independent, dedicated environment of MongoDB Atlas for the US public sector, as well as ISVs looking to build US public sector offerings. This developer data platform – an integrated set of data and application services that share a unified developer experience – supports a wide range of use cases including transactional workloads, time series data, search, and petabyte data storage.

Built on AWS and running in US AWS regions, Atlas for Government has been generally available since June 2021 and provides the simplest way to deploy, operate, and scale modern applications, all in a FedRAMP Moderate Authorized environment. Atlas for Government highlights include:

  • MongoDB clusters deployed in AWS GovCloud or AWS US East/West (US) regions, and leverage the full functionality of MongoDB's document database, Atlas Search, fully automated backup, time series, and more.

  • Guaranteed high availability with a ~99.995% uptime SLA which auto-scales up or down to accommodate fluctuations in data consumption, affording greater flexibility and cost control.

  • Unparalleled security, with all security features built-in at no additional cost. Also, Atlas for Government is operated by MongoDB employees who are US persons on US soil.

  • Support for both AWS GovCloud regions so customers can create multi-GovCloud region clusters and backups that stay within those regions and copy to both.

  • ISVs can use Atlas for Government to store US government data and rapidly build their own FedRAMP offerings. All encryption within Atlas for Government is FIPS validated.

These features make Atlas for Government uniquely positioned to support mission-critical applications across the US public sector.

How MongoDB powers key use cases across the public sector

MongoDB Atlas is already powering innovative applications in a number of sectors. And now, Atlas for Government is primed to power critical applications across public sector agencies and the ISVs that support them.

Healthcare

MongoDB is built to bring together data from disparate databases, systems, and data formats to create a single view of the patient. And with Atlas for Government’s dynamic schema, government agencies can enrich their view of patients with data from new sources, such as connected health devices. Both MongoDB and FHIR natively support the JSON format, the standard that supports rich data structures and objects prevalent in healthcare such as patient data, claims, policies, and treatment information.

Financial services

Agencies that participate in financial services activities must fully commit to digital transformation – liberating data, empowering developers, and embracing disruption — to keep up with the expectations of instantaneous transactions. Whether it's trading platforms and end-to-end digital loan origination, or AI/ML-driven fraud detection systems and financial 'super apps', Atlas for Government enables innovation and speed for government agencies that conduct payments and core banking applications.

Federal, state, and local government

National, regional, and local governments are facing pressing challenges with rising costs, changing regulations, and complex technological demands. The traditional systems currently in place are expensive and improperly equipped to handle modern needs for scale, cost efficiency, and flexibility. Atlas for Government opens doors for new initiatives like building smart cities, planning for traffic and construction updates, and improving the welfare of citizens.

Education

From groundbreaking data-based research to the administrative management of schools’ complex ecosystems, proper data management can transform how educational institutions operate. A modern data platform helps institutions navigate complex challenges like providing continuous learning, teaching with limited resources, and retaining students and staff. Atlas for Government offers an intuitive, secure, cost-effective solution for institutions dedicated to all stages of education.

How do I get started?

Customers can fill out the form on the MongoDB Atlas for Government page and a MongoDB specialist will get in touch with further details to set up. The specialist will help you set up Atlas for Government clusters (US) and you can either launch a new workload, migrate your existing Atlas workload to Atlas for Government, or re-platform your existing workloads by engaging with our professional services. Please also refer to the technical documentation for Atlas for Government for more details, or learn more on MongoDB University.

← Previous

Turning Data Points Into Actionable Insights: Meet May Hoque

Imagine the interesting insights you could glean from combining multiple data sources with one tool that helps you easily analyze data over time. May Hoque is a senior software engineer on MongoDB’s Atlas Data Federation team where he helps create a distributed, federated query engine that can query across data stored in multiple sources. Keep reading to find out more about his experience joining MongoDB as an intern and new grad, then continuing to grow his career here over the last four and a half years. Jackie Denner: Thanks for sharing more about your experience today, May! To start, will you give an overview on your software engineering background and how you started working with MongoDB? May Hoque: I began exploring computer science in a high school class. The class was rudimentary but I had fun learning how to build programs. I chose computer science as my university major because it felt like a career I could grow with that both piqued my interest and offered long-term stability. I am currently a senior software engineer on MongoDB’s Atlas Data Federation team. I first joined MongoDB in 2017 as an intern, then returned after graduation to participate in the New Grad Program in 2018 which gave me an opportunity to rotate working between three different teams at MongoDB over our first six months. I originally joined the BI connector team, but then switched to the Atlas Data Federation team. JD: Tell me more about the Atlas Data Federation product. MH: Atlas Data Federation is a distributed, federated query engine at its core. This core enables users to query multiple data sources with a single query, from a single interface. Other MongoDB products, including Atlas Online Archive and Atlas Data Lake , use this core as a building block for their own functionality. The Atlas Data Lake product, for example, orders and organizes data to optimize for super fast queries even as the user's data sources grow in volume. The ability to perform complex queries, even across multiple data sources unlocks valuable benefits for a variety of use cases, for example maintaining the ability to easily query less frequently used data even after archiving it from pre-existing database clusters to less expensive locations. JD: What makes Atlas Data Federation unique? MH: We’re more than just a search function — we can also store your data and organize it in a way that makes it really fast to actually answer those questions. Its integration with Atlas and the larger MongoDB ecosystem widens the scope of the value users can get from their databases. It’s convenient and operationally simple to have all of your solutions to different challenges in the same place. MongoDB Atlas Data Lake allows developers to easily store and analyze large amounts of data in a cost-effective and scalable manner without having to worry about the underlying infrastructure. JD: Talk me through some example use cases your team supports. MH: The real value in large data sets lies in understanding the trends and relationships between the data points. There are endless possibilities of how organizations can use Atlas Data Federation to draw insights to motivate strategic business decisions, from answering questions about specific events, to aggregating insights across a group of data points. Atlas Data Lake stores and organizes your data in a way that makes it really fast to answer questions related to your collection of data. Teams across an organization can benefit from more insight into data learnings. A marketing team may want to know what percentage of their users have spent more than a specific amount on a single item, including supporting data like what the item was and when they purchased it. An investor may want to know how much profit an organization made over a specific time period. A product team may want to look at historical sales data from past product launches. Users can answer all of these questions and more with a query on Atlas Data Federation. JD: What projects are you currently working on? MH: I am contributing to a bigger MongoDB initiative to add more sources of data. Adding this support to Atlas Data Federation and Data Lake will make our service available to new clients who want to use the product, but currently can’t. I’m also working on a high level systems design challenge to rearchitect our systems to scale and improve our service for our customers. JD: Let’s talk about what it’s like to work at MongoDB. What makes the team and product exciting to work on? MH: The Atlas Data Federation team is primarily focused on problems relating to complex distributed systems and database engineering . These challenges aren’t often easy to work on, but the careful and rigorous thinking needed to solve them is exciting and rewarding. Plus, the solution to the data lake problem is in demand, and the projects we work on are relevant to the industry. JD: What is the overall engineering culture like at MongoDB? What opportunities have inspired you to grow here? MH: My experience on the team has contributed to my growth as an engineer. I’ve noticed a strong culture of learning, mentorship and diversity both on the Atlas Data Federation team and the company at large. I appreciate that our team has a wide spectrum of experience levels, from new grads to engineers with decades of experience. The team is collaborative and takes pride in supporting each other. Whether I work on a project independently or with a group of engineers, I’m never working solo. I always have the support of the team and people to bounce ideas off of throughout a project, which creates opportunity for growth. JD: Why should someone join the Atlas Data Federation team? MH: If you're someone who really likes technical challenges or you just want to solve really cool problems, we have no shortage of them to work on. If you’re focused on growth, we have opportunities for all levels of experience. It is possible to grow from an intern to a manager on our team because of the mentorship and breadth of projects available to work on, which I’ve seen happen for some of my colleagues. Our team environment is built on empathy and collaboration. JD: What stands out to you about your overall experience working at MongoDB compared to your past experiences? MH: After a few years on the team, I'm still consistently growing my skill set and working on interesting, fun projects – two primary reasons I continue to work at MongoDB. The problems the Atlas Data Federation team works on provide me useful experience that I can apply to future projects and challenges. If you’re looking to collaborate with forward-thinking teams and interesting use cases, MongoDB is one of the best tech companies to work for. Interested in transforming your career at MongoDB? View open roles on our teams across the globe.

February 7, 2023
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024