Install AcelleMail on AWS EC2

AWS EC2 is the right host for AcelleMail when (a) you already operate other workloads on AWS and want to consolidate, (b) you want SES to be on the same network plane as the AcelleMail droplet for sub-millisecond API call latency, or (c) your compliance regime requires a specific AWS region or VPC posture. The trade-off versus DigitalOcean: more flexibility, more dials, more bills to read.

This guide is the AWS-specific overlay on the Ubuntu 24.04 install. It covers the AWS service choices and the egress + port-25 quirks that are unique to AWS; the actual install commands match the bare-metal walkthrough.

Step 1 — Instance type#

t3 is the burstable family — perfectly fine for AcelleMail at Hobby/Small tier where the workload is bursty (campaign blast, then idle). At Medium tier and up, switch to non-burstable m6i so a sustained worker push doesn't exhaust CPU credits.

Reserved Instances cut the bill by ~35-40 % with no operational change. For any production workload running > 6 months, this is free money. The "no upfront" payment option lets you cancel mid-term with no penalty.

Spot Instances cut another ~70 % but expose you to 2-minute eviction warnings. For AcelleMail's workload, spot is reasonable for queue worker fleets (jobs are retryable; eviction loses at most one in-flight job) but not for the primary application instance — you don't want the admin UI to disappear mid-session.

Step 2 — EBS volume#

Use gp3 (general-purpose SSD) for the root volume. gp3 is faster and cheaper than gp2 (the older default), with explicit IOPS + throughput dials independent of size.

For AcelleMail at Small tier:

• Size: 50 GB. Logs + the acellemail-latest.zip + DB grow surprisingly fast under heavy campaign volume.
• IOPS: 3,000 (gp3 baseline; free).
• Throughput: 125 MB/s (gp3 baseline; free).

For Medium tier and above with the database co-located, bump IOPS to 5,000-8,000 (paid). Or split the DB to RDS, which is cleaner.

Enable EBS snapshots as your droplet-level backup — schedule via Data Lifecycle Manager (free) for daily snapshots with 14-day retention.

Step 3 — Security Group#

Create a SG with these rules:

For an extra layer, attach AWS Systems Manager Session Manager instead of opening port 22 — you can SSH via the AWS console without any inbound rule.

Step 4 — Elastic IP#

Allocate an Elastic IP (EIP) and associate it with the EC2 instance before pointing DNS at it. Same logic as DO's Reserved IP — when you rebuild or migrate, the IP reassigns to the new instance with no DNS change.

Cost note: an attached EIP is free; an unattached EIP is $3.65/month. Always associate before allocating, and release immediately when you tear down an instance.

Step 5 — RDS for MySQL (optional, recommended at Medium+)#

RDS → Create Database
  Engine: MySQL 8.0
  Template: Production (Multi-AZ for HA) or Dev/Test (single AZ for cost)
  Instance: db.t3.micro (Hobby) → db.m6i.large (Medium+)
  Storage: 20 GB gp3, autoscaling enabled
  VPC: same VPC as EC2; subnet group spanning ≥ 2 AZs
  Public access: NO
  Security group: allow 3306 from EC2 SG only

Pick "Automated backups: 7 days" (free), "Multi-AZ: yes" for production HA (doubles cost but adds failover replica).

The connection string from RDS plugs into the AcelleMail web installer in place of localhost/acellemail.

Step 6 — The actual install#

Follow the Ubuntu 24.04 install guide. SSH in (or use Session Manager), then run Steps 1-10. If you went RDS, skip MySQL on EC2.

For certbot on AWS, the standard --nginx plugin works on port 80, but if your SG blocks port 80 inbound (corporate policy), use the DNS challenge plugin against Route 53:

sudo apt install -y python3-certbot-dns-route53
sudo certbot certonly --dns-route53 -d mail.example.com \
  --non-interactive --agree-tos --email you@example.com

This requires the EC2 instance role to have route53:GetChange + route53:ChangeResourceRecordSets permissions on the relevant hosted zone.

Step 7 — SES integration#

