AWS for Games Blog

Aligning AWS security capabilities with standards and security frameworks for the Betting and Gaming industry – Part 2

In Part 1 of this series, we described how AWS security best practices, using the AWS Security Improvement Program (SIP) and the Security pillar of the AWS Well-Architected Framework, can help Betting and Gaming operators strengthen foundational cloud security, covering information security, identity and access management, audit and logging, network security, and multi-account strategy. Part 2 turns to gaming-specific controls and resilience: geolocation, random number generation, responsible gaming and anti-fraud, change management, and disaster recovery.

Important: The descriptions herein are framed as general-purpose capability overviews. Nothing in this document constitutes regulatory, legal, or compliance advice. Customers are solely responsible for determining how, or whether, AWS services address their specific regulatory obligations. The AWS Shared Responsibility Model defines the division of security responsibilities between Amazon Web Services (AWS) and its customers. AWS is responsible for security of the cloud (physical infrastructure, hardware, networking, and managed service components), while customers are responsible for security in the cloud (data, access management, application configurations, and compliance obligations). Using AWS services doesn’t automatically make your use case compliant. The controls described in this post represent AWS customers’ responsibility within the AWS Shared Responsibility Model. Your compliance posture depends on how you configure and use AWS services for your use case.

GLI standards overview

GLI-19 (Interactive Gaming Systems) is the global benchmark for iCasino, online poker, and iLottery platforms. GLI-19 defines technical requirements across nine domains: architecture, information security, player account management, random number generation (RNG) integrity, geolocation, encrypted communications, audit and reporting, responsible gaming, and change management.

GLI-33 (Event Wagering Systems v1.1) addresses online and mobile sports betting platforms across 20 domains and 66 controls. These controls include architecture, information security, geolocation, know-your-customer (KYC), responsible wagering, financial controls, anti-fraud monitoring, data feed integrity, change control, and independent certification.

GLI also publishes the Gaming Security Framework (GLI-GSF), a suite of information security audits (GSF-1 through GSF-5) covering controls, technical assessments, vendor audits, and both land-based and online environments. GLI-GSF aligns closely with the CIS principles.

Both GLI-19 and GLI-33 share common security themes that are relevant to the five pillars of the AWS Security Improvement Program (SIP), as described in the AWS re:Post article on SIP. The pillars are:

  • Identity and access management
  • Detection and monitoring
  • Infrastructure protection
  • Data protection
  • Incident response

The following sections describe ways you can configure AWS services to support your security objectives. This content reflects generally available AWS capabilities as of the date of publication and is informational only.

Geolocation and jurisdictional compliance

Security theme: Player location verified at session start and periodically, multi-factor geolocation (GPS, Wi-Fi, IP, cell tower), certified vendors, and data residency for certain jurisdictions.

AWS capabilities: AWS offers infrastructure capabilities that you can use and configure when implementing your own geolocation compliance strategies. You can use AWS Outposts to specify geographic boundaries for processing data. Amazon API Gateway provides connectivity to third-party providers that you select. You can use AWS Control Tower guardrails to restrict resource provisioning to specific AWS Regions as part of your own compliance programs.

Geolocation verification—including vendor selection, certification, implementation, and ongoing compliance—is solely your responsibility. AWS doesn’t provide, design, or certify geolocation solutions for gaming compliance purposes. You should work directly with your regulators and licensed geolocation vendors to determine appropriate architectures.

Random number generation

Security theme: Statistically unpredictable, independently certified random number generation (RNG) with hardware entropy sources (high-quality sources of randomness used to seed cryptographic algorithms) and isolation from other components.

AWS capabilities: AWS doesn’t design, build, certify, or provide RNG solutions for gaming. If you require RNG for regulated gaming, you must work with licensed gaming suppliers and independent testing laboratories. AWS offers generally available cryptographic services that customers across all industries use for a variety of purposes, including:

  • AWS KMS GenerateRandom API – Helps provide cryptographically secure random byte generation backed by hardware entropy sources; and
  • AWS CloudHSM – Helps provide FIPS 140-2 Level 3 validated hardware security modules.

Whether and how these general-purpose services are used as part of a gaming RNG architecture is solely your (or your licensed gaming supplier’s) decision. Any gaming-specific RNG implementation, testing, certification, and ongoing compliance remains the exclusive responsibility of you and your certified suppliers.

Responsible gaming and anti-fraud

Security theme: Self-exclusion integration, deposit, loss, and time limits, reality checks, collusion detection, and unusual betting pattern monitoring.

