Passer d’AWS à Google Cloud Platform? Voici ce que vous devez savoir

Si votre organisation passe d’AWS à Google Cloud Platform ou si vous souhaitez simplement apprendre à utiliser un autre fournisseur de cloud, GCP est assez similaire à AWS et facile à utiliser. Nous discuterons des différences et des similitudes.

Les autorisations fonctionnent différemment

Le changement le plus important concerne le fonctionnement des autorisations et la manière dont vous gérez l’accès des autres utilisateurs de votre organisation. GCP et AWS appellent cette fonctionnalité Identity and Access Management, ou IAM, mais GCP adopte une approche différente.

Sur AWS, les «utilisateurs IAM» sont utilisés pour les comptes d’employés et les utilisateurs de services, et peuvent recevoir n’importe quel nombre d’autorisations, regroupées dans un politique. Il est courant que cette stratégie impose des restrictions sur les ressources spécifiques auxquelles l’utilisateur peut accéder, généralement en fonction du nom de la ressource Amazon, pour éviter de donner un accès à l’ensemble du service. Cela signifie que vous devrez généralement créer un grand nombre de vos propres stratégies IAM.

Sur GCP, tout, pas seulement les autorisations, est divisé en «projets» distincts. Tout comme AWS Organizations, les ressources de ces deux projets sont largement séparées. Cela facilite beaucoup la gestion des autorisations entre les projets.

Les utilisateurs généraux et les comptes de service sont également séparés. Les utilisateurs sont des utilisateurs à part entière de Google qui ont accès au projet. Les comptes de service fonctionnent de la même manière, mais sont créés manuellement pour le projet.

Les autorisations sont gérées avec des «rôles», qui ne servent pas le même objectif que les rôles IAM d’AWS (qui sont remplis par les utilisateurs du service). Les rôles ne sont qu’un groupe d’autorisations, un peu comme une stratégie AWS.

Un rôle peut être attribué directement à un utilisateur pour lui donner des autorisations à l’échelle du projet. Cependant, si vous souhaitez accorder des autorisations à une ressource particulière, vous n’avez pas besoin de créer une toute nouvelle stratégie IAM. Vous ajoutez simplement l’utilisateur à cette ressource et lui attribuez un rôle avec suffisamment d’autorisations pour faire son travail.

Vous obtenez un système dans lequel vous pouvez simplement ajouter des membres aux ressources auxquelles ils ont besoin d’accéder, sans avoir à vous soucier de la création, de la maintenance et de l’audit de tonnes de stratégies IAM. Dans GCP, vous devrez très rarement créer vos propres rôles IAM.

Le prix est en grande partie le même

Google Cloud Platform, étant un concurrent direct d’AWS, propose naturellement des tarifs très similaires et compétitifs.

Tout comme AWS, la tarification pour à peu près tout est payante à l’utilisation, avec une tarification mesurée en fonction de l’utilisation. Comme AWS, vous êtes facturé pour la sortie de données de n’importe où sur le réseau de GCP. Il existe également un niveau gratuit très généreux, avec un essai gratuit de 12 mois avec un crédit de 300 $.

Certains services refléteront directement le modèle de tarification d’AWS. Pour Cloud Storage, le remplacement de GCP pour S3, les quatre mêmes niveaux de tarification sont disponibles: Standard, Accès peu fréquent, Glacier et Glacier Deep Archive, sous des noms différents. Mais, ils sont tous à des prix compétitifs par Go par rapport aux prix d’AWS.

Vous pouvez afficher les détails de tarification de chaque service sur le site Web de GCP.

Services similaires

Google Cloud Platform propose de nombreux services destinés à remplacer directement la fonction de nombreux services AWS. Une liste complète de leurs produits est disponible sur leur site Web, mais nous discuterons des plus couramment utilisés.

Pour Calculer, Compute Engine est la version GCP d’EC2, vous permettant d’héberger des serveurs privés virtuels. Google adopte une approche plus laxiste et vous permet simplement de sélectionner le nombre de vcores et la quantité de mémoire que vous souhaitez provisionner, ainsi que la génération de processeur, plutôt que d’avoir un millier de SKU différents pour différents types d’instances. Pour courrir conteneurs, Cloud Run remplace ECS pour les déploiements simples et Kubernetes Engine remplace EKS (après tout, Google l’a inventé).

Pour sans serveur, Cloud Functions remplace Lambda et App Engine exécutera des applications complètes sur une plate-forme sans serveur.

Pour espace de rangement, Cloud Storage remplace directement S3 et propose de nombreux niveaux différents, tels que Glacier et Infrequent Access. Les disques sur lesquels les instances Compute Engine s’exécutent (volumes EBS) sont gérés dans Compute Engine et appelés SSD local ou disque persistant.

Pour bases de données, Google propose quelques offres. Cloud SQL remplace RDS pour les bases de données serveur MySQL, PostgreSQL et SQL. Pour les bases de données NoSQL, Google n’a pas encore géré MongoDB, mais il existe Firebase Realtime Database et Firestore, ainsi que Cloud Bigtable pour les bases de données à colonnes larges.

Pour la mise en réseau, Google propose également un service CDN comme CloudFront d’AWS, appelé Cloud CDN. Contrairement à CloudFront, sur le niveau de service réseau premium de Google, Cloud CDN peut effectuer un équilibrage de charge global à partir d’une seule adresse IP anycast, en raison de la majeure partie du trafic passant par le propre réseau de Google. Pour DNS, il y a Cloud DNS, et pour les équilibreurs de charge, il y a Cloud Load Balancing.

Si vous êtes habitué à AWS Passerelle API, La plate-forme de gestion des API Apigee de Google devrait être un bon remplacement.