GoPhish Cloud on AWS: Architecture, Hardening, and Your First Phishing Campaign

Most organizations approach phishing simulation as a checkbox exercise. They spin up a tool, send a generic credential-harvesting email, report a click rate, and call it done. That approach tells you almost nothing useful. A well-architected phishing simulation infrastructure on AWS changes what you can learn—and what you can prove to leadership about your organization's human-layer exposure.

GoPhish Cloud on AWS — Production Deployment Architecture

Why Cloud Infrastructure Changes the Simulation Game

On-premises phishing simulation platforms carry real operational drag. Dedicated hardware, static IPs that accumulate reputation history, manual certificate management, and maintenance windows that collide with campaign schedules are all friction points that erode the fidelity of your simulations. AWS eliminates most of this.

A GoPhish Cloud deployment on AWS lets you provision fresh infrastructure per engagement. Each campaign can originate from a different sending domain with a clean IP reputation, mimicking the actual tradecraft of external threat actors. Elastic IPs, Elastic Load Balancers, and Route 53 make it practical to rotate infrastructure without rebuilding from scratch.

The architecture that works in practice: GoPhish runs on an EC2 instance (t3.medium is typically sufficient), behind a reverse proxy that handles TLS termination. An AWS SES sending identity handles outbound mail with DKIM signing, and a separate Route 53 hosted zone manages your lure domain. The landing page assets live behind CloudFront if you need CDN distribution for high-volume campaigns. Keep GoPhish's admin listener strictly internal—it should never be reachable from the public internet.

Hardening Before You Send a Single Email

The GoPhish default installation is not production-ready. Before any campaign goes out, address these areas:

Change the default credentials immediately and disable the API if you are not using it programmatically. GoPhish's admin interface will log every action, but only if you have configured centralized logging to CloudWatch Logs or your SIEM before the campaign starts.

At the network layer, your security groups should be explicit. Port 80 and 443 open to 0.0.0.0/0 for the landing server is expected. Port 3333 (GoPhish admin) should be restricted to a known CIDR—ideally your VPN or bastion host. Nothing else.

DNS configuration matters more than most practitioners realize. A missing or incorrect SPF record will cause your simulated phishing email to land in spam, not the inbox—and a campaign that bounces to spam is a campaign that measured your mail filters, not your people. Set SPF, DKIM via SES, and DMARC at minimum. Test deliverability against your target environment before launch.

Certificate management should be automated. Use ACM for CloudFront-fronted landing pages, and Let's Encrypt with Certbot for the EC2-hosted listener. A self-signed certificate on a landing page is a tell—it degrades the realism of the simulation and trains users to look for the wrong indicators.

Structuring Your First Campaign

The temptation with a new simulation platform is to immediately run the most sophisticated attack scenario you can design. Resist it. Your first campaign should establish a baseline, not prove a point.

Choose a pretexting scenario that reflects a genuine threat to your organization. For financial services, invoice fraud lures consistently outperform generic IT helpdesk themes. For healthcare, patient portal and EHR access prompts perform well. Generic "your password is expiring" lures are so overused that they primarily measure whether employees recognize a simulation rather than whether they would fall for a real attack.

Segment your target list by business unit or role from the beginning. Aggregate click rates obscure the signal. A 22% organization-wide click rate may conceal a 60% rate in one department and 3% in another. You cannot build a targeted training program from aggregate data.

Configure conversion tracking properly. GoPhish tracks email opens, link clicks, and submitted credentials as separate events. Map each event to your reporting schema before the campaign launches. Post-campaign, link your results back to HR data to correlate susceptibility with tenure, role type, and prior security training completion. That correlation is where the actionable insight lives.

Operationalizing the Infrastructure

The goal is not a single campaign—it is a repeatable simulation program with measurable trajectory. Automate teardown of campaign infrastructure after each engagement cycle to avoid IP reputation accumulation. Use AWS infrastructure-as-code (Terraform or CloudFormation) to make rebuilding a repeatable, low-effort operation.

Tag all resources for the simulation program in AWS Cost Explorer from day one. Phishing simulation infrastructure on AWS is inexpensive when properly sized, but untagged resources have a way of persisting and accumulating cost. A well-run program should cost less than two hours of a security engineer's time per month in cloud compute.

Log everything. GoPhish generates campaign event data in its database, but exporting that data to S3 or a data warehouse before teardown ensures you have longitudinal records to demonstrate program improvement to leadership.

A phishing simulation program that runs on disciplined infrastructure, measures the right things, and feeds results back into targeted training is one of the highest-ROI investments a security team can make in the human layer of their defense.