Il cloud su cui costruiamo Brova Cloud.

No. AWS è ciò a cui ricorriamo quando un carico di lavoro ha davvero bisogno della profondità di un hyperscaler: database gestiti su larga scala, un CDN globale, funzioni serverless, o requisiti di compliance specifici. Per carichi più piccoli o prevedibili, un'infrastruttura self-hosted su Proxmox o una configurazione più semplice è spesso la risposta migliore e più economica; la fase di progettazione dell'architettura nel processo decide cosa è adatto.

Approvvigioniamo l'infrastruttura come codice, così gli ambienti sono riproducibili e versionati invece di configurati a mano e non documentati. L'accesso a privilegio minimo viene configurato deliberatamente (VPC e IAM impostati con intenzione, non lasciati di default), e monitoraggio, scalabilità e risposta agli incidenti funzionano come parte di Brova Cloud invece di una coda di ticket separata e scollegata di cui nessuno si occupa.

Entrambi funzionano. I progetti possono girare sotto il vostro account AWS (il che mantiene fatturazione e proprietà interamente presso di voi) o sotto il nostro ambiente gestito come parte di Brova Cloud. Cosa ha senso dipende dai vostri requisiti di compliance e da se volete che un team interno dedicato prenda eventualmente in carico le operazioni.

Qualsiasi cosa con traffico imprevedibile o su larga scala, carichi che necessitano database gestiti come RDS o Aurora, distribuzione di contenuti globale tramite CloudFront, o funzioni serverless per lavoro puntuale innescato da eventi. Se niente di tutto questo si applica, ve lo diremo invece di raccomandare per default l'opzione più grande disponibile.

Brova Cloud è il nostro livello di gestione operativa; AWS è uno dei fornitori di infrastruttura su cui la costruiamo per i progetti che ne hanno bisogno. Brova Cloud è la disciplina di monitoraggio, patch e risposta agli incidenti; AWS è il calcolo, l'archiviazione e la rete sottostanti per carichi di lavoro di quella scala.