Currently all of our PHP (Laravel) applications are running on one EC2 instance. To deploy code, we SSH onto the live box and pull from CodeCommit.

We now need to scale and deploy properly. I'm not sure where to start.

Most examples seem to use Elastic Beanstalk but I have been advised that this could be too restrictive.

I guess we want to end up with a load balancer and application servers which are created on demand.

Can anyone point me in the right direction? (I am a bit overwhelmed by all the AWS documentation.)

Ok, this is the plan:

I have signed up for A Cloud Guru and I'm going to work through some of the videos on there.

I'm going to sign up for a AWS Free Tier account and start tinkering.

I'm considering the AWS Certified Solutions Architect - Associate course, this looks like a great way to develop myself.

  • docs.aws.amazon.com/autoscaling/latest/userguide/…
    – 030
    Commented Sep 21, 2017 at 10:46
  • 1
    That depends on how much you need to scale. If you are going from a single server to a thousand, it is not the same as if you are just going from a single server to two or three. If you are staying small, I would check AutoScaling, SSM (RunCommand) and / or OpsWorks
    – AlvaroGMJ
    Commented Sep 21, 2017 at 13:42
  • Probably 500 users max, at the moment any scaling would be better than having all the applications running on one instance. 3 servers and a load balancer would be a good start.
    – Mick
    Commented Sep 21, 2017 at 14:40
  • @Mick - What did you end up doing? Commented Jul 9, 2020 at 14:17
  • If I had to do this now, I would probably look at the Azure App Service or similar.
    – Mick
    Commented Jul 9, 2020 at 14:35

2 Answers 2


Here's a rough approach to scaling any stateless app on AWS:

  1. Run the app in an Auto Scaling Group (ASG). An ASG makes it easy to manage multiple servers, will automatically replace failed servers, and allows you to automatically scale the number of servers up or down in response to load.

  2. To run an ASG, you need to create a Launch Configuration. This is a "template" that specifies the configuration for each server in the ASG: i.e., what type of instance to run (e.g. t2.micro), what AMI to run on the instance, the security group settings, etc.

  3. The AMI you run on each instance in the ASG should have your app already installed (i.e., your PHP app). You can define your AMI as code using a tool like Packer.

  4. The app in your AMI should be configured to run on boot using a process supervisor (e.g., using systemd or supervisord; this will also ensure the app is restarted automatically if it crashes.

  5. Every time you change something in your app, run a build process to create a new AMI, update the Launch Configuration to use this new AMI, and roll that AMI out across your ASG. For example, you could do a zero-downtime deployment (somewhat similar to a blue-green deployment) by doubling the size of the ASG, waiting until all the new servers (from the updated Launch Configuration) launch and pass health checks, and then reducing the ASG back to its previous size (the ASG will terminate oldest instances by default).

  6. With an ASG, you have more than one server, but you want to give your users a single endpoint to use. The typical solution to this is to deploy a load balancer in front of the ASG. If you're building a typical HTTP/HTTPs app (e.g., just about all PHP apps), you'll want to use the Application Load Balancer (ALB); if you're building an app that listens directly for TCP connections, you'll want the Load Balancer Classic or Network Load Balancer. Whichever load balancer you pick, AWS will create a domain name for it that you can use, and any requests you send to that domain name will be routed in round-robin fashion to different servers in your ASG.

  7. You should a) configure the load balancer to perform health checks on your app so that it only routes to healthy servers and b) configure your ASG to register all of its servers in the load balancer automatically and to use the load balancer for health checks.

  8. You can create Auto Scaling Policies for the ALB that change the number of servers in your ASG depending on various CloudWatch metrics. For example, you could configure the ASG to add servers when average CPU usage is over 80% and to remove servers when CPU usage drops below 60%.

For more info, check out A Comprehensive Guide to Building a Scalable Web App on Amazon Web Services.

  • Are you sure about this?: "The AMI you run on each instance in the ASG should have your app already installed ". My Manager strongly believes that the application code should not be part of the AMI. Do you have a reference for this?
    – Mick
    Commented Sep 26, 2017 at 13:32
  • @Mick Heh, yea, pretty sure :) The approach I'm describing is called "Immutable Infrastructure". If you google it, you'll find plenty books and blog posts on the topic (I also talk about it in my own book, Terraform: Up & Running). The idea is to create immutable, versioned images that have all of your application code baked in. You can then promote the exact same image from environment to environment and easily roll back if there is any issue. There are many ways to do it, such as using Packer to build AMIs or Docker to build Docker images. Commented Sep 27, 2017 at 3:30
  • Thanks (apologies for doubting you), I have done a bit more reading since I posted and now understand Immutable and Mutable. I'm just not sure what is best for us, we tend to do small changes and often and I'm not sure I want to build a new AMI everytime we update the code.
    – Mick
    Commented Sep 27, 2017 at 7:44
  • @Mick If you define your AMI using a tool like Packer, then building a new AMI will be completely automated, so it's completely reasonable to build a new one after every commit. You could even extract all the dependencies that don't change often into a "base" AMI and use that as the "source" for your app AMI so the build is effectively just copying in your new code. Alternatively, look into Docker, which, due to caching, can allow you to build new images in seconds. Commented Sep 28, 2017 at 2:54

Currently all of our PHP (Laravel) applications are running on one EC2 instance. To deploy code, we SSH onto the live box and pull from CodeCommit.

The first thing you need to decide on is a Continuous Deploy strategy. There's a lot of servers out there with different use cases, you don't have to pick the most popular, just pick the one that fits your use case.

I guess we want to end up with a load balancer and application servers which are created on demand.

AWS has some great reference architectures but overall I would say start simple. At a base level you'll be using Route 53, Certificate Manager, ALB (ELBv2), VPC, and EC2. I would get used to the options you have with each of these and play with them. AWS CSA will not teach you about reference architecture, rather it will go over what each product is used for.

Before you go building anything for production I would also recommend using an infrastructure deployment tool. AWS provides CloudFormation out of the box but that can be difficult to interface with. Some others are Sceptre and Terraform. These allow you to store your infrastructure as code in a repository and deploy updates via a CD server.

Also keep in mind if you don't have Continuous Integration then you'll need to work on that, followed by Continuous Delivery, then by Continuous Deployment. Each of these is a critical step in the right direction.

Note on "Created on Demand"

Please keep in mind that many people come to the cloud thinking that "scaling" is instantaneous. It's not. Depending on your provisioning it can take some time. You will not scale yourself out of burst traffic. Your traffic will need to be profiled, you will need to determine your instance capacity (for web servers I measure instances in requests per second with a load testing tool), and plan accordingly.

Scaling is primarily designed for a gradual rise in traffic over time, such as if your website traffic grows gradually larger around noon (peak) and then settles late in the day.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.