The t-series of EC2 VMs available from AWS, is a “burstable” series of VM. It isn’t intended for any high-CPU utilization for any longer than 1 sec. In fact, there is something called a CPU credit usage and CPU credit budget. When CPU credit budget is 0, your VM isn’t even reachable by network anymore. And at 100% CPU utilization, the credit goes from 100%(144 for t2.micro) to 0 in an hour or 2.

The t2.micro is fine for a low volume web server, but it is remarkably under-powered, low budget instance. It has 1 vCPU, and 1G of RAM. It sounds like plenty but it also has a concept of CPU credits (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html) which limits this further(https://stackoverflow.com/questions/28984106/what-is-cpu-credit-balance-in-ec2). Every hour it runs, add 6 credits, but every minute you use 100% uses 1 credit. So every hour, you get 6minutes of 100%, 12minutes of 50%, 24min of 25%, etc.

6 CPU Credits / hour
CPU credits spent per minute = Number of vCPUs * CPU utilization * 1 minute
Maximum of 144 CPU credits for t2.micro
144+6t-60t=0
t=144/54 = 2.66h at 100%CPU before all drained.

So if you plan to do any tasks that require the CPU, it will drain the CPU budget that you acrued during non-activity. Their thinking is that the ideal situation is 0, you use up as much as you accrue.
https://d1.awsstatic.com/whitepapers/t2-std-cpu-credits.pdf

And when the CPU budget is 0, then your EC2 instance can’t be reacheable by Cloudwatch, meaning those graphs in AWS portal for your machine no longer update.

At 100% CPU, SSH doesn’t even respond. https://repost.aws/questions/QUpATzdowSSu2NXp8zvGAHrA/ec2-instance-is-stuck-can-t-ssh-in-and-abnormal-cpu-network-utilisation

Update 10/24/2024

EFS/NFS volumes, Limiting Mysql to 256MB(0.45CPU) wp-php to 256M(0.35CPU) failed to even start, mysql keeps rebooting

EFS/NFS volumes, Limiting Mysql(0.45CPU) to 512MB wp-php(0.35CPU) to 128M failed to start import

EFS/NFS volumes, Limiting Mysql(0.45CPU) to 512MB wp-php(0.35CPU) to 256M
failed after 1500 records

Local volumes, Limiting Mysql(0.45CPU) to 512MB wp-php(0.35CPU) to 256M REGRESSED to
failed to start import

Each time the CPU goes up to 100%. kswap os the biggest culprit, meaning the t2.micro has run out of RAM.

The import process insists on making HTTP request of eveyrthing it imports, so if I use public IP, it might charge me $
– There might need to be a way to change the WP URL AND the imported data URL’s, after import!

I’m stuck trying to figure out a way to import wordpress data on a container on t2.micro. Next step is to bypass import and try to upload the Mysql and WordPress file straight into the NFS volumes. And hope only the strain of the import, causes the t2.micro to choke up and stall.

Update 10/30/2024

I didn’t think it would take so long, to re-visit this. But I had deleted old containers, with my sites imported. But the import process in wp-cli for a 25M WXL file, of about 300 posts, always chokes on a t2.micro.

But a modified way of getting a wordpress content to t2.micro, is to run the import script on one of your own beefier machines or VM with 2G of RAM or more. Afterward, 2 volumes are created, 1 for wp-php and 1 for mysql. Run “docker volume ls” then “docker volume inspect ” for each. Find the local path for each volume, and copy the contents of each in separate folders in t2.micro. Then copy the docker-compose .yaml file to the t2.micro. In t2.micro, just sure the volume paths in “docker-compose.yaml” point to where you copied the volume data into. Then run “docker-compose up -d”. WordPress actually runs quite well in t2.micro. The wp-cli application simply cannot import all that data for some reason.

Below is copy of docker-compose.yaml. I changed the docker-compose.yaml some more. I used AWS EFS storage as centralized NFS storage for the WordPress content, in 2 volume connected to 2 NFS shares. It is about 2G total. I get 5G free for 12mo in EFS, and only $0.10USD/mo more after that. 1mo of time on t2.micro is free.

version: '3.1'
services:
  wp_php:
    image: wordpress:latest
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_HOST: wp_mysql
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wp_site1
    volumes:
      - php:/var/www/html
    restart: unless-stopped
    networks:
      bridge:
        aliases:
          - wp_php
  wp_mysql:
    image: mysql:latest
    environment:
      MYSQL_DATABASE: wp_site1
      MYSQL_USER: wp
      MYSQL_PASSWORD: wordpress
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - mysql:/var/lib/mysql
    restart: unless-stopped
    networks:
      bridge:
        aliases:
          - wp_mysql
networks:
  bridge:
volumes:
  php:
    driver_opts:
      type: "nfs"
      o: "addr=fs-XXX0.efs.us-east-1.amazonaws.com,nolock,soft,nfsvers=4"
      device: ":/"
  mysql:
    driver_opts:
      type: "nfs"
      o: "addr=fs-XXX1.efs.us-east-1.amazonaws.com,nolock,soft,nfsvers=4"
      device: ":/"

Whoops. t2.micro is only free for 1st year
$0.0116 per On Demand Linux t2.micro Instance Hour 230 Hrs

And that initial data transfer will cost a little extra:
Amazon Elastic File System Elastic Throughput Data Access USD 1.23
USD $0.03 per GB for Elastic Throughput reads (USE1) 4.007 GB USD 0.12
USD $0.06 per GB for Elastic Throughput writes (USE1) 18.517 GB USD 1.11
Amazon Elastic File System Standard Storage Class USD 0.02
USD $0.30 per GB-Mo for Standard storage (USE1) 0.059 GB-Mo USD 0.02

Compare that to having large VM hard drive:
EBS USD 1.65
$0.00 for 347 Mbps per t3.medium instance-hour (or partial hour) 709 Hrs USD 0.00
$0.08 per GB-month of General Purpose (gp3) provisioned storage – US East (N. Virginia) 2.944 GB-Mo USD 0.24
$0.10 per GB-month of General Purpose SSD (gp2) provisioned storage – US East (Northern Virginia) 14.073 GB-Mo USD 1.41

It seems you only pay for what you use(EFS) vs reserve capacity(EBS) but EBS is cheaper per GB.