AWS capabilities: To build responsible gaming and anti-fraud systems, you can use the general-purpose analytics and machine learning services provided by AWS as infrastructure components within your self-defined architectures. Relevant services include:

The design, implementation, and regulatory compliance of responsible gaming controls (including self-exclusion list integration, deposit and loss limits, integrity monitoring, and collusion detection) is solely your responsibility. AWS doesn’t design or provide regulated gaming solutions, determine compliance requirements, or advise on how to satisfy regulatory obligations. You should consult your own legal counsel and regulators to determine appropriate controls for your jurisdictions.

Change management and incident response

Security theme: Regulator notification before production changes, re-testing and approval, version tracking, rollback capability, documented incident response (IR) procedures, forensic preservation, and timely regulator incident notification.

AWS capabilities:

Disaster recovery

Security theme: Documented business continuity plans, system redundancy, defined recovery time objectives (RTO) and recovery point objectives (RPO), failover testing, and the ability to resume operations without loss of critical player data or transaction integrity.

AWS capabilities:

Together, the four capability areas covered in Part 1 and the five in this post form a comprehensive security posture aligned with AWS operational best practices. Effective implementation requires a well-designed account structure that can support isolation, centralized audit, and scalable governance, as described in Part 1.

Getting started

The following sequence of activities represents a recommended starting point. You should adapt it based on your environment and requirements.

  1. Engage with the Security Improvement Program (SIP): Contact your AWS Technical Account Manager to initiate a SIP assessment. This engagement helps baseline your environment against 200 security best practices and produce a prioritized action plan with near-term improvements (implementable in days) and strategic improvements.
  2. Foundational controls: As a security baseline, prioritize enabling CloudTrail, GuardDuty, default encryption, a multi-account structure, AWS Config conformance packs, and AWS Control Tower. These services help provide detective and preventive controls and can typically be deployed within the first 30 days of a security improvement initiative.
  3. Customer-determined controls: Work with your legal counsel, licensed gaming suppliers, and regulators to identify and implement any additional controls required by specific jurisdictions. AWS general-purpose services serve as the infrastructure components within your architectures.
  4. Continuous compliance: Establish ongoing AWS Security Hub scoring, AWS Config drift detection, regular security assessments, incident response simulations, and recurring SIP reviews on a 6–12 month cadence. The regulatory and technical landscape evolves, and continuous adherence requires ongoing monitoring.

Conclusion

By implementing AWS security best practices through SIP and the Well-Architected Security pillar, you can build architectures that support broader security and operational objectives through automation and proactive posture management. This approach can scale across jurisdictions without duplicating administrative complexity.

The key is approaching regulatory compliance not as a point-in-time certification event, but as an ongoing discipline you embed in your cloud architecture. You are solely responsible for determining and meeting your regulatory compliance obligations, including obtaining necessary certifications and approvals. AWS doesn’t provide compliance advice or make any representation that the use of any AWS service satisfies regulatory requirements.

The regulatory landscape continues to evolve, with new jurisdictions expanding online wagering and existing jurisdictions tightening technical requirements. In this environment, a cloud-native approach to security and infrastructure can help you focus on your core business while maintaining robust security foundations. To get started, engage your AWS account team or Technical Account Manager (TAM) to initiate a SIP engagement and a Well-Architected Security pillar review tailored to your regulatory requirements.

Additional resources

Disclaimer: This article represents general architectural guidance and does not constitute legal, regulatory, or compliance advice. AWS services described herein are general-purpose capabilities available to customers across all industries. Nothing in this document should be interpreted as a representation by AWS that any service, configuration, or architectural pattern satisfies any regulatory requirement, certification standard, or legal obligation.

Customers are solely responsible for assessing and fulfilling their own compliance and regulatory obligations, including consulting their own legal counsel, licensed gaming suppliers, and the relevant regulatory authorities for their jurisdictions.

Sirinda Glasgow

Sirinda Glasgow

Sirinda Glasgow is a Sr. Technical Account Manager at AWS Enterprise Support, specializing in security and compliance and hybrid edge infrastructure for Betting and Gaming customers operating regulated workloads.

Brian Dixon

Brian Dixon

Brian R. Dixon is a Technical Account Manager at AWS Enterprise Support, specializing in cloud security architecture and compliance frameworks in highly regulated industries.

Nick McCabe

Nick McCabe

Nick McCabe is a Solutions Architect at AWS Enterprise Support, specializing in cloud migrations, hybrid edge infrastructure, and cloud architecture for Betting and Gaming customers operating regulated workloads.