🔐 Key Components:

Amazon Cognito: Manages user authentication and generates authorization tokens for secure API access with MFA support

API Gateway with FHIR Endpoints: RESTful API that creates patient resources using JSON payloads with request validation and rate limiting

AWS Lambda: Serverless functions parse and validate JSON payloads with automatic scaling and pay-per-invocation pricing

Storage Layer: DynamoDB stores structured FHIR fields while S3 stores complete document bundles with versioning

Monitoring: X-Ray tracks message flow across services and CloudTrail provides comprehensive audit logs for compliance

🌐 Architecture Layers:

Global Layer: Route 53 for DNS management and CloudFront CDN for global content delivery with edge caching and DDoS protection

Presentation Tier: Auto Scaling group of front-end servers behind Application Load Balancer serving user interfaces with health checks

Application Tier: Business logic servers with ElastiCache for in-memory caching, reducing database load by 80%

Database Tier: Aurora Primary in AZ1 with Aurora Replica in AZ2 for read scaling and automatic failover within 30 seconds

Storage: Amazon S3 for static assets with lifecycle policies and Amazon EFS for shared file system

📱 Key Components:

AWS Amplify (Steps 1-2): Unified framework accelerating mobile/web development with pre-built UI components, offline sync, and authentication

AppSync (Step 3): Managed GraphQL API providing real-time subscriptions for live location updates with DynamoDB integration and conflict resolution

Location Service (Step 4): Provides Track for real-time monitoring, Geofence for virtual perimeters, Map rendering, geocoding, and routing

EventBridge (Step 6): Routes geofence entry/exit events to Lambda functions with event filtering and schema registry

Lambda (Step 7): Executes business logic like sending notifications via SNS and updating location history in DynamoDB

Amazon Pinpoint: Delivers push notifications, emails, SMS for user engagement with campaign analytics and A/B testing

🏗️ Key Components:

Production VPC: Hosts the customer-facing EC2 instance serving live traffic from Customers and the Sales team. This VPC is the primary environment with strict access controls and higher security posture.

Development VPC: A separate isolated VPC hosting a dedicated EC2 instance used by Engineering and Product teams for building, testing, and validating features before they reach production.

VPC Peering Connection: A private, non-transitive network link between the Production and Development VPCs. It allows EC2 instances in both VPCs to communicate using private IP addresses — no NAT gateway, VPN, or internet exposure required. Peering is region-local here but can span regions.

Team Access Model: Customers and the Sales team access the Production EC2 instance directly. The Engineering team accesses both EC2 instances (cross-environment capability), while the Product team accesses the Development EC2 instance for validation. This role-based model enforces least-privilege access.

AWS Cost Management Services: The Finance team uses services like AWS Cost Explorer, Budgets, and Cost and Usage Reports to monitor spending across both VPCs. Tags applied to resources in each VPC enable granular cost attribution by environment and team.

⚙️ Key Components:

Amazon EKS Cluster (Step 2): A fully managed Kubernetes cluster deployed in a private subnet. It runs two logical deployment groups — deployment-ui (frontend services and pods) and deployment-app (backend services and pods) — separated for independent scaling and lifecycle management.

Kubernetes Ingress & Network Load Balancer (Step 5): Traffic from the internet enters via Route 53 DNS (Step 6), is directed to a Network Load Balancer (NLB), which forwards it through the Kubernetes Ingress controller to the appropriate UI or app service inside the EKS cluster.

Elastic Network Interface & NSX-T Router (Steps 1 & 4): The EKS cluster connects to the VMware SDDC via an Elastic Network Interface (ENI). The NSX-T Tier-0 Router within the SDDC compute network routes traffic between AWS and the VMware VMs hosting database workloads, enabling seamless hybrid connectivity.

CI/CD Pipeline (Steps 7–11): The dev team commits code to AWS CodeCommit (Step 7). CodePipeline orchestrates the workflow — triggering CodeBuild (Step 8) to compile and containerize the application, push the resulting image to Amazon ECR (Step 9), and then deploy updated containers to the EKS cluster (Steps 10 & 11) automatically.

VMware Cloud on AWS SDDC: The SDDC hosts EC2 bare metal instances (ESXi clusters) and VMware VMs running database workloads within an NSX-T overlay network. This allows enterprises to run VMware-native workloads on AWS hardware without re-platforming.

🏭 Key Components:

Industrial Edge (Step 1): Physical industrial data stores and gateway/PLC devices at the factory floor collect sensor readings, operational telemetry, and machine states. This raw operational technology (OT) data is the foundation of the architecture.

Kelvin Node & Bridges (Step 2): Edge Gateway components running inside the factory. Kelvin Nodes act as local compute agents that pre-process and buffer data before securely transmitting it to the cloud. Kelvin Bridges handle the protocol translation between industrial equipment and cloud APIs.

Amazon EKS — Kelvin Cluster (Step 5): The core platform runs as a containerized Kubernetes workload on Amazon EKS within Kelvin's own AWS account. An Application Load Balancer routes external traffic into the cluster. Amazon RDS provides persistent relational storage for platform metadata, while Amazon SNS (Step 9) handles event-driven notifications and alerting across the system.

Kelvin Applications (Steps 3 & 4): Kelvin Manager and Kelvin SDK expose platform capabilities to Kelvin users through web and mobile interfaces (Step 7, Kelvin Maps/Copilots), enabling real-time monitoring, configuration, and AI-assisted decision making.

Customer Account & Integrations (Steps 6 & 8): Customer EC2 instances (running Kelvin Nodes) sit in a separate AWS account. These connect to a suite of AWS integration services: Amazon S3 for raw data archiving, AWS IoT SiteWise for industrial asset modeling and time-series data ingestion, Amazon QuickSight for BI dashboards, and Amazon SageMaker for training and deploying predictive maintenance and anomaly detection ML models.

🔭 Key Components:

IBM Instana SaaS — Stream Processor & UI Backend: The centralized Instana control plane ingests high-frequency telemetry from all agent sources, processes it in real time using a stream processing engine, and serves dashboards, traces, and alerts through the UI backend. Developers and SREs access full-stack visibility without managing the Instana infrastructure itself.

Customer Environment — Instana Agents on Compute Targets: Agents are deployed directly onto Amazon EC2 instances, within Amazon EKS pods (as a DaemonSet), on Amazon ECS tasks, and inside Red Hat OpenShift Service on AWS (ROSA) clusters. Each agent automatically discovers running processes, services, and dependencies with zero-configuration auto-instrumentation.

Amazon CloudWatch Integration: CloudWatch acts as the central metrics aggregation layer for AWS-native services. Instana pulls CloudWatch metrics for managed services — including AWS Lambda, Amazon DynamoDB, Amazon S3, Amazon SQS, Amazon Aurora, and Amazon MSK — to provide correlated observability across both custom and managed workloads.

ROSA with IBM MQ & IBM Db2: A special ROSA cluster (Red Hat OpenShift on AWS) runs IBM middleware workloads — IBM MQ for message queuing and IBM Db2 for relational data. Instana monitors both the OpenShift platform layer and the IBM application layer, enabling end-to-end distributed tracing across hybrid stacks.

Corporate Data Center — On-Premises Agents: Instana agents installed on on-premises servers, applications, and databases feed the same SaaS backend, creating a unified observability plane that spans both cloud and on-premises infrastructure without siloed tooling.

Alerting Channels: When Instana detects anomalies, threshold breaches, or incidents, it delivers alerts to developers and SREs via email, webhooks (for integration with ITSM tools like PagerDuty or ServiceNow), and chat platforms (Slack, Microsoft Teams).

🛡️ Key Components:

Route 53 Failover Routing: Route 53 is configured with a primary record pointing to the active region and a secondary record pointing to the passive region. Health checks continuously probe the active region's load balancer. If the health check fails, Route 53 automatically promotes the secondary record, routing all DNS queries to the passive region without manual intervention. TTL tuning controls propagation speed.

Active Region — Elastic Load Balancing & Auto Scaling: Production traffic enters through an Elastic Load Balancer (ELB), which distributes requests across Front End Servers and Application Servers in two Availability Zones. Auto Scaling groups maintain the desired instance count and replace unhealthy instances automatically, ensuring high availability within the region.

Active Region — Aurora Primary & Replica: The active region runs an Aurora Primary instance in one AZ and an Aurora Replica in a second AZ, both sharing a distributed Aurora cluster storage volume. The replica enables read offloading and provides sub-30-second automatic failover if the primary fails within the region — independent of the cross-region DR mechanism.

Passive Region — Warm Standby with No Running Instances: The passive region has its ELB, Auto Scaling groups, and Aurora Replica configured and ready, but no EC2 instances are running. This warm standby approach eliminates the compute cost of a fully active standby while dramatically reducing RTO compared to a cold standby. When failover occurs, Auto Scaling launches instances rapidly from the existing launch configurations.

Aurora Global Database — Asynchronous Cross-Region Replication: Aurora Global Database replicates data from the active region's Aurora cluster to the passive region's Aurora Replica with typical replication lag under one second. This RPO (Recovery Point Objective) means virtually no data loss during a regional failure. In a DR event, the passive region's replica can be promoted to a standalone primary cluster within minutes.

Aurora Cluster Snapshot: The passive region also maintains periodic Aurora cluster snapshots stored in Amazon S3. Snapshots provide a point-in-time recovery option independent of the live replica, protecting against logical data corruption or accidental deletion scenarios that replication alone cannot address.

🌐 Key Components:

Public Subnet with Security Group A: Hosts EC2 instances that need direct internet access — typically web servers or bastion hosts. The subnet is "public" because its associated Route Table A contains an explicit route directing internet-bound traffic (0.0.0.0/0) to the Internet Gateway. Security Group A defines the allowed inbound/outbound rules at the instance level (e.g., HTTP/HTTPS inbound).

Private Subnet with Security Group B: Hosts EC2 instances that must not be directly reachable from the internet — typically application servers, databases, or internal microservices. Route Table B is implicitly associated with this subnet and routes outbound traffic through the VPN Gateway rather than the Internet Gateway, keeping traffic on private networks. Security Group B is typically more restrictive, only permitting traffic from Security Group A.

Route Table A (Explicit Association): Explicitly associated with the public subnet. Contains routing rules that send 172.16.0.0, 172.16.1.0, and 172.16.2.0 prefixes through the VPC Router, plus a default route to the Internet Gateway. Explicit association means this route table was manually linked to the subnet.

Route Table B (Implicit Association): Implicitly associated with the private subnet — meaning it is the VPC's main route table and applies to any subnet not explicitly linked to another route table. It routes the same 172.16.x.x prefixes through the router, with private traffic directed toward the VPN Gateway instead of the Internet Gateway.

VPC Router: The implicit, always-on routing component inside every VPC. It handles local routing between subnets and forwards traffic to the correct gateway (Internet Gateway or VPN Gateway) based on the destination IP and the route table entries.

Internet Gateway: An AWS-managed, horizontally scaled gateway attached to the VPC that enables bidirectional internet communication for instances in public subnets. It performs NAT for instances with public IP addresses.

VPN Gateway, VPN Connection & Customer Gateway: Together these three components establish an AWS Site-to-Site VPN tunnel. The VPN Gateway is the AWS-side endpoint attached to the VPC. The Customer Gateway represents the on-premises router or firewall device. The VPN Connection is the encrypted IPsec tunnel between them, enabling private EC2 instances to communicate securely with the corporate data center over the public internet.

⚡ Key Components:

Client & Custom Domain: The user's browser navigates to a custom domain (e.g., https://example.com). The client-side app issues HTTPS API requests to a separate API subdomain (e.g., https://api-example.com), sending a third-party token along with each request for authorization.

Amazon CloudFront: Acts as the global CDN and HTTPS termination point for the web application. CloudFront caches static assets at edge locations worldwide, reducing latency for geographically distributed users and offloading origin traffic. It integrates with Route 53 for custom domain mapping and with ACM for free SSL/TLS certificates.

Amazon Route 53: Manages DNS records for the custom domain, mapping the friendly domain name to the CloudFront distribution and the API Gateway endpoint. Route 53 also supports health checks and latency-based routing for multi-region deployments.

AWS Certificate Manager (ACM): Provisions and auto-renews a free SSL/TLS certificate bound to the custom domain. CloudFront uses this certificate to enable HTTPS, ensuring all data in transit is encrypted. ACM certificates for CloudFront must be created in the us-east-1 region.

