The EC2 provider is just a regular WordPress plugin – upload and activate it from the WordPress PLUGINS screen.
Connecting to EC2 and automatically creating servers requires a lot more moving parts to be synchronized than simpler providers such as DigitalOcean and Linode. In particular:
It is very important that all five of the above items be checked and double-checked before proceeding. Otherwise provisioning a server on EC2 WILL FAIL.
The AWS EC2 provider then needs connection and security information before it can be used. You can provide this information under WPCLOUD DEPLOY → SETTINGS → CLOUD PROVIDERS → AWS EC2. There are several steps to this process:
After the provider is installed and configured you’ll see it as an option when deploying a new server:
Servers are placed into EC2’s ‘default’ security group. There are times where this group BLOCKS incoming traffic – this will cause server deployments to fail since we’ll be unable to connect to it automatically. You should EDIT the default security group to ensure that traffic is allowed from your WordPress server where WPCD is installed. In particular, the SOURCE for incoming traffic is set to “custom” by default – you need to change this to “Anywhere” or specify the IP address of your WordPress server where WPCD is installed.
Alternatively, you can set it up so that only SSH, HTTP and HTTPS traffic are allowed in from all sources.
The basic EC2 provider can only be used in one region. In order to use it in multiple regions, you need to install the VIRTUAL PROVIDER add-on. Once that has been installed, you can create a virtual provider for each region – learn more in the Virtual Provider documentation.
If you do not see a region you expect in the region list, please check to make sure that you have opted into that region in your AWS console. AWS now has a nice global view summary that includes a column showing your opt-in status for a region: https://console.aws.amazon.com/ec2globalview/home#. We have noticed that locations such as Capetown, Milan, Bharain, Hong Kong and Jakarta are usually disabled in new accounts.
You should ensure that there is a default VPC and SECURITY GROUP for each additional region and that they are configured to allow for traffic on certain ports as mentioned in the Prerequisites For Using the AWS EC2 Provider section at the top of this page.
Many EC2 instances default their root device to only 8GB. For most single WP sites this does not pose an issue. But if you will install multiple sites on the device you will need to increase its size. This exercise requires some comfort level with the command line as well as familiarity with the AWS EC2 console!
Step 2 generally involves the use of the growpart and resize2fs commands which:
When you configure the EC2 provider, there is an option to enable IPv6. Before turning this on you must do the following:
If you do not do this, provisioning EC2 instances WILL fail. If you specify an incorrect or invalid IPv6 CIDR for the default VPC and SUBNET provisioning will fail.
This provider includes support for custom images – i.e.: custom AMIs.
You provide the AMI id in the CUSTOM SNAPSHOTS & IMAGES section of the provider settings area.
Please remember that the AMI must reside in the account and region you’re using. If you need to use the same custom AMI in a different region you will need to copy it to the target region which will give it a different AMI id.
Also, please review these very important notes about custom images.
Running a backup on an instance that is too small for the amount of data being backed up will cause the MariaDB server to stop. You will have to manually restart it. This seems to be a flaw in the EC2 instance.
So, if you intend to use our backup process on these instances please make sure you run a few backup tests before placing your site into production to make sure there are no issues.
If you do want to continue to use these instances without our backup process in place you can always use a plugin backup process such as Updraft Plus which does not tax the instance as much but takes far longer to complete.
Server Sync cannot be used on AWS servers – neither as source nor destination.
The function to copy a site to a new server will not work with AWS EC & Lightsail servers as targets.
When deleting a site, the option to also delete all local backups will not work on AWS servers.
If you’re not seeing a region in the region list dropdown then it’s likely that it has not been enabled for your AWS EC2 account. Many smaller regions are not automatically enabled for most accounts.
This provider includes experimental support for Gravitron instances. Gravitron is the brand name for Amazon’s custom ARM processors.
Depending on your use case, these instances can cost less to run compared to Intel and AMD processors – theoretically, the price/performance ratio is lower.
We have tested basic NGINX functionality such as deploying the server, sites and SSL. But have not certified 3rd party software such as MONIT and MALDET. Thus, this is not something you should run in production if you require 3rd party software support; but they might make good dev servers if you like playing on the bleeding edge of things.
They’re also great instances to use if all you are doing is creating sites that use just the basic WP functions without any of the advanced WPCD features. i.e.: Install Site, Enable/Disable SSL, Enable/Disable CACHE, Backup/Restore, Site Tweaks etc. Most anything that only uses PHP should work but anything that requires a binary (most 3rd party software) have not been certified.
Note that OpenLiteSpeed will not deploy on Gravitron instances – if you attempt to do this you will get weird errors.
Want to know which EC2 instance to use? Take a look at this document on Github that outlines all the various instance types and their differences.