rename project + remove public VPC and NAT

Author: sebsto

Examples/ServiceLifecycle/.gitignore renamed to Examples/ServiceLifecycle+Postgres/.gitignore

@@ -4,7 +4,7 @@ This document describes the AWS infrastructure deployed by the ServiceLifecycle
 
 ## Overview
 
-The infrastructure consists of a secure VPC setup with public and private subnets, a PostgreSQL RDS instance in private subnets, and a Lambda function with VPC access. The architecture follows AWS best practices for security and network isolation.
+The infrastructure consists of a secure VPC setup with private subnets only, containing both the PostgreSQL RDS instance and Lambda function. The architecture is optimized for cost and security with complete network isolation.
 
 ## Network Architecture
 
@@ -13,31 +13,22 @@ The infrastructure consists of a secure VPC setup with public and private subnet
 - **DNS Support**: DNS hostnames and DNS resolution enabled
 
 ### Subnet Layout
-- **Public Subnets**:
-  - Public Subnet 1: `10.0.1.0/24` (AZ 1)
-  - Public Subnet 2: `10.0.2.0/24` (AZ 2)
-  - Used for Lambda functions and NAT Gateway
-  - Auto-assign public IP addresses enabled
-
 - **Private Subnets**:
   - Private Subnet 1: `10.0.3.0/24` (AZ 1)
   - Private Subnet 2: `10.0.4.0/24` (AZ 2)
-  - Used for RDS PostgreSQL database
+  - Used for RDS PostgreSQL database and Lambda function
   - No public IP addresses assigned
+  - Complete isolation from internet
 
 ### Network Components
-- **Internet Gateway**: Provides internet access for public subnets
-- **NAT Gateway**: Deployed in Public Subnet 1, allows private subnets to access the internet
-- **Route Tables**:
-  - Public Route Table: Routes traffic to the Internet Gateway
-  - Private Route Table: Routes traffic through the NAT Gateway
+- **VPC-only architecture**: No internet connectivity required
+- **Route Tables**: Default VPC routing for internal communication
 
 ## Security Groups
 
 ### Lambda Security Group
 - **Outbound Rules**:
   - PostgreSQL (5432): Restricted to VPC CIDR `10.0.0.0/16`
-  - HTTPS (443): Open to `0.0.0.0/0` for AWS service access
 
 ### Database Security Group
 - **Inbound Rules**:
@@ -67,7 +58,7 @@ The infrastructure consists of a secure VPC setup with public and private subnet
 - **Architecture**: ARM64
 - **Memory**: 512MB
 - **Timeout**: 60 seconds
-- **Network**: Deployed in public subnets with access to both internet and private resources
+- **Network**: Deployed in private subnets with access to database within VPC
 - **Environment Variables**:
   - `LOG_LEVEL`: trace
   - `DB_HOST`: RDS endpoint address
@@ -107,19 +98,64 @@ The template provides several outputs to facilitate working with the deployed re
 
 This infrastructure implements several security best practices:
 
-1. **Network Isolation**: Database is placed in private subnets with no direct internet access
+1. **Complete Network Isolation**: Both database and Lambda are in private subnets with no direct acces to or from the internet
 2. **Least Privilege**: Security groups restrict traffic to only necessary ports and sources
 3. **Encryption**: Database storage is encrypted at rest
 4. **Secure Credentials**: Database credentials are managed through AWS Secrets Manager
 5. **Secure Communication**: Lambda function connects to database over encrypted connections
 
-## Cost Optimization
-
-The template uses cost-effective resources suitable for development:
-
-- `db.t3.micro` instance (eligible for free tier)
-- Minimal storage allocation (20GB)
-- No Multi-AZ deployment
-- No automated backups
-
-For production workloads, consider adjusting these settings based on your requirements.
+## Cost Analysis
+
+### Monthly Cost Breakdown (US East 1 Region)
+
+#### Billable AWS Resources:
+
+**1. RDS PostgreSQL Database**
+- Instance (db.t3.micro): $13.87/month (730 hours × $0.019/hour)
+- Storage (20GB GP2): $2.30/month (20GB × $0.115/GB/month)
+- Backup Storage: $0 (BackupRetentionPeriod: 0)
+- Multi-AZ: $0 (disabled)
+- **RDS Subtotal: $16.17/month**
+
+**2. AWS Secrets Manager**
+- Secret Storage: $0.40/month per secret
+- API Calls: ~$0.05 per 10,000 calls (minimal for Lambda access)
+- **Secrets Manager Subtotal: ~$0.45/month**
+
+**3. AWS Lambda**
+- Memory: 512MB ARM64
+- Free Tier: 1M requests + 400,000 GB-seconds/month
+- Development Usage: $0 (within free tier)
+- **Lambda Subtotal: $0/month**
+
+**4. API Gateway (HTTP API)**
+- Free Tier: 1M requests/month
+- Development Usage: $0 (within free tier)
+- **API Gateway Subtotal: $0/month**
+
+#### Free AWS Resources:
+- VPC, Private Subnets, Security Groups, DB Subnet Group: $0
+
+### Total Monthly Cost:
+
+| Service | Cost | Notes |
+|---------|------|---------|
+| RDS PostgreSQL | $16.17 | db.t3.micro + 20GB storage |
+| Secrets Manager | $0.45 | 1 secret + minimal API calls |
+| Lambda | $0.00 | Within free tier |
+| API Gateway | $0.00 | Within free tier |
+| VPC Components | $0.00 | No charges |
+| **TOTAL** | **$16.62/month** | |
+
+### With RDS Free Tier (First 12 Months):
+- RDS Instance: $0 (750 hours/month free)
+- RDS Storage: $0 (20GB free)
+- **Total with Free Tier: ~$0.45/month**
+
+### Production Scaling Estimates:
+- Higher Lambda usage: +$0.20 per million requests
+- More RDS storage: +$0.115 per additional GB/month
+- Multi-AZ RDS: ~2x RDS instance cost
+- Backup storage: $0.095/GB/month
+
+This architecture provides maximum cost efficiency while maintaining security and functionality for development workloads.

Examples/ServiceLifecycle/INFRASTRUCTURE.md renamed to Examples/ServiceLifecycle+Postgres/INFRASTRUCTURE.md

@@ -1,18 +1,18 @@
-# ServiceLifecycle Lambda with PostgreSQL
+# A swift Service Lifecycle Lambda function with a managed PostgreSQL database
 
-This example demonstrates a Swift Lambda function that uses ServiceLifecycle to manage a PostgreSQL connection. The function connects to an RDS PostgreSQL database in private subnets and queries user data.
+This example demonstrates a Swift Lambda function that uses Swift Service Lifecycle to manage a PostgreSQL connection. The function connects to an RDS PostgreSQL database in private subnets and queries user data.
 
 ## Architecture
 
-- **Swift Lambda Function**: Uses ServiceLifecycle to manage PostgreSQL client lifecycle, deployed in public subnets
-- **PostgreSQL RDS**: Database instance in private subnets with SSL/TLS encryption
+- **Swift Lambda Function**: A network isolated Lambda function that Uses Swift ServiceLifecycle to manage PostgreSQL client lifecycle
+- **PostgreSQL on Amazon RDS**: Database instance in private subnets with SSL/TLS encryption
 - **HTTP API Gateway**: HTTP endpoint to invoke the Lambda function
-- **VPC**: Custom VPC with public subnets for Lambda/NAT Gateway and private subnets for RDS
+- **VPC**: Custom VPC with private subnets only for complete network isolation
 - **Security**: SSL/TLS connections with RDS root certificate verification, secure networking with security groups
 - **Timeout Handling**: 3-second timeout mechanism to prevent database connection freeze
 - **Secrets Manager**: Secure credential storage and management
 
-For detailed infrastructure information, see `INFRASTRUCTURE.md`.
+For detailed infrastructure and cost information, see `INFRASTRUCTURE.md`.
 
 ## Implementation Details
 
@@ -110,7 +110,7 @@ The output will include:
 
 The database is deployed in **private subnets** and is **not directly accessible** from the internet. This follows AWS security best practices.
 
-You may create an Amazon EC2 instance (virtual machine) in the public subnet of the VPC and use it as a jump host to connect to the database.  The SAM template doesn't create this for you. [This is left as an exercise to the reader](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html).
+To connect to the database, you would need to create an Amazon EC2 instance in a public subnet (which you'd need to add to the VPC) or use AWS Systems Manager Session Manager for secure access to an EC2 instance in a private subnet. The current template uses a private-only architecture for maximum security.
 
 You can access the database connection details in the output of the SAM template:
 
@@ -171,23 +171,27 @@ sam logs -n ServiceLifecycleLambda --stack-name servicelifecycle-stack --tail
 This example follows AWS security best practices:
 
 1. **Private Database**: Database is deployed in private subnets with no internet access
-2. **Network Segmentation**: Separate public and private subnets with proper routing
+2. **Complete Network Isolation**: Private subnets only with no internet connectivity
 3. **Security Groups**: Restrictive security groups following least privilege principle
 4. **Secrets Management**: Database credentials stored in AWS Secrets Manager
 5. **Encryption**: SSL/TLS for database connections with certificate verification
-6. **VPC Endpoints**: Administrative access through SSM VPC endpoints
+6. **Minimal Attack Surface**: No public subnets or internet gateways
 
 The infrastructure implements secure networking patterns suitable for production workloads.
 
 ## Cost Optimization
 
-The template uses:
+The template is optimized for cost:
 - `db.t3.micro` instance (eligible for free tier)
 - Minimal storage allocation (20GB)
 - No Multi-AZ deployment
 - No automated backups
+- No NAT Gateway or Internet Gateway
+- Private-only architecture
 
-For production workloads, adjust these settings based on your requirements.
+**Estimated cost: ~$16.62/month (or ~$0.45/month with RDS Free Tier)**
+
+For detailed cost breakdown, see `INFRASTRUCTURE.md`.
 
 ## Cleanup
 
@@ -215,10 +219,9 @@ when deploying with SAM and the `template.yaml` file included in this example, t
 ### Lambda can't connect to database
 
 1. Check security groups allow traffic on port 5432 between Lambda and RDS security groups
-2. Verify the Lambda function is deployed in subnets with proper routing to private subnets
-3. Check VPC configuration and routing tables
-4. Verify database credentials are correctly retrieved from Secrets Manager and that the Lambda execution policies have permissions to read the secret.
-5. Ensure the RDS instance is running and healthy
+2. Verify both Lambda and RDS are deployed in the same private subnets
+3. Verify database credentials are correctly retrieved from Secrets Manager and that the Lambda execution policies have permissions to read the secret
+4. Ensure the RDS instance is running and healthy
 
 ### Database connection timeout