View a markdown version of this page

Detailed integration architecture options - AWS Prescriptive Guidance
LMS plugin integrationLearning Tools Interoperability (LTI)Standalone application with API integrationEvent-driven integrationETL integration

Detailed integration architecture options

This section provides architectural guidelines, implementation details, and best practices for each key integration option. Each pattern includes components, workflow, security considerations, and practical implementation guidance to help you design effective AWS-LMS integrations.

LMS plugin integration

LMS Plugin Integration directly extends the LMS platform's functionality through its native extension framework, providing a seamless experience for users while leveraging AWS services for enhanced capabilities.

Architecture and Components

The LMS plugin integration architecture connects the Learning Management System with AWS services through a secure, scalable interface:

  1. LMS Environment: Hosts the LMS platform and the custom plugin code within the LMS application server. This is where users interact with the plugin interface. It contains four interconnected components:

    • LMS UI with Plugin UI: The interface users interact with directly

    • Custom LMS Plugin: The extension code that adds AWS-powered capabilities

    • LMS Core Functionality: Native LMS features that the plugin interacts with

    • LMS Content: Educational materials and data accessed by the plugin

  2. Amazon API Gateway/ AWS AppSync: Serves as the secure bridge between the LMS and AWS services by:

    • Receiving requests from the LMS plugin

    • Routing authenticated requests to appropriate backend services

    • Returning responses to the LMS environment

  3. Authentication Layer: Secures API access through either:

    • AWS Lambda Authorizer: Provides custom authorization logic for validating requests based on LMS context

    • AWS Identity and Access Management: A role associated with an EC2 instance or IAM access keys can be used to sign requests using SigV4. IAM access keys are not recommended as they are long-term credentials.

  4. AWS services: Backend services that provide the actual functionality, such as Amazon Bedrock for generative AI capabilities, Amazon S3 for content storage, and other AWS services as needed for specific use cases

LMS plugin connects to AWS services through API Gateway and an authentication layer.

Figure 1: LMS Plugin Integration Pattern

User Flow

When a user interacts with the plugin in the LMS:

  1. The plugin captures the user's input and relevant LMS context

  2. The plugin sends an authenticated request to API Gateway

  3. API Gateway authorizes the request using either a Lambda Authorizer or IAM

  4. Upon successful authentication, the request is forwarded to appropriate AWS services

  5. AWS services process the request and return results

  6. Results flow back through API Gateway to the plugin

  7. The plugin renders the results within the LMS interface

This architecture ensures secure communication between the LMS and AWS while maintaining a seamless user experience within the familiar LMS environment.

Implementation Technologies

The plugin implementation depends on the LMS platform's technology stack:

  • Moodle: PHP with specific plugin structure requirements

  • Blackboard: Java/Spring and JavaScript adhering to Blackboard's Building Block API

  • Canvas: Does not support native plugins but recommends the use of LTI or Canvas APIs for integration

When developing plugins for any LMS platform, developers must:

  1. Understand the specific LMS's plugin architecture and guidelines

  2. Follow security best practices for the platform

  3. Implement appropriate authentication and authorization mechanisms

  4. Adhere to the platform's UI/UX guidelines

  5. Consider performance implications and scalability

  6. Maintain compatibility with LMS version updates

Authentication and Security

When integrating AWSservices from an LMS plugin, the recommended approach is to use a proxy API integration: The plugin calls a custom API endpoint (for example, API Gateway) that acts as a proxy to the AWS services. Authentication and authorization are handled at the API layer. AWS service logic is isolated from the LMS environment. For this proxy API approach:

  • API Authorization: IAM roles, LMS token, IAM Access Key (if other options are not viable)

  • Plugin Implementation: The plugin makes HTTPS requests to your secured API endpoints

  • Credential Protection: If using long term credentials such as IAM Access Key these will need to appropriately stored and protected

This architecture creates a clear security boundary between the LMS and AWS environments. The LMS plugin only needs to know the API Gateway endpoint URL and appropriate authentication method for the API (such as IAM Role or OAuth token). Regardless of the specific integration approach, LMS plugin development requires careful consideration of security, performance, and maintainability. Proper authentication, authorization, and data protection mechanisms must be implemented to ensure the integrity of the overall system.

