My main LAM AWS instance is a Dual stack (IPv4 and IPv6) web server, ssh proxy and ssh tunnel server. This main instance is currently required for a number of IPv6 workarounds I use to initialize an instance without a public IPv4 address. It is also used as an ssh proxy by my laptop, which currently does not have a public IPv6 address, for access to servers with only IPv6 connectivity. Since August of 2024 the main LAM AWS server instance provides access to my main git remote repo store.
This Linux Apache MariaDB (LAM) instance is in the cloud on Amazon Web Services (AWS) servers. I currently run my main instance 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.
I have been running an AWS EC2 instance continuously for over seven years now. For the first year I ran a t2.micro utilizing the 750 hours of the AWS Free Tier offering. After the first year I moved to the smaller, cheaper t3.nano EC2 instance first with an All Upfront 3 year reservation then with a No Upfront 3 year reservation. In 2023 I ran a t4g.small instance as part of another AWS Free Tier offering which showed me that the ARM instances along with the cheaper AWS pricing were worth consideration and led me to test and then decide on a t4g.nano All Upfront 3 year reservation for the instance to run the main aws site.
The main server instance is now running on a t4g.nano instance under an all upfront cost 36 month reservation. This prorates to less than $1.50 / month which is a considerable savings over the On Demand rate. The t4g.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 $1.00 for 10 GB-Mo of General Purpose SSD (gp2) which is 25% more than the standard configuration for the Latest Ubuntu Server image. I pay $0.30 for 1 GB-Mo of storage on the us-west-2 Oregon 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 $1.00 / month for storage on a One Zone EFS with Lifecycle Management for the mirror of the /Zz directory. I have an AWS EFS in all regions I can currently access but the storage is negligible (less than 150K) on every EFS except my main one in the us-west-2 Oregon region.
Since August of 2024 the aws.lam1.us instance is my main private git remote store. This was also when I made GitLab my main public git remote store. Both the aws.lam1.us instance and GitLab have dual stack IP access supporting both IPv4 and IPv6 protocols. With the proper ssh_config and credentials matching an authorized_keys entry for the git@aws user the following will work:
git clone git@aws:<repo>
The LAM AWS server instance was initially designed to utilize a t2.micro EC2 instance which is part of the AWS Free Tier offering starting in 2017. 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 can scale up by using a larger and more capable server and other options or scale down to a t4g.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 $2.00 / month using a t3.nano EC2 instance reserved prepaid for 3 years. The less expensive t3.nano and then t4g.nano instances were tested and found to support the web and proxy services by being my cloud host after t2.micro hours got more expensive than free. 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 multiple secure websites, 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.
In 2023 the LAM AWS VPC in the us-west-2 Oregon region was modified with an Amazon provided IPv6 CIDR block and the subnet for each availability zone allocated a subset of the block and configured to automatically assign an IPv6 address to a new instance interface. In 2024 the LAM AWS VPC was modified in all additional AWS regions and an EFS created and populated and the cloud-init process enhanced so that instances can be launched with or without a public IPv4 address on either x86 or ARM processor types with any of the latest Debian, Ubuntu or Amazon Linux operating system AMIs. As of 2024 the us-west-2d Oregon Availabilty Zone is where my main instance runs and is the only AWS instance that has the additional over 60 GB-Mo of One Zone EFS with Lifecycle Management storage to mirror the /Zz directory. The us-west-2 Oregon efs is the only one populated with the git repositories of the remote and all the initialization files. Until 2024 the us-west-2 Oregon region was the only one where I operated.
In 2024 I modified the web configuration so that my public named host websites default to https although I still support them with the http protocol. Before 2024 only the lam site with the mediawiki and other Private pages was served over the Secure extension of the Hypertext Transfer Protocol which originally used SSL encryption and now uses TLS encryption. I did this because I noticed my phone browser would default to the https protocol and made it more difficult for me to view the cabo.lam1.us/Weeks website and I decided I agree that all sites should be served over an encrypted protocol.
The index page for the aws site is now the default for both https and http requests to the server. My server uses Name-based Virtual Host Support for additional sites. I use Dynamic Domain Name Service hosts for test instances and CNAME entries to allow a server to take over a set of websites.
lamurakami.freeddns.org lam1.freeddns.org lam2.freeddns.org
lamurakami.duckdns.org lam1.duckdns.org larryforalaska.duckdns.org lam2.duckdns.org
I developed the aws site to display the IP Address and Domain Name of an AWS EC2 instance as well as the DDNS name the instance took over. An AWS EC2 instance gets a private IP address and hostname and optionally a public IP address and hostname. In 2017 when I began the public IR address was no additional charge for an AWS EC2 instance so I was always opting for it. In 2023 I modified my AWS EC2 VPC for dual stack when I became aware that AWS would start charging for a public IPv4 address so that I always get a public IPv6 address. For testing am now opting for an instance without a public IPv4 address most of the time. In 2024 I added a second DDNS set of hosts using Dynu free services that supports IPv6 and seems more reliable than DuckDNS which is not for productions sites.
During the cloud-init process this page is updated with the values of local-ipv4, local-hostname, public-ipv4, public-hostname, public_ipv6, instance-type, and availability-zone for the instance by the cloud-init.pl script. New values are reported by the ec2-user-data.pl script to update the index.html file which is the main page.
When I first developed this page and process it was addressing IPv4 communications only. At the current time and since it's inception as far as I know and AWS EC2 instance always gets a private IPv4 address and fully qualified hostname used for comunications to AWS resources. AWS can optionally provide a public IPv4 address and fully qualified hostname which is implemented through the NAT interface. Since 2024 when AWS started charging for the use of a public IPv4 address I have been opting out of this and relying on a public IPv6 address for communications over the internet. The default VPC AWS creates for a user in each region where they operate is configured for IPv4 only communications. I modified the VPC in each region to use IPv6 addresses within the Amazon provided /56 CIDR block I had allocated to my VPC for each region.
Most of the values come from the AWS EC2 metadata for the instance but the public IPv6 address is retrieved using the ip command. The index.html file for the main page holds the current values in comments as name value pairs as well as in the body as values displayed on the page. The cloud-init.pl script that performs the update uses the name value pairs in the index.html comments and the name value pairs that are the output of the ec2-user-data.pl and performs the update.
Use the cloud-init process to turn a generic Amazon Machine Image or QEMU disk image into a LAM Alaska clone. The cloud-init process works with Ubuntu, Debian, Amazon Linux, Fedora, SUSE and more operating systems and a cloud-config specification in YAML format can be passed as the user-data parameter of the "aws ec2 run-instances" command or the qemu command.
The user data for an EC2 instance has a 16k character limit. I work around this by including initialization scripts in git repositories that are loaded during initialization. Nearly half of size of my CloudInit.txt files are echo statements that end up in the cloud-init-output log. In many cases the echo is followed by a call to a script with parameters to perform the detailed initialization.
The LAM AWS user-data is a set of CloudInit directives section details the various CloudInit.txt files to perform initialization for a LAM Alaska Clone.
Since 2023 the main aws.lam1.us instance supports dual stack access via IPv4 and IPv6. It is the main workaround allowing the initialization of a LAM AWS instance without a public IPv4 address.
AWS started charging for a Public IPv4 Address in February of 2024. This doubled the cost of running one of it's smallest EC2 instances.
PublicIPv4='--no-associate-public-ip-address' # No Public IPv4 address PublicIPv4='--associate-public-ip-address' # Public IPv4 address costs $43.80/Year
In 2023, when I found out AWS would begin charging for each public IPv4 address, I enabled a default IPv6 address from the 2600:1f14:3d86:2c00::/56 CIDR block for EC2 instance launched in my us-west-2 AWS LAM VPC and modified the aws-web-anywhere-alt-ssh-port Security Group to allow for IPv6 traffic. Because the ISP I use in Alaska does not yet support IPv6 and I don't know that any are available I must continue to use a Public IPv4 address for my main LAM AWS VPC EC3 instance. I detailed the Amazon provided /56 IPv6 CIDR block for my VPC in each region in the Modify AWS VPC for IPv6 page I created.
I found that the public IPv4 addresses AWS optionally provided for an EC2 instance are implemented as NAT (Network Address Translation) at the gateway.
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 all EC2 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/16) or the IPv6 CIDR block for the VPC. 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 over either IPv4 or IPv6.
The us-west-2 Oregon has an additional Inbound SSH rule for each of the IPv6 CIDR blocks AWS assigned my VPC for each region. All of these Inbound SSH rules should be in every region but I skipped adding after the first four or five of the rules to the additional regions when originally configuring them in 2024 and 2025. I can get to and from every US region but would have to add entries to make an instance in another region be my main instance.
A separate EFS security group with just the 172.31.0.0/16 NFS for EFS inbound rule is attached to the interfaces for each Availability Zone in the region when creating the EFS for that region.
The default VPC for the AWS Region includes a default subnet in each Availability Zone providing up to 4,096 addresses per subnet, a few of which are reserved for AWS use. This gives the LAM AWS VPC it's own private address space (172.31.0.0/16) and each EC2 instance gets an IP address within this space. The default VPC in each AWS Region also includes an attached internet gateway, a route in the main route table that sends all traffic to the internet gateway, and DNS settings that automatically assign public DNS hostnames to instances with public IP addresses and enable DNS resolution through the Amazon-provided DNS server.
KEYPAIR=lam-arsc
Prior to my expansion into other regions I had let AWS create an aws-nwo-lam1 key pair and I used that to access instances launched in us-west-2 Oregon. Quickly I was adding the passphrase protected key pair I have been using on my laptops since working at ARSC to every cloud-init file. The AWS key pairs are managed in the EC2 area of the console and not the VPC area but they are only available in the region that they they are created or imported into. I decided to import my main key into all the regions which eliminates the need to use the key pair I had let Amazon create for me in 2017.
AWS shows the current region at the top of the control panel and the region is a drop down list within geographical groupings. For me the four regions of the United States are shown first.
REGION=us-west-2 # us-west-2 Oregon (sebnets a, b, c, d) my main region
SECURITY_GROUP=sg-3bda0647 # aws-web-anywhere-alt-ssh-port us-west-2 Oregon
Prior to February 2024 when AWS started charging for a public IPv4 address over and above the hourly charge for running the instance I had only started instances in the us-west-2 Oregon region. In February I created the Modify AWS VPC for IPv6 page and modified the AWS VPC defaults for a number of regions and activated all the regions that were not previously activated. One of the steps is to create a security group which is now a parameter of the aws ec2 run-instances command I use to launch an instance.
REGION=us-east-1 # us-east-1 N. Virginia (sebnets a, b, c, d, e, f) Partial One Zone EFS
SECURITY_GROUP=sg-03320ad0fec07ba77 # aws-web-anywhere us-east-1
REGION=us-east-2 # us-east-2 Ohio (sebnets a, c) SECURITY_GROUP=sg-0e742c1aadfffa653 # aws-web-anywhere us-east-2
REGION=us-west-1 # us-west-1 N. California (sebnets a, b, c) SECURITY_GROUP=sg-0b2cbef29ecc3ecd2 # aws-web-anywhere us-west-1
REGION=af-south-1 # af-south-1 Cape Town (sebnets a, b, c) No t3a.nano
SECURITY_GROUP=sg-018c1aae18c0e566b # aws-web-anywhere
REGION=ap-east-1 # ap-east-1 Hong Kong (subnets a, b, c) No t3a.nano
SECURITY_GROUP=sg-0b668965bee1e8119 # aws-web-anywhere
REGION=ap-south-2 # ap-south-2 Hyderabad (India) (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-0a5e33cec7b147f07 # aws-web-anywhere
REGION=ap-southeast-3 # ap-southeast-3 Jakarta (Indonesia) (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-06ef74b2b06ac0f64 # aws-web-anywhere
REGION=ap-southeast-5 # ap-southeast-5 Asia Pacific (Malaysia) (sebnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-08a513d15fdd89efb # aws-web-anywhere ap-southeast-5
REGION=ap-southeast-4 # ap-southeast-4 Melbourne (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-09f94b9a07c0f44c7 # aws-web-anywhere
REGION=ap-south-1 # ap-south-1 Mumbai (subnets a, b, c) SECURITY_GROUP=sg-02c9967bd1c51cd28 # aws-web-anywhere
REGION=ap-northeast-3 # ap-northeast-3 Osaka (subnets a, b, c) No t3a.nano
SECURITY_GROUP=sg-0e35405e1e8ef33bb # aws-web-anywhere
REGION=ap-northeast-2 # ap-northeast-2 Seoul (South Korea) (subnets a, b, c, d) most are only 3 Partial One Zone EFS
SECURITY_GROUP=sg-0b773851f304ba99a # aws-web-anywhere
REGION=ap-southeast-1 # ap-southeast-1 Singapore (subnets a, c, d) Partial One Zone EFS
SECURITY_GROUP=sg-01752ca41332e7564 # aws-web-anywhere
REGION=ap-southeast-2 # ap-southeast-2 Sydney (subnets a, b, c) SECURITY_GROUP=sg-0e1819221520221dd # aws-web-anywhere
REGION=ap-southeast-7 # ap-southeast-7 Asia Pacific (Thailand) (sebnets a, b, c) No One Zone EFS
SECURITY_GROUP=sg-0cde603dad5e20bdb # aws-web-anywhere
REGION=ap-northeast-1 # ap-northeast-1 Tokyo (Japan) (subnets a, c, d) Partial One Zone EFS
SECURITY_GROUP=sg-08a18afbbbf99c26e # aws-web-anywhere
REGION=ca-central-1 # ca-central-1 Canada (sebnets a, b, d) Partial One Zone EFS
SECURITY_GROUP=sg-0ef4fef22698bcd40 # aws-web-anywhere ca-central-1
REGION=ca-west-1 # ca-west-1 Calgary (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-0c6c9b55fc89bd275 # aws-web-anywhere
REGION=eu-central-1 # eu-central-1 Frankfurt (sebnets a, b, c) SECURITY_GROUP=sg-043484886d8ef0bc2 # aws-web-anywhere eu-central-1
REGION=eu-west-1 # eu-west-1 Ireland (sebnets a, b, c) SECURITY_GROUP=sg-0b96ad2c4a0c62d9f # aws-web-anywhere eu-west-1
REGION=eu-west-2 # eu-west-2 London (subnets a, b, c) Partial One Zone EFS
SECURITY_GROUP=sg-094710e95749e4318 # aws-web-anywhere
REGION=eu-south-1 # eu-south-1 Milan (Italy) (sebnets a, b, c) SECURITY_GROUP=sg-0a076e83dc883ad15 # aws-web-anywhere eu-south-1 Milan (Italy)
REGION=eu-west-3 # eu-west-3 Paris (subnets a, b, c) Partial One Zone EFS
SECURITY_GROUP=sg-06b1313e990e886e7 # aws-web-anywhere
REGION=eu-south-2 # eu-south-2 Spain (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-074d970a9038a9cac # aws-web-anywhere
REGION=eu-north-1 # Stockholm (sebnets a, b, c) No t3a.nano
SECURITY_GROUP=sg-0b924f3ad0746fb5e # aws-web-anywhere
REGION=eu-central-2 # eu-central-2 Zurich (Switzerland) (sebnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-0d7a0136e28817ffd # aws-web-anywhere
REGION=mx-central-1 # mx-central-1 Mexico (Central) (subnets a, b, c) No One Zone EFS
SECURITY_GROUP=sg-09a09b525ef94da64
REGION=me-south-1 # me-south-1 Bahrain (subnets a, b, c) No t3a.nano
SECURITY_GROUP=sg-026a4253f70941de7 # aws-web-anywhere
REGION=me-central-1 # me-central-1 United Arab Emirates (UAE) (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-07791babc4c684823 # aws-web-anywhere
REGION=il-central-1 # il-central-1 Tel Aviv (Israel) (subnets a, b, c) No One Zone EFS No t3a.nano SECURITY_GROUP=sg-03aa12578389c5a88 # aws-web-anywhere
REGION=sa-east-1 # sa-east-1 Sao Paulo (South America) (subnets a, b, c) SECURITY_GROUP=sg-0be16e2ef0697e8a7 # aws-web-anywhere
There are four regions I don't have access to. There are two government regions in the US that require a seprate GovCloud account and two regions in China that require a seprate China account. The two GovCloud regions are US-West and US-East and the two China regions are cn-north-1 China (Beijing) and cn-northwest-1 China (Ningxia). The above list is all the other AWS regions I know of and I have set up a LAM VPC in all with Dual Stack IP configuration and can launch an EC2 instance that initializes as a LAM Alaska Clone with access to the EFS for the region on either an x86 or ARM instance with Debian, Ubuntu or Amazon Linux as the operating system.
The aws/aws-efs-mount.bash script was created to mount the LAM aws-efs for the region the instance was launched in.
The EFS directory is used by the 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.
NFSv4 uses only one IP port, 2049, to run the service which simplifies controlling access.
In 2023 while investigating the internet via IPv4, IPv6 or a dual stack after learning AWS will start charging $43.80 per year for each public IPv4 address in use I found no way to have the EFS resource provisioned with IPv6 addresses. By default AWS creates a private IPv4 subnet for each availability zone within a region and automatically provisions resource names resolved by DNS to private IPv4 addresses within the subnets. This is all within the VPC (Virtual Private Cloud) created by default for you within a region where you deploy resources. I was able to modify my VPC for IPv6 but had to run dual stack EC2 instances to access the EFS. I learned that the public IPv4 addresses AWS can optionally provide for an EC2 instance are implemented as NAT (Network Address Translation) at the gateway.
In 2025 I created a One Zone EFS with Lifecycle Management (efs3) in every Availability Zone that supported it. I moved the /Zz by Date copy to the efs3 in the us-west-2d Availability Zone which will save 75% as long as the bulk of the storage remains in the Infrequent Access (IA) storage class. The /Zz by Date copy is the target of a daily rsync from ak20 and the source of a daily plocate.db update which does not cause a transition from the IA storage class back to the Standard storage class. The size in IA is 150% of what is was in Standard or on the EBS volume because of the 1/8 M (128 K) minimum file size charge AWS uses for the IA and Archive storage classes.
The persistent EBS volume created in 2020 was deleted after the /Zz by Date copy was replicated to the efs3 in the us-west-2d AZ. The EBS volume had been grown from 44G to 48G but the EFS does not have to be provisioned for a size. The daily snapshots of the Zz EBS were deleted and discontinued.
Check in to a Dynamic Domain Name Service for lam1 and lam2 test instances at the end of the cloud-init process.
In 2017 I started using DuckDNS which is a free dynamic DNS hosted on AWS. In 2023 I discovered IPv6 is only partially supported and I developed IPv6 workarounds. In 2024 I started seeing issues with DuckDNS servers causing timeouts for DNS requests. In 2025 I added Dynu as a free dynamic DNS provider that fully supports IPv6 and is not currently experiencing timeouts for DNS requests.
My by IP Address website is the main page of the aws git repository which was designed to show the local-hostname, local-ipv4, public-hostname, and public-ipv4 for the instance using AWS EC2 metadata values. It displays the https://lam1.freeddns.org https://lam2.freeddns.org https://lam1.duckdns.org and https://lam2.duckdns.org links along with the original AWS EC2 metadata values and the Public IPv6 Address added in 2023. One of the subdomains is used for DDNS with CNAME alias entries for my domain names.
A number of the command line options are specified by variables mostly dependent on the Operating System / Architecture / PublicIPv4 options and the values are detailed in the following sections.
I initially created CloudInit directives only for Ubuntu Server and only the x86-64 architecture. This was originally on x86-64 Ubuntu Server 16.04 LTS, then x86-64 Ubuntu 18.04 LTS, then x86-64 Ubuntu Server 20.04 LTS and x86-64 Ubuntu Server 22.04 LTS.
The first variant was the CloudInit directives to have ssh on port 443 instead of https allowing me to setup a SSH SOCKS5 Proxy server on port 443 in some environments such as on hotel / resort Wi-Fi. This variant does not support the secure site where Mediawiki and other MariaDB web applications live.
In 2022 After upgrading to x86-64 Ubuntu Server 22.04 LTS I created an x86-64 Amazon Linux 2 initialization.
In 2023 I created an x86-64 Amazon Linux 2023 initialization after it became available in March. I followed in 2023 with ARM Amazon Linux 2023, and ARM Ubuntu Server 22.04 LTS initialization scripts. I then added Debian 12 scripts for both x86-64 and ARM architectures.
In 2023 I added the PublicIPv4 option.
INSTANCE_TYPE=t4g.nano; # ARM 0.5 GiB 2 vCPU $0.0042 / hour = $0.1008 / day ~= $3.024 / month INSTANCE_TYPE=t3a.nano; # x86 0.5 GiB 2 vCPU $0.0047 / hour = $0.1128 / day ~= $3.384 / month INSTANCE_TYPE=t3.nano; # x86 0.5 GiB 2 vCPU $0.0052 / hour = $0.1248 / day ~= $3.74 / month INSTANCE_TYPE=t2.nano; # x86 0.5 GiB 1 vCPU $0.0058 / hour = $0.1392 / day ~= $4.176 / month INSTANCE_TYPE=t4g.micro; # ARM 1 GiB 2 vCPU $0.0084 / hour = $0.2016 / day ~= $6.048 / month INSTANCE_TYPE=t3a.micro; # x86 1 GiB 2 vCPU $0.0094 / hour = $0.2256 / day ~= $6.768 / month INSTANCE_TYPE=t3.micro; # x86 1 GiB 2 vCPU $0.0104 / hour = $0.2496 / day ~= $7.488 / month INSTANCE_TYPE=t2.micro; # x86 1 GiB 1 vCPU $0.0116 / hour = $0.2784 / day ~= $8.352 / month INSTANCE_TYPE=t4g.small; # ARM 2 GiB 2 vCPU $0.0168 / hour = $0.4032 / day ~= $12.096 / month INSTANCE_TYPE=t3a.small; # x86 2 GiB 2 vCPU $0.0188 / hour = $0.4512 / day ~= $13.536 / month INSTANCE_TYPE=t3.small; # x86 2 GiB 2 vCPU $0.0208 / hour = $0.4992 / day ~= $14.976 / month INSTANCE_TYPE=t4g.medium; # ARM 4 GiB 2 vCPU $0.0336 / hour = $0.8064 / day ~= $24.192 / month INSTANCE_TYPE=t3a.medium; # x86 4 GiB 2 vCPU $0.0376 / hour = $0.9024 / day ~= $27.072 / month INSTANCE_TYPE=t3.medium; # x86 4 GiB 2 vCPU $0.0416 / hour = $0.9984 / day ~= $29.952 / month INSTANCE_TYPE=t4g.large; # ARM 8 GiB 2 vCPU $0.0672 / hour = $1.6128 / day ~= $48.384 / month INSTANCE_TYPE=t3a.large; # x86 8 GiB 2 vCPU $0.0752 / hour = $1.8048 / day ~= $54.144 / month INSTANCE_TYPE=t3.large; # x86 8 GiB 2 vCPU $0.0832 / hour = $1.9968 / day ~= $59.904 / month
Each specific Initial AMI will only launch with a matching instance type Architecture.
Amazon Machine Image (AMI)s are available for a number of Operating System / Architecture configurations. A number of AMIs are supported and maintained by AWS, some provided by the AWS community and custom AMIs can be made. I could create a custom AMI but instead use a AWS provided AMI provided without additional charge and perform the initialization with the CloudInit directives. The initialization takes a few minutes but I avoid having to pay for the storage of the AMI as an EBS snapshot.
Each AMI is for a Region, Operating system, Architecture, and Storage for the root device. I have CloudInit directives for Ubuntu server 24.04, Ubuntu server 22.04, Debian 12, Amazon Linux 2023, and Amazon Linux 2 for both x86 and ARM Architectures.
In February of 2024 I started launching instances in other regions of AWS besides the us-west-2 Oregon region where I have been operating since 2017. Before launching an instance in a new region I Modify AWS VPC for IPv6 since my initial testing is about running an instance with a Public IPv6 address but without a Public IPv4 that AWS is now charging a ludicrous amount for starting this month. I was testing arm64 Ubuntu 22.04 LTS which had an issue with package management on instances without a Public IPv4 address and decided to see if it affected other images since there is a separate image for each region.
For Ubuntu I use the Ubuntu image locator for ec2 and search for arm64 or arm64 and the region to find the latest build for my testing. The rest of this section has cloud-init files for the us-west-2 Oregon region and are generally updated when new images appear in the Launch instances Quick Start section for selecting the AMI.
The AMI_RootDeviceName environment variable is used in the block device mapping parameter of the aws ec2 run-instances command to increase the default Root Device Volume Size. I am currently specifying 10 GB which is a 25% Increase over the default 8 GB of EBS storage for the root volume.
The following command describes an Amazon Machine image in a specific region:
aws ec2 describe-images --image-id ${AMI} --region ${REGION}
The AMI_RootDeviceName value should match that used in the AMI for the new Root Device Volume Size to be used. The following are values I have observed:
AMI_RootDeviceName='/dev/sda1' # Ubuntu Noble & SUSE AMI_RootDeviceName='/dev/xvda' # Other OS AMIs
If the AMI_RootDeviceName value does not match that used in the AMI the instance will still launch but the default 8G root device size will be used rather than the 10G value specified on the command line.
The LAM AWS server is initialized with CloudInit directives to install the necessary packages, configuration and content on top of a generic Server image. All the directives in a file can be specified with the 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 CloudInit package is a great tool for AWS EC2 initialization.
If launched with the Public IPv4 address option a lam1 instance can be used as the main LAM AWS instance.
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.
CLOUD_INIT=/var/www/aws/aws-lam1-Ubuntu-24-Noble-CloudInit.txt KEYNAME=lam1-Ubuntu-Noble-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
Must reboot before ssh on alternate ports works on Ubuntu 24.04 Noble Numbat!
CLOUD_INIT=/var/www/aws/aws-nwo-lam1-Ubuntu-Noble-CloudInit.txt KEYNAME=lam1-Ubuntu-Noble-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
lam1 Instance running Ubuntu 22.04 Jammy Jellyfish rather than Ubuntu 24.04 Noble Numbat
CLOUD_INIT=/var/www/aws/aws-lam1-Ubuntu-22-Jammy-CloudInit.txt KEYNAME=lam1-Ubuntu-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-nwo-lam1-Ubuntu-CloudInit.txt # Ubuntu 22.04 Jammy Jellyfish KEYNAME=lam1-Ubuntu-22-Jammy-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
This instance uses github as the source of public repositories which means it does not support initializing without a public IPv4 address. It does not require the EFS or my aws.lam1.us instance to be running.
CLOUD_INIT=/var/www/aws/aws-lam2-Ubuntu-CloudInit.txt
KEYNAME=lam2-Ubuntu-20-04-Focal-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
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.
PublicIPv4='--associate-public-ip-address' # Public IPv4 address costs $43.80/Year
I use the above for all the SSH SOCKS5 Proxy server on port 443 instances. I have always had IPv4 only access at a hotel or resort when I found Port 22 blocked. The two latest Ubuntu 24.04 Noble Numbat and Debian 12 CloudInit files can successfully launch an instance without a public IPv4 address.
CLOUD_INIT=/var/www/aws/aws-lam2-ssh443-Debian-CloudInit.txt KEYNAME=lam2-ssh443-Debian-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-lam2-ssh443-Ubuntu-24-Noble-CloudInit.txt KEYNAME=lam2-ssh443-Ubuntu-24-Noble-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
Must reboot before ssh on alternate ports works on Ubuntu 24.04 Noble Numbat!
CLOUD_INIT=/var/www/aws/aws-lam2-ssh443-Ubuntu-22-Jammy-CloudInit.txt # Ubuntu Server 22.04 Jammy Jellyfish KEYNAME=lam2-ssh443-Ubuntu-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
This instance uses github as the source of public repositories which means it does not support initializing without a public IPv4 address. It does not require the EFS or my aws.lam1.us instance to be running.
CLOUD_INIT=/var/www/aws/aws-lam2-ssh443-Amazon-Linux-2-CloudInit.txt KEYNAME=lam2-ssh443-AL2-x86-${REGION}${PublicIPv4}
Like in What is missing, this instance doesn't check in to a Dynamic Domain Name Service.
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.
CLOUD_INIT=/var/www/aws/aws-lam2-Amazon-Linux-2-CloudInit.txt KEYNAME=lam2-Amazon-Linux-2-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-nwo-lam2-Amazon-Linux-2-CloudInit.txt KEYNAME=lam2-Amazon-Linux-2-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-lam2-Amazon-Linux-2023-CloudInit.txt KEYNAME=lam2-AL2023-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-nwo-lam2-Amazon-Linux-2023-CloudInit.txt KEYNAME=lam2-AL2023-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-lam2-Debian-CloudInit.txt KEYNAME=lam2-Debian-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-nwo-lam2-Debian-CloudInit.txt KEYNAME=lam2-Debian-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
CLOUD_INIT=/var/www/aws/aws-lam2-SLES-CloudInit.txt KEYNAME=lam2-SUSE-${REGION}-${INSTANCE_TYPE}${PublicIPv4}
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} --region ${REGION} \
--block-device-mapping DeviceName=${AMI_RootDeviceName},Ebs={VolumeSize=10} \
--instance-type ${INSTANCE_TYPE} --security-group-ids ${SECURITY_GROUP} \
--tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=${KEYNAME}}]" \
--key-name ${KEYPAIR} ${PublicIPv4} --user-data file://${CLOUD_INIT}
This results in an instance using one of the http://lam1.lam1.us or http://lam2.lam1.us subdomains that is a LAM Alaska clone based on the latest daily backups.
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 CloudInit directives and a small amount of data on top of the latest 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 Amazon Machine 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 CloudInit directives specified as user-data when launching a new instance are maintained in the 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.
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 and GitLab.
Saturday, May 17, 2025 @ 1:45:43 AM
aws.ServerAdmin@LAMurakami.com