Technology Standards for Third Party Developers on AWS
Cloud Standards
Hosting
Unless the software solution is delivered as a fully SaaS solution, MH requires that all components be hosted on a McGraw Hill owned AWS cloud account with our AWS organization.
- McGraw Hill utilizes AWS Organizations and Control Tower to group related applications into separate account structures. There will be one production and one non-production account provided. All software development activity must occur exclusively in the non production account.
- All web applications or services relying on HTTP protocols must be delivered via a McGraw Hill owned domain name. No third party domain ownership is permitted.
- McGraw Hill utilizes a split-DNS model where non-production sites are not exposed to the public internet and operate on an internal onlydomain accessible only by VPN.
- If AWS does not provide a service or capability that meets the business objective, McGraw Hill will support Azure services. Written approval to utilize Azure is required.
- Access to AWS is provided by McGraw Hill through an OKTA controlled account. Developers will authenticate via OKTA to an AWS SSO Landing page or access key.
- MH utilizes three tiers of access policy when granting IAM user access via OKTA. Requests are submitted and tracked via MH Assist
- Read Only: Can view most AWS services.
- Protected: Write permissions for common services such as EC2, RDS, or S3.
- Power User: Most AWS services are configurable with the exception of network or account level controls.
- If the solution requires a server, MH provides several base AMI instances, and only MH provided AMIs are permissible. AMIs are required to be rotated monthly. The following types are available:
- ECS Base AMI for ECS applications
- EKS Base AMI for EKS clusters
- Amazon Linux 2 AMI for non-dockerized workloads
- Windows AMI for Microsoft Windows.
Tagging
In order to perform proper automation and cost reporting, McGraw Hill mandates the use of cloud assets tags to be applied during asset creation, typically via Terraform.
Development Lifecycle
- Software is required to be tested and promoted via test environments. The best practice is DEV -> QA -> PROD.
- We enforce prod / non-prod isolation. Production services are not permitted to call endpoints registered within a non-prod account, nor are non-prod services permitted to utilize production services unless an exception is granted.
Automation
- While hand provisioning of cloud resources is to be expected in a sandbox, once an application begins participating in SDLC, we require the use of infrastructure-as-code automation. We have standardized on Terraform, and have a number of shared modules for the most commonly supported container-based hosting patterns (e.g. ECS or EKS, Serverless, ALB, Cloudfront, API Gateway, Aurora or RDS, Open Search, ElastiCache, and other common AWS services. We also support Terraform in Azure.
Authentication
- AWS logins are least-privileged based, where we register you with AWS SSO (which creates chained IAM users) . You will be grouped in either read only (limited console view), protected (you can start/stop most common services) or power user (most activities permitted). We utilize AWS Organizations, which includes Control Tower and SSM as a governance wrapper, so any action that would result in network or security changes that would place an account at risk are prohibited and prevented as part of account guardrails.
- Users in Azure are provisioned on an as-needed basis, with permissions crafted around the business case with subscription access likewise scoped.
- All access is audited and monitored.
Network Controls
The application will be deployed into a segmented AWS account that connects to shared services using the transit gateway. All accounts in McGraw Hill utilize pre-provisioned network segments. These are centrally managed to ensure the stability and reliability of McGraw Hill’s Enterprise infrastructure and are immutable. Each AWS account contains three public and three private subnets spread across availability zones. Network CIDRs are constrained to /21 or /22 segments. Requirements for larger network segments should be carefully planned and negotiated with Cloud Operations and Engineering.
- As an established best practice, all software deployments must utilize HA configurations spread across three availability zones to ensure reliability. This requires a minimum of two instances in two availability zones which guarantee redundancy. More complex applications may require more instances spread across the three availability zones to ensure Raft consensus. [1]
Software Development Standards
McGraw Hill prefers and supports OpenSource language frameworks. Supported serverside languages include Java, Node.js, PHP, and GoLang. Angular is the primary client-side language. Data functions are supported by Python or Scala.
Utilization of McGraw Hill Shared Services
McGraw Hill operates a shared technology microservice architecture that all applications that are customer-facing are required to utilize directly or through an LTI implementation wrapper. This platform provides common, reusable services exposing REST endpoints acting upon a single educational entity. McGraw Hill has standardized on an asset identification standard known as “XID” which serves as a globally unique identifier. Applications are not to develop their own implementations of these common services and must instead utilize the McGraw Hill Shared platform.
A full list is available outside of this document, but a common subset are:
- Login and Landing page: McGraw Hill has a common login flow for all customers and no web application shall create a unique login experience unless specifically authorized in the SOW
- Video Playback: Accessible and flexible video playback support.
- IDM (user management), ORG (educational hierarchies such as district/school).
- Roster (section/class), product (digital representation), entitlements (license/consumption)
- Scout (service configuration utility), Tass (service and user session tokens), LTI interoperability wrapper suite.
All microservices emit data through events onto a data backbone. New applications may subscribe to topics if required to cache data and respond to state change. Otherwise, all calls are to be made synchronously. No PII data may be stored in the third party application unless approved in writing.
Application design and architecture is expected to adhere to industry best practices, as expressed by the twelve-factor methodology. System architecture and flow diagrams are required and must be reviewed/approved by McGraw Hill designated staff.
1EdTech Learning Tools Interoperability (LTI)
Learning Tools Interoperability | 1EdTech
Product requirements may dictate that the software component be delivered as a LTI Tool. For external LMS platform integrations, MH provides a 1EdTech-certified LTI Advantage integration service, which internal tool providers access via the LARS integration service. LARS provides all LTI Advantage integration capabilities and services, via an LTI-compatible integration layer, which supports multiple LTI versions and security frameworks. Most MH Platforms are LTI 1.3 compatible. LTI 1.3 compatibility may be utilized in place of the shared service API integration. Adapter frameworks are available to serve as an abstraction layer between third party software components and LTI services.
Build and Configuration Management
- All build, compilation, test, validation, and deployments into a cloud platform must occur via continuous integration jobs orchestrated by GitHub Actions.
- All artifacts produced by these builds must be stored in JFrog Artifactory, which is a private container/artifact repository hosted by McGraw Hill. These artifacts will be scanned during storage to ensure they are malware/virus free. Teams are expected to utilize SonarQube for SonarQube OWASP Top10 plugin for static security scans.
- Release communication and validation is established via the JIRA ticketing system and any production changes must follow the McGraw Hill change control process.
- Database deployments are automated and managed within source control.
- All environments use the same build artifacts and configuration is injected by the environment.
- Builds and deploys must not incur downtime in production.
- When developing solutions for an existing platform, the delivered solution shall adhere to the Lint rules established for the target platform.
Security
- End to end Encryption is required. Data must be encrypted in transit and at rest in both addressable storage and offline backups.
- Software is scanned for common vulnerabilities through a combination of static and dynamic scanning. This begins once the software is deployed into a non-prod environment and has an endpoint available for scanning. The supplier will coordinate with the McGraw Hill CyberSecurity intake process to provide credentials for test scans. Sev1 and Sev2 defects must be remediated.
- Additional pen testing exercises are performed by a third party and may result in additional issues for remediation.
- No secrets are permitted to be stored in GitHub.
Instrumentation and Telemetry
- All running software must be observable. The preferred vendor-neutral way is to utilize OpenTelemetry and FluentBit/D for log shipping. We currently utilize New Relic as our primary APM platform, so if the software is not yet instrumented, it is a requirement to install New Relic agents for host monitoring, as well as establish Synthetic tests. Web delivery systems must install the New Relic browser beacon, as well as the Pendo agent if integrating with a licensed platform.
- Log stream data is routed to Datadog, which is our logging platform.
Service Level Objectives
In order to objectively measure software quality and end-user experience, the following golden signal indicators are utilized and measured over a 30 day period:
- Latency: Applications must perform with less than 3.0 seconds of observable render latency as measured from LargestContentfulPaint in browser DOM. Synchronous services are expected to resolve an HTTP transaction in less than 500ms, with 100ms being the target mean. These numbers must be achieved 95% of the time.
- Error Rate: HTTP responses outside of 200 or 4xx normal flow codes are not to exceed 1% rates.
- Uptime: Applications are expected to be available with successful responses at a rate of 99.95%.
- Security: Applications are required to be free of Critical and High CVE Vulnerabilities, and any security defect with a rating of P3 or higher priority must be resolved.
- Cost Efficiency: Applications are required to achieve the 4 standards above while striving to minimize operating costs. This is measured by the cloud provider's cost optimization tooling. Applications are evaluated for cloud-native scaling behavior where workload costs should closely mirror the transactional volume established by user interactions.
Source Control
Unless otherwise stipulated in the mutually signed statement of work, the following conditions apply:
- All source code developed for McGraw Hill LLC must reside in the corporate GitHub Enterprise Account and become the sole property of McGraw Hill. Source code includes application code, configuration, terraform, and any other textual configuration files necessary to compile, test, and deploy software to a cloud environment.
- Developers committing code to GitHub must use individually named accounts protected by OKTA. Shared accounts are not permissible.
- Do not store secrets in GitHub. Use AWS parameter store or Secrets Manager.
- Unit Tests of sufficient coverage (80% recommended) are required to enable automated deployment verification.
- Capacity Plan tests scripted in order to generate system stress up to 1.5x baseline throughput are required.