Several years ago, Stanford’s Office of University Communications enlisted the help of University IT (UIT) to migrate its most critical websites — www.stanford.edu and emergency.stanford.edu — from on-campus web servers to a cloud solution using Amazon Web Services (AWS). The Stanford Homepage on AWS architecture is no longer in deployment, but it remains a viable example of an Infrastructure-as-a-Service (IaaS) cloud implementation blended with trusted on-premises solutions.
The system incorporated AWS servers from the provider’s three-location USWest region that responded dynamically, day or night, to fluctuations in visitor traffic hitting the University's main website from anywhere in the world. The model provided high availability and scalability: more machines when the load was high, fewer when low.
As the AWS servers functioned automatically in the cloud, the people at Stanford who manage the website content used an authoring and staging process that ran on Stanford systems — a process in which they had invested years of trust and mastery.
To link the on-premises and cloud systems, UIT built software that provided a straightforward interface for publishing content from the on-campus staging server to the AWS production servers. Overall, the AWS architecture was built with as little dependency as possible between Stanford preview resources and AWS.
Architecture of Stanford Homepage on AWS
AWS Resource Stack
| Resources | Purpose | Resource Name / Comments |
|---|---|---|
| AutoScalingGroups/LaunchConfiguration | High Availability | www-aws: min:3,max:15, desired:3 AMI: debian/customized AMI |
| CloudTrail | API audit trail | Audit where, who, when, what, effect |
| CloudWatch | Performance monitoring, alerts | E.g., Set alarms when CPU usage is over 80%, notify through SNS |
| EC2s | Compute machines | VMs for www web servers |
| Elastic Load Balancers | HA, load-balance | Route traffic to web servers to different zones, remove dead servers, provide high availability; also provide security: web servers only allow traffic from these ELBs. |
| IAM user/group/policies | Security control | API Key per user/application, specific policy |
| InstanceProfile/Policies | Role-based Access control | www-role: with policy to allow web servers to download homepage content from S3 bucket |
| Route 53 | DNS routing | www.stanford.edu: points to www ELB |
| S3 storage | Shared storage | Private bucket www-aws.stanford.edu: Configurations, www.stanford.edu page content |
| Security Group - ELB | Access control | Sg-84f615eb: allow public traffic on port 80, 443 |
| Security Group - Web Servers | Access control | Stanford-Web: allow 80,443 traffic from ELB (Sg-84f615eb), and campus network |
| SES | Simple Email Service | Need to send email alerts, notifications |
| SNS | Event notification | Combined with other services for event driven alerts |
| VPC | Private network for security | 172.31.0.0/16: non-routeable private IP (not to be confused with Stanford shadow network). You can create other private VPC in 10.x, 192.x range too. |
