How the Changineers Platform is built: multi-tenant AWS-native SaaS with no persistent compute under Changineers management.
The Changineers Platform is a multi-tenant SaaS built on AWS. It follows the AWS Well-Architected Framework and the Serverless Application Lens, using AWS managed services wherever possible so that operating-system and infrastructure patching is handled by AWS. There is no persistent compute under Changineers management.
The platform runs in AWS ap-southeast-2 (Sydney) across multiple
Availability Zones. Customer content, CMS data, recordings, and other
durable assets are replicated to ap-southeast-4 (Melbourne) for
disaster recovery.
Multi-tenancy
Section titled “Multi-tenancy”The platform is multi-tenant. Each tenant is served on its own subdomain and is isolated across three layers:
- A dedicated AWS Cognito user pool per tenant.
- Tenant-scoped API routing at the edge, so each tenant has its own origin path through CloudFront and API Gateway.
- Tenant-column isolation in the relational database, following the “pool” model described in AWS’s SaaS Tenant Isolation Strategies whitepaper. Postgres Row-Level Security enforces the tenant boundary in the database itself: queries cannot reach another tenant’s rows, even if application code asks. The current tenant is set per transaction; without it, the policy matches no rows.
Authentication
Section titled “Authentication”User authentication is handled by AWS Cognito. Cognito stores and encrypts credentials at rest and enforces password policies.
Cognito’s Advanced Security Mode is enabled on every tenant user pool. This provides:
- Detection of credentials seen in published credential leaks, with a forced password reset when one is matched.
- Adaptive authentication, which risk-scores sign-in attempts based on device and location and can challenge high-risk attempts for additional verification.
Users can enrol multi-factor authentication with SMS or TOTP via an authenticator app. Tenants can require MFA for their users.
Tenants can federate with external identity providers via SAML 2.0 or OpenID Connect.
Application sessions follow Cognito’s token lifetimes. Access and ID tokens expire after 1 hour; refresh tokens after 30 days. After refresh-token expiry the user re-authenticates.
Authentication events are logged to Cognito’s event log. Account management actions are additionally captured in CloudTrail.
Data stores
Section titled “Data stores”- Amazon Aurora PostgreSQL is the primary data store for user-generated content.
- Amazon DynamoDB holds transient data and data outside the primary platform flows: notifications, LTI nonces, and similar.
- Amazon S3 stores content and media, served through Amazon CloudFront.
All are encrypted at rest using AWS KMS. See Configuration baselines for the full baseline.
Environments
Section titled “Environments”The platform has two long-lived environments:
- Production, serving live user traffic in the Production AWS account.
- Beta, used to validate changes before promotion to production, in the Development AWS account.
Ad-hoc environments may be provisioned for integration with customer systems, following Secure development.
Isolation between environments
Section titled “Isolation between environments”Production and non-production environments live in separate AWS accounts, so production data is not reachable from non-production workloads. Customer data is never copied from Production into Beta or development; non-production environments hold seeded or synthetic data.
Scaling
Section titled “Scaling”Compute scales automatically with load. AWS Lambda functions scale horizontally per invocation; ECS services (the transcription workers) scale on queue depth and scale to zero when idle. Aurora and DynamoDB scale read and write capacity within configured bounds.
Capacity alarms and SLO definitions are codified in Terraform alongside the resources they protect; routing into incident.io follows the service-prefix pattern described in Observability § Alarms.
Architecture diagrams
Section titled “Architecture diagrams”System context:
Platform containers:
LTI 1.3 integration
Section titled “LTI 1.3 integration”Changineers integrates with Learning Management Systems (LMSs) using the LTI 1.3 specification, published by 1EdTech (formerly IMS Global). Changineers acts in the LTI Tool role; LMS products such as Moodle, Canvas, and Blackboard act in the Platform role.
Three services from LTI Advantage are in use:
- Core Launch (LTI 1.3), initiated by an instructor from the LMS to register Changineers as a tool on the course. The registration makes Changineers visible as a gradebook column and enables the NRPS and AGS services below.
- Names and Role Provisioning Services 2.0 (NRPS 2.0), which synchronises the course roster from the LMS at launch time so that users in Changineers correspond to the users in the LMS.
- Assignment and Grade Services 2.0 (AGS 2.0), which sends a learner’s score back to the LMS gradebook when they complete an activity in Changineers.
Students do not launch into Changineers via the LMS. They access Changineers directly; the LMS integration only surfaces to students as their score in the gradebook column.
Both services are layered over open standards:
- OpenID Connect Core 1.0 for the launch handshake.
- OAuth 2.0 Client Credentials Grant (RFC 6749) with JWT Bearer Assertions (RFC 7523) for service-to-service authentication when posting scores.
The integration exposes three endpoints on the Tool side:
POST /lti/loginreceives the OIDC login initiation from the LMS.POST /lti/launchreceives the signedid_tokenfrom the LMS and establishes a session.GET /lti/jwksserves the Tool’s public keys so the LMS can verify tokens that Changineers signs.
Nonce replay protection is enforced for each launch; each id_token
is signature-verified against the LMS’s JWKS, and state values are
single-use.
LTI integration components:
LTI launch and grade sync flow: