Comprehensive Requirements Document

AWS API Gateway / Lambda DevOps Deployment Platform

Zero Trust Architecture for Serverless PaaS Management

1. Purpose & Scope

This document defines the full set of requirements for a DevOps deployment and runtime system using AWS API Gateway, AWS Lambda (Python 3.14), DynamoDB, SNS, and Route53. The system enables secure, flexible, and evolving serverless web application deployments without using CloudFormation, CDK, Terraform, Cognito, CloudFront, or any CDN.

This system follows strict Zero Trust principles, including resource isolation, least privilege, explicit authorization, and full traceability of all infrastructure changes.

2. High-Level System Description

The platform uses:

• A single AWS API Gateway to host multiple microservices via context paths and greedy routes.
• AWS Lambda functions written in Python 3.14 to serve HTML/CSS/JS for browser-accessible applications.
• DynamoDB for metadata, change logs, asset inventory, and table-specific access metadata.
• SNS for deployment alerts and operational notifications.
• Route53 for DNS and subdomain creation, enabling HTTPS services served from API Gateway.

All provisioning occurs through AWS CloudShell scripts only, enforcing deterministic deployments and strict environment controls.

The system includes a fully responsive web-based Asset Inventory UI, powered by Lambda and API Gateway, allowing administrators to browse assets, view metadata, inspect change logs, and open live service links.

3. Architectural Requirements

3.1 Core AWS PaaS Services

The system must use:

• API Gateway
• Single regional API Gateway.
• HTTPS only.
• Multiple context paths to host microservices.
• Greedy path routing (/{proxy+}) for nested routes.
• No CloudFront, no CDN.
• Lambda (Python 3.14)
• Each context path may reference one or more Lambdas.
• Lambdas serve webpages and static content.
• Code updates must be deployable without adjusting Lambda parameters.
• Lambdas must be isolated per Zero Trust rules.
• DynamoDB
• Stores:
• Asset metadata
• Change logs
• Tag schemas
• Application classifications
• Zero trust access mappings
• Must support table-level access control logic per Lambda.
• SNS
• Sends alert emails for deployments, failures, and security warnings.
• Route53
• Supports creation of subdomains for new services.
• Must route HTTPS traffic directly to API Gateway.

4. Deployment Requirements

All AWS resources must be deployed exclusively via AWS CloudShell using scripts that:

• Create Lambda functions
• Create or update API Gateway routes
• Create or update DynamoDB tables and policies
• Register Route53 subdomains
• Generate IAM roles following Zero Trust
• Run test suites
• Update DynamoDB metadata and change logs
• Send SNS notifications

Prohibited Tools:

No CloudFormation, Terraform, AWS CDK, or other IaC systems.

No Cognito.

No CloudFront.

No CDNs.

5. Functional Requirements

5.1 API Gateway

• Must support hierarchical route structures.
• Must support nested greedy routes.
• Must allow new services to be added without gateway replacement.
• Must isolate microservices using separate Lambdas.

5.2 Lambda Services

• Lambdas must serve HTML/CSS/JS content.
• Shared styles.css per subdomain.
• Lambda code must be replaceable without changing its configuration.
• Lambdas may interact with DynamoDB only if explicitly allowed.
• Must pass deployment test suite before being considered healthy.

5.3 Route53 Subdomains

• CloudShell scripts must create or update subdomains automatically.
• Subdomains map to services accessible via HTTPS through API Gateway.

6. UI Requirements (Asset Inventory System)

6.1 Responsiveness

All pages must be fully responsive and maintain integrity across:

• Desktop
• Laptop
• Tablet
• Mobile

No horizontal overflow allowed.

Mobile-first CSS required.

6.2 Inventory Listing Page

Must include:

• Search bar
• Filters (PaaS type, tags, health, environment)
• Asset table showing:
• PaaS Service
• Name
• Description
• Health status
• “Open” (live link)
• “View Details”

6.3 Asset Detail Page

Must include:

• PaaS type
• Asset name
• Description
• Full metadata
• Live link (opens in a new tab)
• Health status + last test results
• Change log history
• Associated Lambdas
• DNS/subdomain info
• Routing context info
• IAM policy information (Zero Trust section)

7. Metadata Requirements

7.1 Required Metadata Fields