Advantages

  • Tight UI/UX integration: The plugin becomes part of the native LMS interface, providing a seamless experience for users who don't want to leave the LMS environment.

  • Direct Access to the LMS Context: Plugins have access to course context, user roles, and other LMS-specific data that external applications would need to request.

  • Leverage Existing Authentication: Can utilize the LMS's authentication and authorization mechanisms, simplifying security implementation.

Limitations

  • Requires plugin development expertise for each LMS

  • Must maintain compatibility with LMS version updates

  • Subject to LMS plugin architecture constraints

  • Requires separate implementations for each LMS platform

Learning Tools Interoperability (LTI)

Learning Tools Interoperability (LTI) is an education technology standard developed and maintained by 1EdTech (formerly IMS Global Learning Consortium). LTI enables third-party tools to integrate seamlessly with LMS platforms by providing a standardized way for external applications to authenticate with an LMS and exchange data. This standard ensures secure, efficient, and consistent interoperability between learning platforms and external educational tools. It allows any LTI compliant tool to plug into any compliant LMS.

Common LTI implementations include digital textbook launches, grade assessment tools, and interactive learning modules. These integrations work well for straightforward use cases where the need for data exchange is minimal and the interaction model is simple. Grade passback scenarios, such as quiz scores from external platforms or assignment completion status, also function adequately within LTI's constraints.

However, the integration of Generative AI tools presents even more demanding requirements. These systems need training data from student interactions, course content and materials, assessment responses and feedback, learning patterns and preferences, and cross-course correlations. They require real-time data processing, continuous learning and adaptation, deep content understanding, and the ability to handle complex interaction patterns – all of which exceed LTI's capabilities.

For modern educational technology needs, LTI often serves best as one component of a larger integration strategy. Many successful implementations use LTI for its strengths (secure launches, basic data passing, grade return) while supplementing it with additional integration methods for more complex requirements.

Architecture and Components

The LTI integration architecture consists of:

  1. LMS Environment: Any LTI-compliant LMS ( for example Moodle, Canvas, Blackboard)

    • LMS UI with iFrame Container: The standard LMS interface where the LTI tool will appear embedded

    • LTI Launch Interface: Handles the LTI launch process and OAuth-based security protocol

    • LMS Core Functionality: Native features of the LMS that the LTI tool might interact with

    • LMS Content: Course materials and data that might be accessed by the LTI tool

  2. LTI Tool Application: A web application hosted on AWS that implements the LTI standard

    • LTI Tool Frontend: Web application hosted on AWS that renders inside the iFrame container

    • LTI Tool Backend: Server-side component that processes requests and business logic

  3. AWS Services Layer: Backend AWS services providing enhanced functionality such as Amazon Bedrock

The LTI standard enables secure communication between the LMS and the AWS-hosted tool while maintaining separation between the systems. This provides flexibility for the tool's development while ensuring secure data exchange with the LMS environment.

LTI tool frontend renders in an iframe, with backend connecting to AWS services.

Figure 2: LTI Integration Pattern

User Flow

When a user interacts with the LTI plugin in the LMS:

  1. The LMS and the LTI tool perform a handshake process that enables the exchange of information.

  2. Upon success, the LTI tool is displayed inside an iFrame on the LMS.

  3. The tool makes authenticated calls to an AWS backend.

  4. The tool returns the requested information.

  5. Alternatively, the tool can also pass information back to the LMS.

Implementation Technologies

Authentication and Security

LTI implements a secure authentication mechanism based on OAuth 2.0:

  1. User clicks an LTI tool link within the LMS

  2. LMS generates a signed JSON Web Token (JWT) containing user context and launch parameters

  3. User is redirected to the LTI tool with the JWT

  4. LTI tool validates the JWT signature using the LMS's public key

  5. Tool creates a session and displays the appropriate content

  6. AWS services are accessed by the LTI application's backend using IAM roles

This approach keeps AWS credentials entirely separate from the LMS environment, improving security posture.

Advantages

  • Cross-platform compatibility across LMS environments (Moodle, Canvas, Blackboard, etc.)

  • Independent development and release cycles

  • Standardised authentication and data exchange

  • Portable across institutions and departments

Limitations

  • Functions within iframe/separate context, limiting some UX options

  • Requires implementing and maintaining LTI standards compliance

  • More complex authentication flow than direct plugin integration

  • Might have limited access to certain LMS features

