AWS Deployment Workflow Demo

Architecture

A user opens a web browser and requests one of two hostnames. The two requests take entirely different paths through the system.

Static path (www.example.com)

The browser resolves www.example.com to an Amazon CloudFront Distribution. CloudFront serves cached static website content (HTML/JS/CSS) at the edge. On a cache miss, CloudFront fetches the object from its origin, an Amazon S3 bucket that holds the static website assets. This gives the front-end global distribution and edge caching without running any servers.

Dynamic path (https://api.example.com)

The browser calls https://api.example.com, which resolves to Amazon API Gateway. API Gateway is the single managed entry point for all dynamic requests. It invokes AWS Lambda Functions (the business-logic tier) via native Lambda proxy integration over HTTPS. The Lambda functions run inside a VPC so they can reach VPC-scoped data stores.

From Lambda, requests fan out to the data tier depending on the operation:

• Amazon DynamoDB — the primary NoSQL key/value store, reached over the AWS DynamoDB API (via a VPC endpoint or the AWS network).
• Amazon RDS — a relational database inside the VPC for structured/transactional data.
• Amazon ElastiCache — an in-memory cache inside the VPC, used by Lambda to serve hot reads quickly and reduce load on RDS/DynamoDB.
• Amazon S3 (a second, application-data bucket, distinct from the static-site bucket) — Lambda writes/reads application objects here. The padlock icon in the diagram indicates this S3 access is over an encrypted/secured channel (SSE + TLS, typically via an S3 VPC gateway endpoint).

So the overall flow is: browser → (CloudFront → S3 static) for the site shell, and browser → API Gateway → Lambda (in VPC) → {DynamoDB, RDS, ElastiCache, S3} for all live data operations. The static and dynamic paths never cross; they share only the browser as a common client.

AWS Components

• Amazon CloudFront — CDN that caches and serves static website content globally at the edge for www.example.com.
• Amazon S3 (static bucket) — origin store for static website assets (HTML/JS/CSS).
• Amazon API Gateway — HTTPS entry point for dynamic requests at api.example.com; proxies to Lambda.
• AWS Lambda — serverless business-logic tier; runs inside the VPC and fans out to data stores.
• Amazon DynamoDB — NoSQL key/value store for primary application data.
• Amazon RDS — relational database inside the VPC for transactional/structured data.
• Amazon ElastiCache — in-memory cache inside the VPC for hot reads.
• Amazon S3 (app-data bucket) — secured object storage for application data written/read by Lambda.
• Amazon VPC — network boundary containing Lambda, RDS, and ElastiCache.

IAM Permissions Required

cloudformation:*
s3:*
cloudfront:*
apigateway:*
lambda:*
dynamodb:*
rds:*
elasticache:*
ec2:CreateVpc, ec2:CreateSubnet, ec2:CreateSecurityGroup,
ec2:AuthorizeSecurityGroupIngress, ec2:CreateVpcEndpoint,
ec2:DescribeVpcs, ec2:DescribeSubnets, ec2:DescribeSecurityGroups,
ec2:CreateRouteTable, ec2:CreateRoute, ec2:CreateInternetGateway,
ec2:CreateNatGateway, ec2:AllocateAddress
iam:CreateRole, iam:AttachRolePolicy, iam:PutRolePolicy, iam:PassRole,
iam:CreatePolicy, iam:GetRole
logs:CreateLogGroup, logs:PutRetentionPolicy, logs:CreateLogStream
acm:RequestCertificate, acm:DescribeCertificate
cognito-idp:*

Implementation Phases

Phase 1: CloudFormation Infrastructure

Files: aws/cloud/stack.yaml, aws/cloud/parameters.json

The complete CloudFormation template defining ALL resources: the static S3 bucket + CloudFront distribution (with OAC to the bucket), API Gateway REST API + custom domain, Lambda functions with their execution role, VPC with private/public subnets, security groups, RDS instance, ElastiCache cluster, DynamoDB table, the app-data S3 bucket, and VPC gateway/interface endpoints for S3 and DynamoDB. All resource names and ARNs must be internally consistent, and parameters.json must have an entry for every Parameter in stack.yaml (region, VPC CIDR, subnet CIDRs, RDS credentials, instance classes, certificate ARNs, domain names, EnableNatGateway).

Phase 2: Operational Files

Files: aws/cloud/deploy.sh, aws/cloud/destroy.sh, aws/cloud/README.md, .env, configs.py

deploy.sh runs aws cloudformation deploy with --capabilities CAPABILITY_NAMED_IAM and the parameters file. destroy.sh runs aws cloudformation delete-stack and waits for completion. It first empties both S3 buckets (static + app-data), since CloudFormation cannot delete non-empty buckets. README.md explains setup and deploy steps.

Unknowns

Unknown	Impact	Resolution
Authentication/authorization layer?	Diagram shows no Cognito or authorizer	Amazon Cognito User Pool + API Gateway JWT authorizer
Which datastore is authoritative?	Diagram wires Lambda to both	DynamoDB primary; RDS for relational; ElastiCache cache-only
Does Lambda need outbound internet?	NAT Gateway adds ~$32/mo	VPC gateway endpoints only (no NAT)
ElastiCache engine?	Affects cluster config	Redis (single node)
Multi-AZ / high availability?	Affects RDS and ElastiCache cost	Single-AZ (cost-optimized)

Notes

• The diagram shows two separate S3 buckets serving different roles — do not collapse them into one.
• The padlock on the Lambda→S3 arrow is treated as an encryption/secure-transport requirement (TLS in transit, SSE at rest).
• CloudFront and the static S3 bucket sit outside the VPC; only Lambda, RDS, and ElastiCache are VPC-bound.