• ✅ Yes, I completed the capstone activity.

• ❌ No, I did not complete the capstone activity.

Explanation:
I designed a complete high-level architecture and created a diagram (diagrams.net / draw.io style) that migrates both workloads to AWS, decouples layers, and uses managed services where appropriate. Key design choices:

• Hybrid connectivity & migration: AWS Direct Connect (or Site-to-Site VPN) + AWS DataSync / AWS Snow Family for bulk data transfer from the on-prem datacenter to AWS. This preserves secure, high-throughput connectivity and provides a reliable migration path for large datasets used by the analytics workload.

• Three-tier web application (cloud-native / refactor-first approach):

  • Frontend (static assets): Amazon S3 (static hosting) + Amazon CloudFront for global caching, custom domain and TLS (ACM). This offloads traffic and reduces latency.

  • Decoupling & API layer: Amazon API Gateway fronting the backend APIs (or ALB if using containerized web servers), enabling throttling, auth, and simple routing.

  • Backend / application layer: Option A (refactor/light-managed): run stateless Java app as containers on Amazon ECS with Fargate (no infra management) or EKS if retaining more Kubernetes-native features. Option B (lift-and-shift): EC2 Auto Scaling Group behind an Application Load Balancer (ALB). Use Amazon SQS for asynchronous tasks to decouple frontend and backend and Amazon SNS for fan-out events.

  • Database: Amazon RDS (MySQL/Aurora MySQL) in Multi-AZ for high availability and automated backups; read replicas for scaling reads. Use Secrets Manager or Parameter Store for credentials and enable encryption at rest (KMS) and in transit (TLS).

  • Session/state: Use ElastiCache (Redis) if session caching is needed to maintain stateless app servers.

• Analytics workload (Hadoop → AWS):

  • Ingest & landing storage: Use AWS DataSync (or Snowball for very large one-time transfer) to move on-prem raw data into an S3 data lake (S3 buckets with lifecycle policies). S3 is the primary durable storage (cold/hot tiers: S3 Standard, S3 Intelligent-Tiering, Glacier for archives).

  • Processing: Amazon EMR (spin up Hadoop/Spark clusters as required) reading/writing directly from S3 (EMRFS), minimizing HDFS dependence and allowing transient clusters (cost savings). Optionally use EMR on EKS if containerized processing preferred.

  • Catalog & ETL: AWS Glue Data Catalog for schema management and optional ETL jobs (serverless).

  • Interactive query & analysis: Amazon Athena for ad-hoc SQL on S3.

  • Visualization: Amazon QuickSight for dashboards and data visualizations, connected to Athena / RDS / Redshift if needed. For very large analytic data warehousing, consider Amazon Redshift (Spectrum) in addition to EMR.

• Security & governance: Central IAM roles/policies, AWS KMS for encryption keys, AWS WAF on CloudFront/ALB for web protections, AWS Shield (DDoS), VPC private subnets for DB and EMR master nodes, Security Groups & Network ACLs, and centralized logging via AWS CloudWatch Logs and AWS CloudTrail.

• Observability & cost control: CloudWatch metrics/alarms, AWS Config for resource compliance, and AWS Budgets / Cost Explorer for cost monitoring.

• High availability & resiliency: Multi-AZ deployments for RDS and EMR core nodes (when applicable), S3 durability for data, CloudFront for frontend availability, and autoscaling for compute layers.

If you want, I can:

• Export the diagrams.net diagram I created (PNG / PDF).

• Or paste a downloadable diagrams.net XML file you can import directly.
  Tell me which export format you prefer and I’ll provide it right away.

🧾 Summary Table