Standalone application with API integration

This pattern involves developing a standalone application that interfaces with the LMS through its APIs. While operating independently, the application can both read from and write data to the LMS as needed. This integration approach is particularly valuable when LMS data needs to be accessed by external systems. For instance, when creating analytics solutions for student engagement or developing dashboards for non-LMS users (such as registrar office staff or deans), a separate application might be more appropriate than trying to extend the LMS itself. This allows for specialized tools tailored to these specific user groups' needs.

Architecture and Components

  1. Standalone Web/Mobile Application:

    • LMS API: The interface exposed by the LMS that allows external applications to read and write data

    • LMS Core Functionality: Native features and functions of the LMS

    • LMS Content: Course Materials, user, data, and other educational content stored in the LMS

  2. AWS Cloud:

    • LMS API Client: Component that handles pull/push API calls to communicate with the LMS API

    • Application Frontend: User interface layer that users interact with directly

    • Application Backend: Server-side components that processes business logic

    • AWS Services: Backend services that provide specialized functionality such as Amazon S3 or Amazon Bedrock.

Standalone application uses an API client to bridge LMS and AWS services.

Figure 3: Standalone API Integration Pattern

User Flow

  1. User authenticates with the standalone application

  2. Application authenticates with LMS using OAuth 2.0 or API keys

  3. Application retrieves or updates necessary data from LMS API

  4. User interacts with application features that leverage the retrieved data and AWS services

  5. AWS-processed results are displayed to user and optionally saved back to LMS

Implementation Technologies

  • Application Hosting: Amplify, Elastic Beanstalk, or container services

  • Authentication: OAuth2, LMS Access Key

  • LMS Communication: Software Development Kits (SDKs) or REST client libraries for the specific LMS

Authentication and Security

When authenticated against the LMS API most platform use either OAuth 2.0 or other tokens to authenticate the request from the application.

Advantages

  • Complete flexibility in application design and user experience

  • Independent deployment and scaling from the LMS

  • Full control over the technology stack

Limitations

  • Limited by available LMS API capabilities

  • Might require ongoing updates as LMS APIs evolve

  • Additional complexity in maintaining data consistency

  • Many requests to the LMS API might have a negative impact on LMS system performance so rate limiting should be implemented

  • Tight coupling between systems, patterns such as messaging, API Gateways or facades can limit this

Event-driven integration

Event-driven integration leverages the LMS' event system to trigger actions in AWS services based on user activities or system changes within the LMS.

Architecture and Components

  1. LMS Environment: Hosts the LMS platform and the custom plugin code within the LMS application servers. This is where users interact with the LMS to generate events. It contains three interconnected components:

    • Custom LMS Plugin: Extension code that is invoked for each event raised and passes the event to Amazon EventBridge or publishes to the stream

    • LMS Core Functionality: Native LMS features that the user interacts with creating LMS Events

    • LMS Content: Educational materials and data created and accessed by the users

  2. EventBridge / Streaming: Receives the events from the LMS Plugin and either triggers rules to invoke downstream services when the event matches a defined pattern, or processes records in the stream to invoke appropriate AWS services. Streaming services can be Amazon Kinesis Data Streamsor Amazon Managed Streaming for Apache Kafka.

  3. AWS Services: Backend services that provide the actual functionality, such as Lambda for executing custom code.

LMS plugin forwards events to Amazon EventBridge or Kinesis for AWS processing.

Figure 4: Event-Driven Integration Pattern

System Flow

When an event occurs in the LMS, the following process takes place:

  1. LMS captures the event in its Events subsystem

  2. Custom LMS Plugin observes each created event

  3. The plugin sends an authenticated request to EventBridge or streaming service with the event payload

  4. AWS API validates the request using IAM

  5. Upon successful authentication, the request is added to an EventBridge event bus or stream

  6. A rule receives incoming events and routes them to appropriate AWS services based on matching event patterns or records are processed off the stream and processed by the consumer.

This architecture ensures secure communication between the LMS and AWS services allowing LMS platform capabilities to be extended with AWS services.

Implementation Technologies