Amazon Cognito: Handles user authentication and authorization. The client logs in using a Cognito User Pool ID or a third-party identity provider (e.g., Google, SAML). Cognito issues a JWT access token, which the client app attaches to every API Gateway request. API Gateway verifies this token with Cognito before forwarding the request to Lambda — acting as a zero-code authorizer.

Amazon API Gateway: The unified API entry point that receives HTTPS requests, validates Cognito tokens, and routes each request to the appropriate Lambda function based on the URL path: /tickets, /shows, or /info. API Gateway also handles rate limiting, request validation, and CORS configuration.

AWS Lambda Functions with IAM Roles: Three dedicated Lambda functions each handle one API resource. Each function is assigned its own IAM execution role (lambda-ticket-role, lambda-show-role, lambda-info-role), enforcing least-privilege access — each Lambda can only read the specific DynamoDB table items it needs, preventing over-permissioning.

Amazon DynamoDB: A fully managed NoSQL database storing the application data (ticket, show, and info records). Lambda functions retrieve the appropriate DynamoDB information based on incoming request parameters and return the result to the API Gateway response chain.

🐳 Key Components:

Step 1 — Amazon Route 53: Resolves the web client's custom domain to the CloudFront distribution. Route 53 also supports latency-based routing and health checks if the architecture scales to multiple regions.

Step 2 — Amazon Cognito: Authenticates users before they access the application. Cognito issues JWT tokens validated by API Gateway, enabling token-based authorization across all backend API calls without custom auth code in the application containers.

Step 3 — Amazon CloudFront: A global CDN that caches and delivers static web assets from the nearest edge location, drastically reducing latency for international users. CloudFront also enforces HTTPS and integrates with ACM for certificate management.

Step 4 — Amazon S3 (Static Storage): Stores the static frontend assets (HTML, CSS, JavaScript, images) that CloudFront distributes. S3 serves as the CloudFront origin for static content, decoupling it from the dynamic containerized backend.

Step 5 — Amazon API Gateway: The single entry point for all dynamic API requests. After verifying the Cognito token, API Gateway forwards requests to the Application Load Balancer, which routes them to the appropriate ECS service.

Step 6 — Application Load Balancer (ALB): Distributes incoming API traffic across ECS Fargate tasks in both Availability Zones. The ALB performs health checks on tasks and automatically stops routing to unhealthy containers, ensuring zero-downtime deployments and fault tolerance.

Steps 7 — Amazon ECS + AWS Fargate (AZ 1 & AZ 2): ECS manages container task scheduling and service definitions, while Fargate provides the serverless compute layer — no EC2 instances to patch or right-size. Tasks run in private app subnets in both AZ 1 and AZ 2, providing resilience against an AZ failure. Container images are pulled from ECR at task launch.

Step 8 — Amazon DynamoDB (Private Database Subnets): A fully managed, serverless NoSQL database deployed in private database subnets in both AZs. DynamoDB stores application state and data, responding to read/write requests from ECS Fargate tasks. DynamoDB's built-in multi-AZ replication means the application's data layer is inherently highly available.

Step 9 — Amazon ECR: A fully managed container registry storing the Docker images deployed to ECS Fargate. ECR integrates with IAM for access control and with CI/CD pipelines (CodePipeline, GitHub Actions) to push new image versions. ECS pulls images from ECR when launching or updating tasks.

Step 10 — Amazon CloudWatch: Provides comprehensive monitoring for the entire stack — ECS task metrics (CPU, memory), ALB access logs, DynamoDB read/write capacity, and custom application metrics. CloudWatch Alarms can trigger Auto Scaling policies for ECS services based on traffic patterns.

🔐 Key Components:

ACM Private Certificate Authority (ACM PCA): AWS's fully managed private CA service acts as the root or subordinate certificate authority for the organization. It issues X.509 certificates signed by the private CA, enabling mTLS and internal service-to-service encryption without relying on public CAs. ACM PCA is referenced by its ARN (Amazon Resource Name) when configuring the issuer controller.

