To decrease the learning curve for Mantel’s Managed Services engineers around client-specific information and configuration details providing higher quality and faster outcomes for our customers.
The problem
One of the core beliefs of the Mantel Managed Services (MS) team is that they don’t prescribe how a particular customer’s environment must look, what services they must use or what applications they can/can’t run. This allows the clients to operate in the manner best suited to them, but it does mean that the Mantel engineers need to contend with a lot of variability between clients. To date, this has limited how much cross-client work a single Managed Services engineer has been able to do (given the sheer amount of knowledge one must maintain to be efficient when triaging tickets/issues). This means that the headcount within the Managed Services team needs to scale linearly with the client count. In the current economic climate, Mantel would like to explore removing (or at least reducing) this constraint and allowing a single engineer to service additional clients without reducing customer service quality.
Business requirements
The core requirements of the solution were:
- Decrease the amount of time it takes a managed services engineer to the customer-specific information they require to address a ticket
- Allow a managed services engineer to context switch between clients (and there for environments and tools) by providing useful technical options (such as code examples, boilerplate code etc.)
- Keep all client-specific information private and secure in line with existing Managed Services and privacy agreements
- Perform these actions quicker and cheaper than a comparable uplift in headcount
- Integrate with the existing Mantel Corporate IT policies and technology landscape (including integrating with existing SSO solutions). From a technical perspective, it would be good to surface the above in a similar manner and interface with tools currently in use by the managed services team (such as via a terminal or web browser). Longer-term integration with existing systems, such as the ticket management system, would be desirable but not required at this stage.
The solution
Given the relatively straightforward nature of the proposed business problem, it was decided that Amazon Q business would be a suitable solution to the problem given:
- It can scrape existing data sources used by the team to build out a suitable knowledge base
- Provides a user-friendly interface for the team to use in the form of a simple web page
- Integrates with AWS Identity Centre, which is currently already in use across the Mantel Group IT Landscape, ensuring SSO
Architecture Diagram
The overall solution diagram is shown below:
The solution is made up of the below core components:
- A new AWS Account created within the Existing Mantel AWS organisations to ensure it aligns with existing security controls.
- Within the account, an “Amazon Q Business” instance is provisioned along with the “Managed” Amazon Kendra backend (while the Kendra instance is technically hidden as a part of this solution, it’s highlighted in the diagram due to the privacy and security implications of it hosting data)
- An AWS Lambda function and S3 bucket are provisioned to handle data syncing from our Google Drive instance into Q Business. This addresses a Mantel security control that prevents us from using the native Google Drive sync built into Q Business.
- Secrets hosted in AWS Secrets Manager for the credentials to access both Confluence and Google Drive
The main power of the solution comes from data scrapping and syncing, which ultimately makes the Q a helpful instance. Currently, the solution is pulling data from two locations:
- The Mantel Confluence site contains most of the client-specific high-level information. The sync is authenticated against an Okta account in accordance with existing Mantel Security Policies.
- Google Drive. Google Drive is where we store most of our client artefacts and more detailed information on specific configurations and client solution components. While Amazon Q Business does support scrapping directly from Google Drive, Mantel’s existing IT security controls don’t allow this, so a two-step solution needed to be put in place where a Lambda function does the scrapping into an S3 bucket and then Amazon Q Business pulls the information from there. While this does break the sourcing that Amazon Q performs… It’s currently considered an acceptable workaround while assessments are done on what changes might be able to be made to support the standard configuration.
Network patterns
The Network design for this solution is pretty simple, mainly due to the Cloud-centric nature of the Mantel Group corporate IT landscape. Each of the involved systems (Confluence and Google Drive) are publicly hosted SaaS products, meaning that they can only be accessed over the public internet (there are no Private backhauls or cross-connects provisioned as a part of the Mantel Group system). The same goes for Amazon Q Business, as a managed service it’s publicly available service which means there is no need for a VPC or other networking components.
The Lambda Function could have been hosted within a VPC. Still, given that it talks to two publicly available systems (Google Drive and S3), adding this additional layer of complexity was not beneficial.
Data flow
From a Networking perspective, there are three data flows that we need to be mindful of:
- Google Drive is accessed (over the public internet as it’s a public SaaS service) via a Lambda function hosted in the “AWS-GenAI-POC” account (NOT hosted within a VPC), and data copied into an S3 bucket within the same AWS Account (This bucket does NOT have public access enabled) which in turn is then ingested into Amazon Q business
- Confluence is also accessed via the public Internet (as it’s a cloud-hosted instance of Confluence), but it’s accessed via Amazon Q Business directly via its native integration.
- Authenticated Managed Services Engineers can access the Amazon Q Business URL across the public internet. As Amazon Q Business is a managed service, it’s also not hosted in a VPC.
Security Monitoring and Q Business Application Access
Access to the Actual end user interface of the Q Business application (those who can actually interact and use the application) is controlled via an IAM Group which in turn is controlled via Mantel Group’s corporate Identity Provider “Okta”.
How AWS was used as part of the solution
As outlined in the previous sections, the solution consists of very few AWS components, mainly because Amazon Q Business is an ” all-in-one” solution for this type of business requirement.
While typically, we’d be looking to implement things like VPCs, Transit Gateway and such to control access to the various solution components… this solution doesn’t require any of that. The only AWS resources that have been deployed as a part of the solution are:
- A new AWS Account (to keep aligned with the best practice of minimising potential blast radiuses across workloads)
- An Amazon Q Business Implementation in the “us-east-1” region.
- A lambda function and S3 bucket will facilitate the required Google Drive workaround.
- AWS Secrets Manager Secrets to host the credentials required to authenticate with Google Drive and Confluence
- CloudWatch Dashboard for monitoring
Outcomes of Project & Success Metrics
The application is in production and actively being used by members of the Managed Services team and have seen the following improvements:
- Improved context switching between clients (and there for environments and tools) by providing useful technical options (such as code examples, boilerplate code, etc.)
- All client-specific information is kept private and secure in line with existing Managed Services and privacy agreements
- Perform these actions quicker and cheaper than a comparable uplift in headcount
- Integrate with the existing Mantel Group Corporate IT policies and technology landscape (including integrating with existing SSO solutions)
Lessons Learned
So far, we’ve learnt several things when it comes to applying Generative AI technology to business solutions, including:
- The criticality of high-quality data on which to train/populate the models. Internal documentation isn’t always clear, concise, and high-quality, which drastically impacts the quality of the products’ responses.
- The quality of the data is also affected by the metadata that is passed along with it. Q Business appears to need additional context around data sources to help it better select the right source of information when answering questions.
- While having Q Business as a single “all-in-one” solution has been great from an implementation and ongoing management perspective, its lack of flexibility does make its integrations unsuitable for a number of use cases, and its lack of expandability (integrating with non-supported data sources) limited the use cases to which it’s a suitable solution. Custom Plugins do partially solve this problem, but the way plugins work is quite limited and poses additional security hurdles that need to be addressed.