The LMS plugin implementation depends on the platform's technology stack, for example:

  • Moodle: The Moodle Events API can be used with a local plugin to send the events to EventBridge.

  • Canvas: Canvas Live Events can be published to Amazon SQS so AWS services can pull the messages or can be invoked via a Lambda function. Using a Lambda function to write the events on the Amazon SQS queue to EventBridgemight still be useful to decouple the subscribers.

  • Blackboard Learn: Learn Activity Streams are an implementation of the Caliper Specification which enables the collection of learning data in a standardized way. The events are sent to a Caliper Event Store which can be used to invoke AWS services.

The plugin implementation must adhere to the LMS's plugin development guidelines and APIs. This often involves:

  • Implementing specific plugin lifecycle methods and configuration pages

  • Accessing LMS data through provided APIs, data access patterns and security practices.

Authentication and Security

When integrating with AWS, three primary authentication methods exist:

  1. IAM Role (Preferred Method):

    • Attach a role to EC2 instances or container if the LMS is running on AWS

    • Provides temporary, secure credentials for AWS API calls

    • Eliminates need to store long-term access keys in configuration

  2. IAM Roles Anywhere (Recommended for Non-AWS Hosted Moodle):

    • Uses X.509 certificates to obtain temporary AWS credentials for workloads running outside AWS

    • Provides temporary credentials without long-lived access keys

    • Requires attaching an appropriate IAM policy to your IAM Roles Anywhere role

    • See IAM Roles Anywherefor setup instructions

  3. AWS Access Key (Alternative Method):

    • Use when an IAM Role cannot be assumed

    • Requires careful security management

    • Long-term credentials that must be manually rotated

AWS SDK support these methods.

Advantages

  • Access to broad range of AWS capabilities

  • Enhanced scalability

  • System decoupling

  • Near real-time updates

  • Improved reliability as events / stream records can be persisted and replayed

  • Independent development and release cycles

  • Flexibility in development language

Limitations

  • Unable to integrate with LMS user interface

  • Callbacks to the LMS from downstream services might cause unintended system load

ETL integration

ETL (Extract, Transform, Load) integration focuses on batch processing of LMS data for analytics, reporting, and other data-intensive use cases.

Architecture and Components

  1. Learning Management System:

    • LMS API: The interface exposed by the LMS that provides access to educational data

    • LMS Core Functionality: Native features and functions of the LMS

    • LMS Content: Course materials, user data, and other educational content stored in the LMS

  2. AWS Cloud:

    • Scheduled Extraction: Time-based trigger that initiates the ETL process

    • AWS Glue ETL Jobs: Service that extracts data from the LMS API, transforms it, and loads it into storage

    • Amazon S3 (data lake): Storage repository for processed educational data

    • AWS Analytics Services: Tools for analyzing and visualizing the processed data

    • AWS Lambda: Function that can process data or write results back to the LMS (indicated by dotted lines)

Scheduled ETL extracts LMS data via AWS Glue into S3 for analytics services.

Figure 5: ETL Pipeline Integration Pattern

System Flow Example

  1. Scheduled Extraction triggers AWS Glue ETL Jobs at predetermined intervals

  2. AWS Glue ETL Jobs connect to the LMS API to extract data

  3. Extracted data is transformed and loaded into Amazon S3 (data lake)

  4. AWS Analytics Services access the data lake to perform analysis

  5. Optionally, insights and processed data can be fed back to the LMS via AWS Lambda functions (shown by dotted lines)

Implementation Technologies

  • ETL Processing: AWS Glue for serverless data integration

  • Data Storage: Amazon S3 for the data lake architecture

  • Analytics: Amazon Athena for SQL queries, Amazon Quick Sight for visualization

  • Scheduling: Amazon EventBridge or AWS Glue triggers for triggering extraction on schedule

  • Optional Processing: AWS Lambda for additional transformations or writing data back to LMS

Authentication and Security

When authenticated against the LMS API most platform use either OAuth 2.0 or other tokens to authenticate the request from the application.

Advantages

  • Allows LMS data to be processed and visualized using modern analytics and AI tools

  • Design for scalable extraction of potentially large datasets

Limitations

  • Full extractions might lead to excessive system load, investigate change data capture mechanisms or consider a separate LMS instance for extraction

  • Extraction during core hours might impact user performance

  • Additional data governance required to address privacy and compliance requirements outside of the LMS

The following AWS Workshops are useful for exploring ETL based integration in more detail: