Azure vs AWS

Azure vs AWS

ReportMate has two published Terraform modules. This page compares what each actually deploys, based on the code in both repositories, so you can pick one knowingly.

Short answer: the Azure module is the more complete and more actively maintained path. The AWS module is a clean, readable, feature-comparable re-implementation, but it is newer, has far less history behind it, and leaves several things to you that the Azure module automates.

Service mapping

Concern	Azure module	AWS module
Compute	Container Apps (2 apps) in a Container Apps Environment, plus an optional Function App (enable_functions) for scheduled alert functions	ECS Fargate (2 services) in an ECS cluster
Database	PostgreSQL Flexible Server, plus a database, a server configuration, and firewall rules	RDS PostgreSQL 16 in private subnets
Registry	Azure Container Registry	ECR (2 repos, plus maintenance and demo-loop)
Ingress / edge	Front Door profile, endpoint, origin group, origin, route, rule set, custom domain	Application Load Balancer only
Secrets	Key Vault with ~30 secrets, an access policy, and role assignments	Secrets Manager with 8 secrets
Identity	User-assigned managed identity plus 10 role assignments	Two IAM roles with narrow inline policies
Auth	Entra ID app registrations, service principals, app role assignments, delegated permission grants, pre-authorized apps	Cognito user pool, hosted UI, app client, two groups
Real-time	none	API Gateway v2 WebSocket API
Queue / storage	Storage accounts, blob containers, a queue, a table	S3 bucket, SQS queue + DLQ
Monitoring	Log Analytics workspace + Application Insights	CloudWatch log groups + SNS
Scheduled maintenance	Container App Job, with the cleanup script and Dockerfile in-repo	Fargate task on EventBridge Scheduler, image not in-repo
Cost guardrails	none in the module	AWS Budget, NAT egress alarm, VPC Flow Logs

What the Azure module has that the AWS one does not

• Database schemas and migrations. schemas/ carries the initial schema plus a numbered migration series and runner scripts. The AWS module creates an empty database and expects you to migrate it yourself.
• Edge and custom domain. Front Door with a custom domain is fully declared. On AWS, enable_custom_domain and domain_name are declared but wired to nothing — there is no CloudFront, ACM, or Route 53 resource in the repo. You bring your own certificate ARN and DNS.
• Full identity automation. The Azure module creates the app registrations, service principals, credentials, and role assignments that make SSO work end to end. On AWS you get a Cognito pool and two empty groups, and the dashboard has no Cognito provider, so sign-in has to be wired up by hand (see Getting-Started).
• The maintenance container itself. Azure ships db-cleanup.py, a Dockerfile, and requirements.txt next to the Terraform. AWS creates an ECR repository and a task definition pointing at :latest in it, and leaves the image to you.
• Bundled documentation and operational scripts — a wiki/ directory, deployment guides, database management scripts, and pipeline definitions.
• Maturity. The Azure repo has dozens of merged pull requests; the AWS repo has three.

By raw size: Azure is roughly 4,950 lines of Terraform with about 263 variable declarations across root and submodules; AWS is roughly 3,050 lines with about 134.

What the AWS module does better

• It is far easier to read. Eleven small submodules, one clear wiring file, no null_resource shell-outs, no time_sleep workarounds. The Azure module uses three null_resource blocks and a time_sleep; the AWS module uses neither.
• Cost visibility is built in. Flow logs, a per-NAT egress alarm, and a daily budget are declared in the module. The Azure module has no equivalent.
• Explicit HA and egress trade-offs. db_multi_az, enable_multi_az_nat, and enable_vpc_endpoints are first-class switches with the cost consequence stated in the variable description.
• Tighter least privilege in places. The ECS execution role's secret access is scoped to exactly the eight secret ARNs in use, rather than a broad Key Vault access policy.
• No hardcoded tenant. Neither module hardcodes an account or subscription, but the AWS one has no tenant-shaped configuration to leak in the first place.

Rough parity

Both deploy the same application: a FastAPI backend and a Next.js frontend against PostgreSQL, with a secret store, a container registry, an ingest queue, and daily database maintenance. Only the AWS module adds a WebSocket API. Both require you to build and push the container images separately. Both default their database to a small instance and expect you to size up.

Picking one

Choose Azure if you want the shortest path to a working, SSO-integrated deployment with the schema already handled, or if your organization is already on Entra ID.

Choose AWS if you are already an AWS shop, want infrastructure you can read in an afternoon, or care about the cost instrumentation. Budget time for the gaps: database migrations, TLS and DNS in front of the ALB, dashboard sign-in, and the maintenance container image.