AWS architecture design

Question

Dans notre société, nous prévoyons de lancer notre plate-forme Web via l'AWS. J'ai préparé la conception d'architecture et je vous demande de bien vouloir donner votre avis sur la façon de l'améliorer. Quelques notes ..

BASE DE DONNÉES

• Nous allons avec MariaDB (maître + esclave sur d'autres AZ)
• DB Master est uniquement accessible pour les Admins pour écrire/supprimer/lecture
• Fin -utilisateurs lirons tous de répliques de lecture (4 répliques accross 2 AZ)
• Maître = T2.micro
• lire les répliques = T2.small

ADMIN

• panneau d'administration sera l'application seperated, le sous-domaine séparé et SSL activé
• panneau d'administration est le seul qui est en train de modifier maître RDS Nombre de utilisateurs: max 10 : D
• serveur Web: Lighttpd/Apache (commentaire?)
• machine: T2.nano
(pas de besoin de plus pour 10 utilisateurs, non?)

AVANT (FIN-UTILISATEURS)

• Front desservira beaucoup d'utilisateurs (jusqu'à 10mio)
• machines EC2 seront T2.small
• Web serveur: lighttpd/Apache (commentaire?)
• Nous avons beaucoup d'utilisateurs, mais chaque utilisateur est seulement 1 demande PHP (1 php + sélectionnez le script sur RDS Lire Replica)
• Tous les autres fichiers sont statiques et seront servis à partir de notre CDN (Origin sera EC2 T2.nano, car il y a vraiment peu de trafic, juste en afin de mettre en cache de nouveaux fichiers sur CDN)
• Bien sûr, les machines EC2 pour front seront à autoscallage. 2 AZ différents à choisir. (est-ce que ce groupe de 1 autoscale est dans ce cas ou 2 groupes?)

BACKUP et SÉCURITÉ

• maître DB automatiquement la sauvegarde
• Nous ne snapshotting automatisé d'administration EC2 & Origine CDN Webserver
• Pas besoin de backuping des instances Frontend EC2 AUTOSCALE, tout le code sera automatiquement déployé avec CodeDeploy de Github

Here's the current arhitecture design diagram.

S'il vous plaît aider et fournir quelques commentaires. Quels sont les goulots d'étranglement? Avons-nous oublié quelque chose d'important?

Answer 1

difficile de savoir, sans connaître beaucoup sur votre cas d'utilisation, mais quelques petites choses sautent me:

• Vous dites que vous servirez « beaucoup » d'utilisateurs, mais utilisez une combinaison de t2 .nanos, t2.micros et t2.smalls - cela peut devenir un goulot d'étranglement. Je pense à t2 est bon pour test/dev et très petites charges de production. Pas pour servir «beaucoup d'utilisateurs» - cela peut rapidement devenir un goulot d'étranglement. Envisagez d'utiliser un compartiment S3 pour l'origine de vos actifs statiques au lieu d'une instance t2.nano, moins cher, plus facile et plus évolutif si nécessaire; il n'y a aucun inconvénient à cela.