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:
| Service | Quantity | Description |
| AWS Elastic Beanstalk | 2 | Elastic Bean PHP for live Elastic Bean PHP for staging |
| Amazon EC2 | 3 | 2 web servers on T2.Medium instances for live 1 web server on T2.Medium instance for staging |
| Amazon RDS | 2 | Multi 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 Balancer | 1 | High availability for production (estimating 50 GBs per month) |
| Amazon Elastic File System | 2 | 50 Gbs for live 50 Gbs for staging |
| Autoscaling | 1 | Autoscaling service |
Activities
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
Application
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!
Security
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.
CEO at Orienteed.