AcelleMail's Amazon SES driver is the obvious sending choice when running on AWS — same network plane, no public-internet hop. The setup:

1. Verify your sending domain in SES in the same region as your EC2 (e.g. us-east-1).
2. Move out of SES sandbox — file a support ticket with your sending pattern + use case. Amazon usually grants production access within 24 hours for legitimate use.
3. Create an IAM user with AmazonSESFullAccess (or scoped policy with just ses:SendRawEmail). Generate access key + secret.
4. In AcelleMail Admin → Sending Servers → New → Amazon SES, paste credentials + region.
5. Set sending quota matching your SES sandbox-out limit (start at 200/day, ramp per IP warmup schedule).

Port 25 on AWS#

AWS blocks outbound port 25 by default on every EC2 instance. Unlike DO, AWS rarely grants requests to unblock — the policy is to use SES instead. For 99 % of AcelleMail users this is fine; SES via API speaks HTTPS on port 443 and never touches port 25.

If you have a hard requirement to send via outbound SMTP from EC2 (e.g., on-premises mail relay integration), file an AWS port-25 unblock request — it's an EC2 limit-increase request, not impossible but slow.

Egress cost — the AWS gotcha#

EC2 egress to the public internet costs $0.09/GB in us-east-1 (cheaper in some regions, more expensive in others). AcelleMail itself is light on outbound traffic — the heavy egress is to the sending API.

When you use SES in the same region, traffic stays inside AWS's network and is free (private IP path). If you use Mailgun/SendGrid/etc. (external sending APIs), every email's body + headers go out as egress — a 50 KB email sent 100k times is 5 GB / month / $0.45 in egress. Not big, but it adds up at scale.

Rule of thumb on AWS: use SES, not external sending APIs, unless you have a specific reason. The cost + latency advantage compounds with volume.

Step 8 — CloudWatch + alerts#

CloudWatch Agent installs free; configure metrics + log shipping:

sudo apt install -y collectd
wget https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i amazon-cloudwatch-agent.deb
# Use the wizard: sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

CloudWatch Alarms — set the standard four:

• CPU > 80 % for 5 min
• Memory > 90 % for 5 min (custom metric, requires CloudWatch agent)
• Disk > 85 %
• Estimated charges > $X/month (billing alarm — single best AWS guardrail)

Cost worked example — Small tier production#

Cheaper than DigitalOcean for the same workload only after you commit to a 1-year Reserved Instance. On-demand AWS is more expensive than DO; on a 1-year RI it's competitive. On a 3-year RI, AWS wins outright.

Related reading#

• Install AcelleMail on Ubuntu 24.04 LTS — actual install steps
• Configuring Amazon SES with AcelleMail — sending integration
• SES sending limits cookbook — quota management
• Server Requirements and Hosting Options — sizing
• Post-install hardening checklist — security follow-up
• Scaling AcelleMail for 100k emails per day — when to upgrade

FAQ#

What about ECS / Fargate / EKS?#

Same architecture as the Docker guide. Use ECS Fargate for serverless containers + EFS for the AcelleMail code volume; or EKS if you already operate Kubernetes. Both work; both are noticeably more complex than EC2 + EBS for a single-instance workload.

Should I use Lightsail instead?#

Lightsail is EC2 + RDS + Load Balancer + bundled egress at a flat monthly price. Easier billing, less flexibility. Reasonable for hobby and small production; outgrown at Medium tier when you start needing IAM-scoped policies and VPC controls. The install steps are identical to EC2.

What region should I pick?#

Match your audience and your SES region. SES is region-aware; sending from us-east-1 to a us-east-1 SES endpoint is the lowest-latency, lowest-cost path. If your audience is EU, use eu-west-1 for both EC2 and SES. Don't cross regions unless you have a specific reason.

Can I scale to multiple AZs?#

For a single-instance AcelleMail, you don't need to. Single AZ + EBS snapshots + IAM-controlled rebuild is sufficient HA for sending workloads (a 4-hour outage is annoying, not catastrophic). Multi-AZ kicks in at XL tier with multiple application instances behind an ALB — see the scaling guide.