It’s so easy to scale services in the cloud – and costs can start really low due to the massive economies of scale, so why wouldn’t you build your web presence in the cloud?
This website is hosted on AWS, currently on pattern #2 below, but as my audience grows, I may have the need to scale up. Each architectural pattern begins with a display of service benefits:
- Cost effective: Costs are optimised for the solution
- Fully managed: Automatic provisioning and ongoing management of services
- High availability: Continuity of the service following an outage/disaster
- High scalability: To automatically serve multiple requests for a website as demand increases (and decreases)
#1 Simple web presence 
Cost effective
Fully managed Availability Scalability
1 x EC2 on demand instance, elastic IP and A record pointing from external DNS
Website runs on 3 docker containers:
Docker-Compose and dockerfile is used to orchestrate the spin-up process, SSL provided by Let’s Encrypt. Website provided by WordPress.
#2 Expanding Audience 
Cost effective Fully managed Availability Scalability
EC2 instance used is now a reserved instance (1 year)
Use EventBridge and Lambda to create regular, scheduled backups of the EC2 instance as an AMI.
Use EventBridge to detect state change in EC2 instance (fail) and use Lambda to spin up a new EC2 instance using AMI & attach existing elastic IP
#3 Foundations for Future Demand 
Cost effective Fully managed Availability Scalability
The website is still not fully scalable because the docker containers are all hosted on one EC2 instance, including the Database.
EventBridge and Lambda configuration are replaced with an Auto Scaling Group.
External DNS is updated to point to Route 53, this replaces the need for an elastic IP. Route 53 points to the Auto Scaling Group with the single EC2 instance as a target. The ASG has min capacity: 1, desired capacity: 1, max capacity: 1
The ASG performs health checks on the EC2 instance and automatically recovers the instance if it changes state using the AMI generated in #2.
#4 Decoupling the Website 
Cost effective Fully managed Availability Scalability
Migrate the MariaDB Database from a docker container to RDS for MariaDB. Take a backup using Mariabackup, then save to the EC2 host. Now copy the backup files to S3 and finally restore from S3 to RDS for MariaDB.
Reconfigure docker-compose to use Docker-Swarm & edit the DB connection to point to the RDS endpoint. Spin up 2 x EC2 instances (1 Nginx manager instance & 1 php-fpm worker instance).
The Auto Scaling group is deleted as it cannot be used alongside orchestration tools like Docker Swarm. At this point it would be better to move from containers to nginx/php-fpm installed directly on EC2 instances.
Note: scaling is manual, but supported by Docker Swarm which load balances across containers.
#5 Moving to fully Managed Services 
Cost effective Fully managed Availability Scalability
We will leverage the ECS service to host and manage the containers. Create images of the nginx and php-fpm containers and add them to ECR. Create 3 separate VPC’s in 3 Availability zones within 1 region.
Create an ECS cluster using the Fargate launch type. Specifying the images and VPCs for instance deployment. Add an Application Load Balancer in front of ECS specifying all AZ’s.
Onward!
One of the biggest benefits offered by AWS is managed services. I can get on with growing my audience and creating great content while my site is fully managed by AWS. This becomes ever-more a priority as my site grows in popularity.
Did this post peak your interest or provide you with any insights for your own hosting needs? Why not contact me to arrange a no-obligation chat?