AWS Private CA Issuer Controller: A Kubernetes controller (deployed as a pod in EKS) that bridges cert-manager with ACM PCA. When cert-manager creates a certificate request, the Issuer Controller intercepts it, calls the ACM PCA API using the configured PCA ARN, and retrieves the signed certificate. It watches for certificate request events and updates their status once the CA responds.

cert-manager Certificate Controller: The core cert-manager component running inside the EKS control plane. It watches Kubernetes Certificate custom resources, creates CertificateRequest objects, monitors their status, and stores the resulting signed certificate and private key as a Kubernetes Secret. It also handles automatic certificate renewal before expiry (typically at 2/3 of the certificate's lifetime).

Kubernetes API Server & ETCD: The API Server is the central management plane for all Kubernetes resources — it receives certificate requests from cert-manager and stores the resulting certificate Secrets. ETCD is the distributed key-value store backing the API Server, persisting all cluster state including Secrets. Secrets containing TLS certificates are encrypted at rest in ETCD when EKS envelope encryption is enabled.

Kubernetes Secret (TLS Certificate): The certificate and private key issued by ACM PCA are stored as a Kubernetes TLS Secret. Application workloads consume certificates by mounting this Secret as a volume or referencing it in an Ingress resource — decoupling certificate management from application deployment.

EC2 Node Compute Group — Pods & Hello World Services: Application pods (Pod 1 and Pod 2) run on EC2 worker nodes in the EKS cluster. Each pod runs a Hello World Service that consumes TLS certificates via the Kubernetes Secret, enabling encrypted communication between internal services or exposing HTTPS endpoints to the Ingress controller.

Ingress Controller & AWS Network Load Balancer (NLB): The Ingress controller (e.g., AWS Load Balancer Controller) routes external HTTPS traffic into the appropriate pods based on Ingress rules. SSL is terminated at the Ingress layer using the ACM-issued certificate — the NLB handles TLS handshake at the edge, forwarding decrypted traffic to the pods over the cluster network.

🖥️ Key Components:

Internet Gateway: The VPC-level gateway that allows the EC2 instances in the public subnets to receive inbound traffic from the internet and send outbound traffic. The Internet Gateway is attached to the VPC and referenced in the public subnet route tables.

Application Load Balancer (EC2 Security Group): An ALB deployed across both public subnets, covered by the EC2 Security Group. The ALB receives all inbound HTTP/HTTPS traffic from the Internet Gateway and distributes it evenly (or via sticky sessions) to the EC2 instances in AZ 1 and AZ 2. ALB health checks automatically stop routing to unhealthy instances, maintaining uptime during instance failures or deployments.

Amazon EC2 Instances (Public Subnets — AZ 1 & AZ 2): Two EC2 web/application servers, one in each Availability Zone's public subnet. Both instances are covered by the EC2 Security Group, which permits inbound traffic only from the ALB (not directly from the internet). Running instances in public subnets here allows them to receive load-balanced traffic while still providing direct outbound internet access for package updates or API calls.

Amazon EFS with Mount Targets: Amazon Elastic File System provides a fully managed, scalable NFS file system shared across both EC2 instances simultaneously. Each AZ has its own EFS Mount Target — a network endpoint within that AZ's subnet — ensuring low-latency, in-AZ access to the shared file system. The left EC2 instance is labelled "Reads only" from EFS, indicating a common pattern where one node writes (e.g., uploaded content) and replicas serve reads. EFS automatically replicates data across multiple AZs within the region for durability.

Amazon RDS (Private Subnet — AZ 2) & RDS Read Replica (Private Subnet — AZ 1): The primary Amazon RDS instance resides in the private subnet of AZ 2, covered by the DB Security Group which only permits inbound connections from the EC2 Security Group. A Read Replica in AZ 1's private subnet receives asynchronous replication from the primary RDS instance — write transactions commit to the primary and are replicated to the replica with minimal lag. The Read Replica offloads read-heavy queries (reporting, search) from the primary, improving overall database throughput. In a failure scenario, the Read Replica can be promoted to a standalone primary.

DB Security Group: A dedicated security group applied to both the RDS primary and Read Replica. It only allows inbound database port traffic (e.g., port 3306 for MySQL or 5432 for PostgreSQL) from instances within the EC2 Security Group — blocking all other traffic, including direct internet access. This enforces strict network segmentation between the application and database tiers.