A smart grid utility company is designing a real-time smart-meter telemetry ingestion platform across two AWS Regions: us-east-1 (primary) and eu-west-1 (secondary). The platform must achieve a Recovery Time Objective (RTO) of less than 5 minutes and a Recovery Point Objective (RPO) of less than 1 minute.
The architecture consists of:
- An ingress tier in each region running containerized applications on AWS Fargate in private subnets, behind an Application Load Balancer (ALB).
- Outbound connections from Fargate tasks to external grid devices that require highly resilient internet access.
- A persistence tier using Amazon Aurora PostgreSQL.
- An internal metadata microservice deployed in a shared services VPC in us-east-1 that resolves via a Route 53 Private Hosted Zone (PHZ) named grid.internal.
During normal operations, global telemetry traffic must be routed to the region with the lowest latency. If a regional outage occurs, all traffic must automatically fail over to the surviving region. The secondary region should operate in a cost-optimized warm standby configuration, scaling up its ECS tasks only during a failover.
Which solution meets these requirements while minimizing cost and operational complexity?
- Configure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.Cevap
- BConfigure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs), but provision a single NAT Gateway in the first AZ of each VPC to optimize network resource costs. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.
- CConfigure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and enable DNS resolution support on the peering connection. Rely on the peering connection's native DNS features to resolve grid.internal in eu-west-1 without manually associating the PHZ with the secondary VPC. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.
- DConfigure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Configure Route 53 latency-based routing records pointing to each regional ALB, but do not associate health checks to prevent split-brain DNS states; instead, implement an AWS Lambda function triggered by Amazon CloudWatch alarms to manually swap DNS records during a regional failover.