Saltar al contenido

Moving Drupal instances on AWS

In our blog post today we tell you how we have managed to successfully move Drupal instances to Amazon Web Services to achieve greater security and scalability in an ecommerce of an important retail client.

The customer

Multinational customer, luxury fashion retailer, with thousands of employees located in different countries.

Their needs

In the collection of initial requirements, the following needs are indicated: 

  • Build up their internal portal with Drupal 8.7
  • Having a staging environment
  • Having a live environment
  • Access the front end servers (web servers) via ssh
  • Gain stability and scalability
  • Make the environment secure and safe
  • Focus on the platform

they also have specific PHP / Drupal requirements:

  • PHP common (meta-package name: php7.2-common)
  • MySQL (package name: php7.2-mysql)
  • XML (php7.2-xml)
  • GD image library (php7.2-gd)
  • JSON (php7.2-json)
  • cURL (php7.2-curl)
  • Mbstring (php7.2-mbstring)
  • Zip (php7.2-zip)
  • FPM (php7.2-fpm)
  • Composer
  • Drush
  • Nodejs
  • GIT (just for Staging)

Our proposal based on Drupal

Our proposal has been based on the idea to provide Drupal as PaaS- Platform as a Service, in order to make customer focusing only on the real core business: the internal portal. Forget about infrastructure limitations and issues and focus on Drupal!

The most effective way to have Drupal as PaaS is AWS Elastic Beanstalk.

Beanstalk configuration

In particular we have proposed the following setup of Beanstalk:

AWS Elastic Beanstalk2Elastic Bean PHP for live
Elastic Bean PHP for staging
Amazon EC232 web servers on T2.Medium instances for live
1 web server on T2.Medium instance for staging
Amazon RDS2Multi A-Z configuration, RDS db.T3.Medium MySQL with 20 GBs for live
Multi A-Z configuration, RDS db.T3.Medium MySQL with 20 GBs for staging
Elastic Load Balancer1High availability for production (estimating 50 GBs per month)
Amazon Elastic File System250 Gbs for live
50 Gbs for staging
Autoscaling1Autoscaling service


It follows a list of the main macro activities we run in order to have a proper Drupal Staging / live environment en AWS.

  • Launch a DB Instance in Amazon RDS
  • Launch an Elastic Beanstalk Environment
  • Configure Security Settings and Environment Properties
  • Configure and Deploy the Application
  • Install Drupal
  • Update Drupal Configuration and Remove Access Restrictions
  • Cleanup
  • Enable Elastic Beanstalk Command Line Interface (EB CLI)
  • Install needed PHP modules
  • Configure custom domain name
  • Enable https

Drupal on Beanstalk

Having an application working as a PaaS on Elasticbeans need a small change in the usual maintenance procedures. In fact, with Elasticbeans every time you need to upgrade the application- in this case Drupal- you have two main possibilities:

  • create and upload to the Elastic Beanstalk console a zip file with the needed fixes.
  • use the command line (EB CLI) for creating, configuring, and deploying.

Since of the skillset of our team, we went for the latest option.

The results


Drupal portal is running smooth since it has been provided as PaaS.

Scalability and stability

Customer is not facing anymore the issue they use to have with peak of access, since the service is autoscaled. The portal is stable and the infrastructure limitations are not an issue anymore! 


The whole infrastructure is totally safe thanks to the AWS security standards. Access roles are well defined and the policies are restrictive but flexibles. Of course, as best practices, Drupal must be updated constantly according to its security fixes.

Focus on Drupal

Now the customer is free to focus on the development of new features for its internal portal forgetting about infrastructure limitations.