This Linux Apache MariaDB (LAM) instance is in the cloud on Amazon Web Services (AWS) servers. I currently run in the Oregon (US West 2 region) which is one of the cheapest regions for AWS pricing. The inclusion of support for the Perl, Python and PHP application programming languages makes this a LAMP model web service software stack instance.
The LAM AWS server instance was created to host my public named host websites and be a backup of the mediawiki installation and home grown perl database web interface on the secure side of my main server. These utilize a MariaDB server on the same machine. The server is also used as an ssh proxy for browsing the web.
This server instance is now running on a t3.nano instance under a no upfront cost 36 month reservation. The rate is less than $1.50 / month. This is a considerable savings over the On Demand $0.0052 per Linux t3.nano Instance Hour = $3.796 / Month ($0.0052*24*365/12) - $45.552 / Year pricing. The t3.nano instance 36 month reservation covers 1 EC2 instance but does not include any EC2 EBS storage which is required for the Ubuntu Server image used for the Operating System. I pay $0.80 for 8 GB-Mo of General Purpose SSD (gp2) which is the standard configuration for the Latest Ubuntu Server image. I pay $0.10 for 0.300 GB-Mo of storage on the AWS Elastic File System (EFS) at the USD $0.30 per GB-Mo for Standard storage (USW2) rate. The AWS EFS storage is among the most expensive but it is extremely convenient to have a persistent parallel file system that can be mounted with the Linux nfs4 package available during the Instance Initialization. I pay $4.00 / month for an additional 42 GB-Mo of General Purpose SSD (gp2) for the volume to mirror the /Zz directory.
The LAM AWS server instance was designed to utilize a t2.micro EC2 instance which is part of the AWS Free Tier offering. That offering includes 750 Hours / month of a t2.micro Elastic Compute Cloud (EC2) instance which is enough to run one instance 24/7. The instance could scale up by using a larger and more capable server and other options or scale down to a t3.nano or other server sizes cheaper than a t2.micro except under the (AWS) Free Tier offering. Multiple groups of virtual hosts can all run on one server or a separate server can be used for each group or single host. Once the Free Tier was over the t2.micro server was found to cost less than $12.00 / month with the initial sizing and usage On Demand and less than $4.00 / month using a t3.nano EC2 instance reserved prepaid for 3 years. A t3.nano is even less expensive and passed testing supporting the web and proxy services by being my cloud host after t2.micro hours got more expensive. The server is mostly idle although memory usage runs at 75% on a t3.nano and nearly 50% on a t2.micro.
A single LAM AWS server instance can host multiple websites, including a secure website, with Apache2 on Linux and includes MariaDB, Perl, Python, PHP and other common development tools. Additional packages installed support running MediaWiki and more. The LAM AWS server is built on the latest Ubuntu Server Amazon Machine Image (AMI) with an EBS General Purpose (SSD) Volume. The resulting image is similar enough to the Linux Mint distribution I use on the newer machines at home and on my laptop so that cloning my MediaWiki and lam databases from the main server to either an aws instance or Linux Mint machine can be done with the same procedure.
On Ubuntu (and Linux Mint) the awscli package includes the aws command which includes the ability to launch a new instance.
aws ec2 run-instances --count 1 --image-id ami-0ee8244746ec5d6d4 \ --instance-type t3.nano --security-group-ids sg-3bda0647 \ --associate-public-ip-address --key-name aws-nwo-lam1 --user-data \ file:///var/www/aws/aws-nwo-lam1-Ubuntu-CloudInit.txt
The LAM AWS server is initialized with Ubuntu CloudInit directives to install the necessary packages, configuration and content on top of a generic Ubuntu Server image. All the directives in a file can be specified with the CLI user-data parameter or in Advanced Options of the launch page from the AWS web console. The directives can also be pasted into the text box when using the web console. The Ubuntu CloudInit package is a great tool for AWS EC2 initialization and is another reason to use an Ubuntu Server ami rather than one of the other available types.
The main initialization directives update the Ubuntu server to support all the virtual hosts of the LAM AWS cloud and automatically assume the lam1 domain subset of hosts. Additional Dynamic Domain Name Service#Check-in from a Linux host operations can be performed to take over more or all of the lam1 domain subsets.
Port 443 is normally used for HTTPS so is likely to be available even when other ports are blocked. I run this instance only when I find my ssh access blocked when using someone else's WiFi such as from the laptop at a hotel or for testing.
aws ec2 run-instances --count 1 --image-id ami-0ee8244746ec5d6d4 \ --instance-type t3.nano --security-group-ids sg-3bda0647 \ --associate-public-ip-address --key-name aws-nwo-lam1 --user-data \ file:///var/www/aws/aws-nwo-lam2-Ubuntu-CloudInit.txt
This instance runs on Amazon Linux 2 rather than Ubuntu Server. There are a number of package differences and differences in Apache2 configuration. With the addition of EPEL and amazon-linux-extras repositories it supports being a LAM Alaska clone including the MediaWiki and other functions served by https.
aws ec2 run-instances --count 1 --image-id ami-0ca285d4c2cda3300 \
--instance-type t3.nano --security-group-ids sg-3bda0647 --tag-specifications \
'ResourceType=instance,Tags=[{Key=Name,Value=aws-lam2-Amazon-Linux-2}]' \
--associate-public-ip-address --key-name aws-nwo-lam1 --user-data \
file:///var/www/aws/aws-nwo-lam2-Amazon-Linux-2-CloudInit.txt
A volume in the AWS Elastic File System (EFS) in my default USA NW Oregon region is used as a NFS mounted parallel file system. The security group definition allows traffic on the port for this service only within the Virtual Private Cloud (VPC). The LAM AWS VPC has it's own private address space and each EC2 instance or an AWS Elastic File System resource gets an IP address within this space.
The security group definition controls the traffic within the Virtual Private Cloud and with the outside world. I use the same security group definition for both images with only a limited number of inbound ports open. The definition details are:
This security group definition allows web traffic on the standard ports from the public interface (0.0.0.0/0), Secure Shell on an alternate high numbered port and IMAPS on an alternate high numbered port. The security group definition allows Secure Shell on the standard port and NFS traffic only on the private interface (172.31.0.0/20). The SSH SOCKS5 Proxy instance uses the same security group definition but is accepting Secure Shell traffic on the port that is normally used for Secure Web (HTTPS) traffic. The security group definition does allow outgoing traffic from the server over the public interface.
An EFS directory is used by the Ubuntu CloudInit directives during initialization of my AWS EC2 instances. The nfs-common additional package is required to mount the persistent Amazon Web Services Elastic File System. Once the nfs-common package is installed the nfs4 mount can be implemented. Since an additional package is required the mount is performed within the runcmd section and cannot be run earlier in the bootcmd section. I also use the rcs package in the runcmd segment that mounts the EFS file system:
echo
echo Adding nfs4 mount to AWS NW-O VPC Elastic File System
mkdir /mnt/efs
chown ubuntu:ubuntu /mnt/efs
mkdir /etc/RCS
ci -l -t-"File System table for LAM AWS web and shell server" /etc/fstab
nfsOpt="nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0"
echo "fs-6f45fac6.efs.us-west-2.amazonaws.com:/ /mnt/efs nfs4 ${nfsOpt}" >> /etc/fstab
rcsdiff -U0 /etc/fstab
ci -l -m"Added nfs4 mount to AWS NW-O VPC Elastic File System" /etc/fstab
mount -a -t nfs4
The fs-6f45fac6 unique resource identifier is part of the virtual host name used to access the AWS Elastic File System (EFS) in my default USA NW Oregon region. One big advantage of using NFSv4 is that only one IP port, 2049, is used to run the service which simplifies controlling access.
A second EBS volume was created to hold a copy of my /Zz by Date data in 2020. This copy is synced daily with the main copy on my AK LAN main server as long as ak20 is available via ssh. I started a t3.large EC2 instance with 8GiB memory to handle the initial population from the most recent Zz*tgz backup. The t3.nano I normally run could not handle the initial population task but has no problem with the daily rsync jobs. The volume is currently 82% utilized and should have room for at least a couple of years of growth. The 40G of EBS costs an additional $4.00 a month and is available to only one EC2 instance.
A snapshot of this volume is created daily and retained for 15 days.
The LAM AWS server instance hosting my public named host websites and a backup of the secure side of my main server is designed to use a set of Ubuntu CloudInit directives and a small amount of data on top of the latest Ubuntu Server Amazon Machine Image (AMI) on the default launch image page. The initialization takes a few minutes but this means I don't have to pay for the storage of a custom AMI.
Daily backups to the persistent parallel file system are used for a new instance initialization so that it is current except for changes made to the main server within the last 24 hours.
New instance initialization includes a full upgrade so testing after the launch of a new image should show if any updates that have not been applied to the current main running instance cause problems.
The latest Ubuntu Server image is specified as a command line option for the "aws ec2 run-instances" command. A new image on the default launch image page is tested when it appears and usually can be substituted without any other changes to the new instance initialization. Some package changes required changes to the new instance initialization when I did the major upgrade to Ubuntu 18.04 from Ubuntu 16.04 but most simply shorten the full upgrade performed during the new instance initialization.
The Ubuntu CloudInit directives specified as user-data when launching a new instance are maintained in the two files linked to above.
A set of scripts on the persistent parallel file system are included in daily backups on the main server to keep the backups up to date. Any configuration file changes from package defaults must be included in the backups and or applied during the new instance initialization.
A daily source backup runs on the main server and backs up all RCS/*,v archives and the source but these backups are not applied during new instance initialization.
I have published some of the repos of the server configuration and the content in the html folder and an apache2 configuration for the websites to GitHub.