3-tier architecture for Ghost deployment on AWS

Hello Folks,

I would like to deploy Ghost on AWS in a 3-tier architecture.

So my thought process is to have 3 private subnets in 3 AZs, 3 public subnets in 3 AZs as well. Internet Gateway attached to the route table for the public subnets and a NAT Gateway attached to the private subnets. Ubuntu 18.04 LTS AMIs for the servers in the private subnets attached to auto scaling groups and a load balancer. NGINX servers in the public subnets attached to auto scaling groups and load balancer. The load balancer for the NGINX servers will serve as the origin for the Cloudfront distribution and Web Application Firewall in front of it. S3 buckets for static storage that can be accessed via VPC Gateway endpoint by all servers in the VPC as required. Now I am thinking of using either MySQL or Amazon Aurora RDS on AWS that can be only reached from the app servers in the private subnets.

Here are a few questions:

  1. In the Ubuntu 18.04 LTS installation guide I see that nginx, sql server and everything else is installed on the same machine. Is there an installation guide for separating the installation in 3 separate tiers, web, app and db?

  2. If you do a separate mysql or Aurora DB installation what is the guidance on creating the DB schema separately not through the ghost install process?

  3. I have deployed ghost on Lightsail before however I don’t prefer packaged platform services since building each piece of infrastructure and controlling their security and operation is something I would like to manage myself. So the architecture I mentioned, is there something fundamentally wrong with it that Ghost cannot be deployed that way?

Thank you for your help.

Hey @aakashb :wave:

The 2 problems you’ll probably run into are:

  1. Ghost is not designed to be clustered - https://ghost.org/faq/clustering-sharding-multi-server/
  2. Migrations are tied to the running version of Ghost. They can be run separately, but each instance of Ghost will check for migrations when booting up

Your best bet is to use Ghost’s caching headers to configure a cache in front of your Ghost frontend, and limit access to the admin / API

Thank you so much @vikaspotluri123 for pointing me to the info I was looking for. This is a definite no-go.

While Ghost cannot be clustered, I don’t believe you’ll find it to be necessary. Ghost performs quite well on very small EC2 instances and you can scale vertically by increasing your instance size, as necessary. I assume what you really care about is building a secure, highly available site in AWS. Yes, that’s possible.

Create your AWS Aurora Serverless instance (I’d recommend Serverless since it scales and is automatically spread across 3 AZs), making sure your Subnet Group lists your 3 private VPC subnets. Once launched, record the instance URL, username, and password.

Create EC2 instance and follow the Ghost installation process, making sure to not install MySQL locally on the EC2 server. The ghost install script will ask you to enter your MySQL hostname, user name and password. Enter the Aurora values.

Create an Application Load Balancer with the same 3 AZs. Point it to a Target Group with your single EC2 instance.

Setup WAF and attach it to your ALB. You could add a WAF rule to limit access to the Ghost Admin UI to your IP address, for security.

Set up an EC2 Launch Template and Autoscaling Group (ASG) with a min/max size of 1 instance and no scaling policy. We don’t really want to scale (since Ghost cannot be clustered), but we do want to ensure that one instance is always running in one of your 3 AZs. If the instance hardware fails, or an AZ goes down, AWS will spin up a new EC2 instance and ensure that it’s connected to your ALB and receiving traffic. Any time you update your Ghost EC2 instance make sure you take an image of it and update your Launch Template with the new image name. If you need to scale vertically, just update your Launch Template with a new instance size.

2 Likes

Thank you @jbritten I am gonna give this a go and test it out.