AWS hosting for public-sector workloads is rarely a question of whether to use AWS. By 2023, the procurement, compliance, and operational ecosystem around AWS had matured to the point where it was the default for most agency and institutional infrastructure decisions. The harder question is which architectural pattern fits the workload.
This post covers the four AWS hosting patterns that account for most public-sector deployments, when each one is appropriate, and what the operational discipline looks like for each.
Pattern 1: Static Site on S3 + CloudFront
The simplest pattern. The website is published as static files (HTML, CSS, JavaScript, images) to an S3 bucket. CloudFront serves the files from edge locations close to visitors. Route 53 handles DNS. AWS Certificate Manager provisions and rotates the TLS certificate. AWS WAF applies security rules at the edge.
This is the right pattern for institutional websites where the content is mostly published and rarely dynamic, including Cascade Website Hosting for higher education, government information sites that publish content reviewed by editors before going live, and marketing or campaign sites with minimal interactive functionality.
Operational characteristics. Effectively unlimited scale at the edge. CloudFront handles whatever traffic arrives. Origin (S3) costs are low and predictable. Security surface is minimal because there is no application server. Compliance posture is straightforward because the data plane is read-only.
When this pattern is wrong. When the site has substantial server-side logic (dynamic forms, search, session-based personalization, user authentication beyond basic). Static sites with heavy client-side JavaScript can simulate some of this but at the cost of browser performance and accessibility.
Pattern 2: PHP or Node Application on EC2 With Auto Scaling
The pattern for institutional Drupal, WordPress, or custom PHP applications. EC2 instances run the application. Application Load Balancer distributes traffic. Auto Scaling adds or removes instances based on demand. RDS handles the database. ElastiCache handles session storage. CloudFront sits in front for static asset delivery and edge caching.
This is the right pattern for managed Drupal hosting for government, institutional WordPress in regulated environments, and custom application workloads requiring server-side processing.
Operational characteristics. Predictable performance under load. Security surface includes the application server, which has to be patched and hardened continuously. Compliance posture requires explicit operational practices (patching cadence, log aggregation, access controls). Cost scales with traffic but is bounded by Auto Scaling limits.
When this pattern is wrong. When the workload is too small to justify the operational overhead of running EC2 (a small institutional blog might be better as static or serverless). When the workload would benefit from the full elastic posture of serverless (event-driven applications, infrequent invocation patterns).
Pattern 3: Containerized Application on ECS or EKS
The pattern for modernized institutional applications, headless CMS architectures, and microservice deployments. Containers run on ECS (the AWS-managed container orchestrator) or EKS (managed Kubernetes). Application Load Balancer routes traffic. Aurora or RDS handles persistent state. ElastiCache handles caching. CloudFront sits in front for the public surface.
This is the right pattern for institutions modernizing legacy applications, building new applications with microservice patterns, or deploying off-the-shelf software distributed as container images.
Operational characteristics. Better resource utilization than EC2 for variable workloads. Operational complexity is higher (container orchestration is a discipline). Compliance posture extends to the container image supply chain (image scanning, vulnerability monitoring, base image patching). Cost is competitive when the workload utilizes the orchestration efficiently.
When this pattern is wrong. When the team does not have container orchestration experience and the workload could be served more simply by EC2 or serverless. The overhead of running ECS or EKS for a small workload is real.
Pattern 4: Serverless on Lambda + API Gateway
The pattern for event-driven workloads, low-traffic APIs, and applications with bursty or unpredictable invocation patterns. Lambda runs the code. API Gateway provides the HTTP surface. DynamoDB or Aurora Serverless handles persistent state. S3 stores objects. CloudFront accelerates the surface.
This is the right pattern for backend integrations between institutional systems, low-volume APIs that serve occasional traffic but cannot afford idle infrastructure cost, and event-driven workflows triggered by scheduled jobs or upstream system events.
Operational characteristics. Pay per invocation, which makes idle workloads cost effectively zero. Cold start latency is real but mitigable with provisioned concurrency. Security surface is the smallest of any pattern because there are no servers to patch. Compliance posture is straightforward, with most controls inherited from the AWS managed services.
When this pattern is wrong. When the workload has steady, predictable traffic where Lambda's per-invocation pricing exceeds the cost of EC2 or containers. When the application has long-running operations (Lambda has hard execution time limits). When the team is not comfortable operating distributed systems with eventual consistency semantics.
Common Operational Disciplines Across Patterns
All four patterns share a baseline operational posture for public-sector workloads.
FedRAMP-aligned configuration. AWS GovCloud for federal workloads with FedRAMP High requirements. Commercial AWS regions for FedRAMP Moderate workloads with appropriate boundary controls. Either way, the agency inherits the cloud provider's compliance authorization for the underlying infrastructure.
Identity through institutional IAM. Workload access through AWS IAM with roles and policies tied to institutional identity providers. No long-lived access keys for human users. Service-to-service authentication through IAM roles or IAM Identity Center.
Logging and monitoring. CloudTrail for API audit, CloudWatch for metrics and application logs, AWS Config for configuration drift detection, GuardDuty for threat detection. Logs aggregated to a central account with retention policies that match compliance requirements.
Backup and disaster recovery. Automated backups with documented restoration procedures. Multi-AZ deployments at minimum, multi-region for higher-criticality workloads. Restoration tested at least quarterly, with logs retained as audit evidence.
Network security. VPC architecture with public and private subnets, security groups with explicit allow rules, no internet exposure on databases or internal services, AWS WAF on public-facing endpoints, AWS Shield for DDoS protection on critical workloads.
How to Pick the Right Pattern
The decision flow for public-sector workloads typically runs through four questions:
- Is the content mostly static and published-once? Pattern 1 (S3 + CloudFront).
- Does the workload require a traditional server-side application runtime? Pattern 2 (EC2 + Auto Scaling) or Pattern 3 (ECS/EKS).
- Is the workload event-driven or bursty? Pattern 4 (Lambda + API Gateway).
- Does compliance posture require AWS GovCloud? All patterns work in GovCloud, but the service surface is narrower than commercial regions.
For institutional websites specifically, pattern 1 covers the majority of higher-education marketing sites and government information sites. Pattern 2 covers Drupal and WordPress. Pattern 3 and 4 emerge as institutions modernize specific applications or build new digital services.
Frequently Asked Questions
Does AWS GovCloud support all four hosting patterns?
Yes. The four patterns work in GovCloud the same way they work in commercial regions. The service surface in GovCloud is narrower (some newer AWS services are not yet authorized in GovCloud), so workloads using bleeding-edge services may need to wait for GovCloud authorization.
What FedRAMP authorization level do these patterns inherit?
AWS commercial regions hold FedRAMP Moderate authorization. AWS GovCloud holds FedRAMP High authorization for the services within its boundary. The hosting pattern inherits the authorization level of the region it runs in. Application-level controls (NIST 800-53 controls assigned to the application or system) are the agency's responsibility regardless of region.
How does Cascade CMS fit into AWS hosting patterns?
Cascade publishes static files. The production hosting environment that receives Cascade's published output (the Cascade Website Hosting tier) typically uses Pattern 1 (S3 + CloudFront) when the published output is purely static, or Pattern 2 (EC2) when the institution has form-handling, search, or other dynamic functionality alongside the published content.
What is the typical cost difference between these patterns?
Pattern 1 (static) has the lowest unit cost and effectively unlimited scale. Pattern 4 (serverless) has the lowest cost for low-traffic workloads. Pattern 2 (EC2) has predictable cost that scales with provisioned capacity. Pattern 3 (containers) is competitive when the workload utilizes orchestration efficiently. The right comparison is total cost of ownership including operational overhead, not unit infrastructure cost.