4 Approaches to hosting SPAs with AWS

Choosing the right hosting strategy for your single-page application (SPA) on AWS can be overwhelming. With services ranging from simple object storage to fully managed container orchestration, AWS offers powerful options. We'll dive into how each works, their pros and cons, ease of rollback, and when each is the best fit.

S3 + CloudFront

Build your frontend and upload the static files to an S3 bucket. CloudFront is configured to distribute these assets globally, with support for SPA routing, custom error handling, and cache control. Builds can be versioned by directory (e.g. /v1.3.2/) and served by changing CloudFront origin settings or rewrites.

Pros:

• Low cost, scalable, and reliable.

• Global performance via CloudFront’s CDN.

• Easy rollbacks by switching directory paths or aliases.

• Full control over cache headers, security, and routing.

• Easily scriptable with CI tools.

Cons:

• Initial setup takes effort.

• Must handle deployments and cache invalidation yourself.

• No built-in CI/CD previews.

This approach is ideal for production-grade applications, especially in enterprise environments where performance, control, and cost optimization matter. It works well for static SPAs, marketing sites, or internal portals requiring strict cache policies, SPA routing, and versioning. Teams that prefer custom pipelines and infra-as-code love this model for its flexibility.

Amplify

Amplify Hosting is a fully managed CI/CD + hosting solution for frontend apps. Once your Git repository is connected, Amplify builds and deploys automatically on each commit. It includes global CDN, HTTPS, branch-based preview deployments, custom domain setup, and support for all major frontend frameworks. Amplify handles deployment infrastructure behind the scenes.

Pros:

• Very fast to get started.

• Built-in CI/CD with preview branches.

• Built-in HTTPS, SPA routing, and hosting via CDN.

• Good integration with other Amplify services.

Cons:

• Less control over infrastructure and caching behavior.

• Harder to integrate into custom versioning or rollback strategies.

• Preview builds and multiple branches can increase cost quickly.

Amplify is a great fit for startups, prototypes, MVPs, hackathons, or any project where speed, simplicity, and quick feedback matter. It’s excellent for smaller teams or solo developers who don’t want to manage infrastructure. It's also useful during early product development when CI/CD and preview environments offer high velocity.

ECS + EC2/Fargate

You package your frontend build into a Docker image (usually with NGINX to serve static files) and deploy it using ECS. With Fargate, AWS manages the compute; with EC2 launch type, you manage the servers. You define task definitions, services, and optionally use Application Load Balancers or CloudFront for distribution. You roll back by deploying an older Docker image or version-tagged container.

Pros:

• High control over web server behavior, headers, and routing logic.

• Suitable for containerized infrastructure alongside other services.

• Works well with CI/CD pipelines and infrastructure as code.

• Rollback is easy by re-deploying previous container versions.

Cons:

• Higher complexity — requires Docker knowledge and ECS familiarity.

• Not cost-efficient for purely static apps (more infra than needed).

• Slower to set up and deploy compared to Amplify or S3.

This approach is ideal for larger, containerized applications where frontend and backend are tightly integrated and deployed together. It's commonly used by teams with DevOps maturity, especially when using ECS for the backend and wanting unified infrastructure. It's a strong choice when advanced routing, custom headers, or NGINX tweaks are needed, but overkill for simple static SPAs.

EC2

This is a traditional approach where you provision one or more EC2 instances, configure an OS-level web server (like NGINX or Apache), and serve your built frontend app from the instance. You might set up an Elastic Load Balancer (ELB) or integrate with CloudFront for CDN support. Deployments typically involve copying build files via SSH or through automated CI/CD scripts.

Pros:

• Full control over the hosting environment (OS, web server config).

• Works well for legacy setups or when deep customization is needed.

• Easy to host multiple apps or custom backends on the same server.

Cons:

• High maintenance — must patch, scale, and monitor servers yourself.

• Slower deployments unless automation is set up.

• Can be costly and less efficient for static frontends.

Hosting SPAs on EC2 makes sense in legacy environments or when your team is already managing EC2 infrastructure and wants tight OS-level control. It’s also a fit for highly customized web servers or setups where containerization isn't yet adopted. However, for new projects, it’s generally recommended to prefer Fargate or static hosting models.