Every asset must include:

• Name
• PaaS type
• Purpose
• Owner
• Tags
• Environment
• Version
• Last updated timestamp
• Live URL (if applicable)

7.2 DynamoDB Metadata Storage

• All metadata stored centrally in the Metadata DynamoDB table.
• Metadata must be queryable and filterable.
• Metadata updates must be logged.

8. Change Log Requirements

8.1 Required Fields

Each deployment must create change log records containing:

• Timestamp
• Actor (CloudShell script or user)
• Operation type
• Target asset
• Parameter changes
• Test results
• SNS notification status

8.2 Behavior

• Must log every deployment, update, deletion, or routing change.
• Logs must appear on Asset Detail Pages.
• Logs must be queryable by asset, user, tag, or date range.

9. Zero Trust Architecture Requirements

9.1 Core Zero Trust Principles

The system must enforce:

• Least privilege
• No shared IAM roles
• No wildcard permissions
• Explicitly authorized resource access
• No implicit trust between Lambdas or services
• Authorization enforced by IAM + metadata verification
• Every Lambda isolated from every other Lambda

9.2 DynamoDB Table Creation

CloudShell scripts must:

• Create DynamoDB tables.
• Create IAM roles and specific policies per Lambda.
• Bind those policies only to Lambda(s) explicitly approved.
• Store zero trust mapping metadata in DynamoDB.
• Log table creation + policy creation in change logs.

9.3 IAM Policy Rules

IAM roles attached to Lambdas must:

• Be unique per Lambda.
• Use specific resource ARNs.
• Prohibit:
• dynamodb:*
• * wildcards
• Global resource references
• Specify exact allowed actions.
• Include table-level access mapping in metadata.

Example allowed action set:

• dynamodb:GetItem
• dynamodb:PutItem
• dynamodb:UpdateItem
• dynamodb:Query

9.4 Lambda Isolation

• Lambdas cannot call each other unless explicitly authorized.
• Lambdas cannot access other tables they are not mapped to.
• Environment variables must reference only authorized tables.

9.5 Access Verification

Deployment scripts must validate:

• IAM policies contain no extra permissions.
• Only approved Lambdas can query the target table.
• Unauthorized access attempts are denied and logged.
• Alerts sent via SNS when unauthorized access is detected.

9.6 Logging & Alerts

Unauthorized attempts must generate:

• CloudWatch logs
• SNS alerts
• Change log entries

10. Testing Requirements

10.1 Deployment Tests

Deployments must test:

• API routing correctness
• Lambda execution success
• DynamoDB access (authorized + unauthorized tests)
• Route53 DNS propagation
• HTTPS access

10.2 Health Testing

Each service must support:

• 200 OK checks
• Latency tests
• Error response validation

10.3 Reporting

Test results:

• Stored in DynamoDB
• Added to change logs
• Included in SNS alerts

11. Security & Authentication Requirements

11.1 Authentication

• Must not use Cognito.
• Custom session-based authentication is required.
• Sessions must be validated on each request.
• No implicit trust beyond session validation.

11.2 Access Control

• Asset Inventory UI must be restricted to authenticated users.
• Deployment endpoints must require authorization.
• IAM policies must remain highly granular.

12. Constraints

• No CloudFront
• No CDN
• No Cognito
• No IaC (CloudFormation, CDK, Terraform)
• Must use AWS CloudShell
• Must use Lambda Python 3.14
• Must enforce Zero Trust at all layers

13. Acceptance Criteria

The system is considered complete when:

1. A single API Gateway hosts multiple services through context paths and greedy routes.
2. Lambdas serve responsive web UI pages using shared CSS.
3. DynamoDB metadata and change logs function correctly.
4. Zero Trust IAM policies enforce table-level isolation.
5. Unauthorized DynamoDB access attempts are denied and logged.
6. Route53 subdomains successfully route to API Gateway.
7. CloudShell scripts create all resources deterministically.
8. SNS alerts operate for deployments and security events.
9. All pages work responsively on all screen sizes.
10. Authentication is functional without Cognito.
11. No prohibited services or IaC tools were used.
12. Asset Inventory UI shows accurate metadata, change logs, links, and health status.
13. All deployment tests, health checks, and routing checks pass fully.