Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

GAMEOPS02-BP01 Adotta una strategia multi-account per isolare giochi e applicazioni diversi nei propri account

Progetta una struttura di account che guidi l'implementazione dell'infrastruttura per soddisfare le esigenze di sicurezza, isolamento e operative di ogni ambiente. L'isolamento dell'ambiente, mediante la limitazione dell'accesso ad esso e la possibilità di utilizzare solo AWS i servizi necessari, è essenziale, in quanto gli ambienti di produzione sono bloccati, mentre gli ambienti di sviluppo e test sono favorevoli alla sperimentazione. Si consiglia vivamente di isolare ulteriormente i principali sottosistemi in ogni ambiente e di ospitare e gestire autonomamente i servizi comuni utilizzati da più ambienti. Account AWS

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all’implementazione

Adotta una strategia multi-account AWS isolando i diversi ambienti (come sviluppo, test, staging, produzione e servizi condivisi) tra singoli ambienti, in modo da ridurre la Account AWS portata degli incidenti. Prendi in considerazione la possibilità di AWS Organizations gestire centralmente la gerarchia per Account AWS semplificare ulteriormente le operazioni, nonché di definire e applicare in modo selettivo le politiche a livello di account e di unità organizzativa (livello di unità organizzativa). Progettando un'unità Account AWS organizzativa e una struttura appropriate in linea con le esigenze del flusso di lavoro di sviluppo e produzione, è possibile ottimizzare i costi e migliorare la scalabilità.

Passaggi dell’implementazione

Un sistema di gioco distribuito in AWS dovrebbe utilizzare più account organizzati in modo logico per garantire un isolamento adeguato, che riduce la portata dei problemi e semplifica le operazioni man mano che l'infrastruttura di gioco si espande. Account AWS le infrastrutture di gioco che ospitano i giochi sono in genere raggruppate nei seguenti ambienti logici:

Per l'infrastruttura di gioco AWS attiva, si consiglia di creare account separati per ogni ambiente di gioco (sviluppo, test, allestimento e produzione), nonché account per la sicurezza, la registrazione e i servizi condivisi centralizzati.

In genere, gli studi di sviluppo di giochi più piccoli che gestiscono un numero limitato di risorse infrastrutturali, in genere poche centinaia di server o meno, possono crearne uno Account AWS per ciascuno di questi ambienti (ad esempio, un account di produzione, un account di sviluppo e un account di staging). Tuttavia, man mano che l'infrastruttura di gioco o le dimensioni del team aumentano nel tempo, questo modello semplificato potrebbe non adattarsi bene.

Quando configuri questi ambienti, tieni presente che molti AWS servizi condividono le Service Quotas a livello di risorse e API per un intero account all'interno di una particolare regione. Questo deve essere considerato quando si determina come organizzare gli account in modo logico. Account AWS devono sostenere i costi solo per il consumo dei servizi in essi distribuiti. Pertanto, ciò consente di ridurre efficacemente la contesa di risorse e le quote di servizio, in particolare man mano che il gioco cresce e sempre più sviluppatori hanno bisogno di accedere per creare e gestire le risorse.

In base alla nostra esperienza di collaborazione con grandi studi di sviluppo di giochi che in genere gestiscono migliaia di server e centinaia di sviluppatori accedono alle risorse, ti consigliamo di progettare una struttura di account più dettagliata in cui le singole applicazioni che supportano il gioco abbiano i propri account di sviluppo, test, staging e produzione. Poiché è difficile e dispendioso in termini di tempo riprogettare la strategia AWS multi-account dopo aver lanciato il gioco a causa della complessità della pianificazione e della migrazione dei sistemi live, prendi in considerazione le tue future esigenze di scalabilità nel determinare la giusta struttura multi-account. 

È possibile utilizzarla AWS Organizationsper impostare una gerarchia e un raggruppamento di Account AWS unità organizzative e definirle (OUs) per applicare loro politiche comuni a livello di unità organizzative tramite politiche di controllo del servizio (). SCPs AWS Organizations gestisce e governa centralmente l'ambiente man mano che crescete e scalate le risorse. Puoi creare nuovi account e allocare risorse in modo programmatico, raggruppare account per organizzare i flussi di lavoro, applicare politiche di governance agli account o ai gruppi e semplificare la fatturazione utilizzando un unico metodo di pagamento per i tuoi account. Inoltre, Organizations è integrato con altri servizi in modo da poter definire configurazioni centrali, meccanismi di sicurezza, requisiti di audit e condivisione delle risorse tra gli account dell'organizzazione.

AWS Control Toweroffre un modo semplice per configurare e gestire un ambiente sicuro con più account, chiamato landing zone. Control Tower crea la tua landing zone utilizzando AWS Organizations, offrendo una gestione e una governance continue degli account, nonché le migliori pratiche AWS di implementazione basate sull'esperienza di lavoro con migliaia di clienti durante il passaggio al cloud. AWS ConfigAWS Trusted Advisor, e AWS Security Hub CSPMsono servizi che forniscono una visione aggregata o centralizzata dell'igiene del tuo account.

Questo isolamento ti aiuta a configurare autorizzazioni e barriere personalizzate o individuali per ogni ambiente di gioco. Gli account di produzione dovrebbero avere i guardrail, le restrizioni di accesso, il monitoraggio e gli avvisi e gli strumenti di sicurezza necessari, mentre gli account non di produzione potrebbero non richiedere lo stesso livello di guardrail e autorizzazioni. Gli ambienti non di produzione possono essere automatizzati per disattivare le risorse fuori orario e ridurre i costi. La separazione degli account a questo livello di granularità semplifica il monitoraggio dei costi di infrastruttura per ciascuno degli ambienti che supportano un gioco.

Di seguito è riportato un esempio di struttura multi-account per una società di giochi che utilizza unità organizzative (OUs) per raggruppare Account AWS logicamente in ambienti AWS Organizations e studi separati. In questo esempio, OUs vengono utilizzati per raggruppare gli account in base al rispettivo ambiente e quindi in base allo studio che gestisce l'ambiente. Questo dimostra come è possibile creare una gerarchia annidata per consentire la distribuzione di applicazioni e giochi separati nei rispettivi account all'interno del rispettivo ambiente (illustrato come OUs), il che può essere utile se si sviluppano e gestiscono più giochi. Consulta la documentazione e i white paper forniti nella sezione risorse di questo pilastro per scoprire le strategie aggiuntive da prendere in considerazione per organizzare la tua strategia multi-account.

Sulla base della discussione precedente, il diagramma di esempio seguente presuppone uno studio di gioco (Organizzazione) con una pipeline di sviluppo composta da 4 fasi (sviluppo, test, messa in scena e produzione). Per un determinato gioco (game1), ogni ambiente (OU) dispone di servizi di gioco individuali, server Account AWS di gioco dedicati, servizi social e server web. Le risorse che vengono eseguite in ciascuno di essi Account AWS sono pertinenti ai rispettivi sottosistemi. In genere, ogni singolo gioco che utilizza questo tipo di pipeline di sviluppo replicherebbe questa struttura o una struttura simile. Account AWS

Oltre a questi ambienti incentrati sul gioco OUs, ci sono anche l'unità organizzativa dei servizi condivisi e l'unità organizzativa di sicurezza. Questi OUs dovrebbero riguardare l'intera organizzazione, non ogni singolo gioco. In questo modo i giochi consumerebbero i servizi condivisi per gli strumenti di sviluppo, i dati e l'analisi, come in questo esempio. Quindi, invia i registri delle applicazioni e del sistema alla Account AWS configurazione per i registri nell'unità organizzativa di sicurezza.