Which recommendations should a Solutions Architect present to the Developers to solve the problem in a secure way with minimal maintenance and overhead?
Disable the SrcDestCheck attribute for all instances running the application and Oracle Database. Change the default route of VPC A to point ENI of the Oracle Database that has an IP address assigned within the range of 172.50.0.0/16
Create and attach internet gateways for both VPCs. Configure default routes to the internet gateways for both VPCs. Assign an Elastic IP for each Amazon EC2 instance in VPC A
Create a VPC peering connection between the two VPCs and add a route to the routing table of VPC A that points to the IP address range of 172.50.0.0/16
Create an additional Amazon EC2 instance for each VPC as a customer gateway; create one virtual private gateway (VGW) for each VPC, configure an end- to-end VPC, and advertise the routes for 172.50.0.0/16
Explanations:
Disabling the SrcDestCheck attribute is not necessary and can create security issues. Changing the default route of VPC A to point to the ENI of the Oracle Database would not work since the two VPCs are not directly connected and cannot communicate this way.
Creating and attaching internet gateways and configuring routes to them would expose the instances to the public internet, which is not secure. Additionally, assigning Elastic IPs does not resolve the connectivity issue between the two VPCs.
Creating a VPC peering connection allows private communication between the instances in the two VPCs without exposing them to the public internet. Adding a route to the routing table of VPC A that points to the IP address range of VPC B (172.50.0.0/16) enables the application instances to connect securely to the database.
Setting up customer gateways and virtual private gateways creates a more complex setup (like a VPN) which is not needed for simple VPC-to-VPC communication. This adds unnecessary overhead and maintenance, and is not the most efficient solution compared to VPC peering.