Which architecture will set up an Elastic Beanstalk environment to access the company’s application without making multiple changes on the company’s end?
Configure the Elastic Beanstalk application to place Amazon EC2 instances in a private subnet with an outbound route to a NAT gateway in a public subnet. Associate an Elastic IP address to the NAT gateway that can be whitelisted on the payment gateway application side.
Configure the Elastic Beanstalk application to place Amazon EC2 instances in a public subnet with an internet gateway. Associate an Elastic IP address to the internet gateway that can be whitelisted on the payment gateway application side.
Configure the Elastic Beanstalk application to place Amazon EC2 instances in a private subnet. Set an HTTPS_PROXY application parameter to send outbound HTTPS connections to an EC2 proxy server deployed in a public subnet. Associate an Elastic IP address to the EC2 proxy host that can be whitelisted on the payment gateway application side.
Configure the Elastic Beanstalk application to place Amazon EC2 instances in a public subnet. Set the HTTPS_PROXY and NO_PROXY application parameters to send non-VPC outbound HTTPS connections to an EC2 proxy server deployed in a public subnet. Associate an Elastic IP address to the EC2 proxy host that can be whitelisted on the payment gateway application side.
Explanations:
This option places EC2 instances in a private subnet, ensuring they are not directly exposed to the internet. The NAT gateway allows outbound internet access while maintaining security. Associating an Elastic IP address with the NAT gateway provides a single public IP for whitelisting by the payment gateway, complying with the security policy.
This option places EC2 instances in a public subnet with direct internet access through an internet gateway. While it allows access to the payment gateway, it violates the requirement for a secure architecture, exposing instances directly to the internet. Additionally, associating an Elastic IP with the internet gateway does not provide control over outbound connections for whitelisting.
This option involves using an EC2 proxy server in a public subnet, which introduces additional complexity. While it allows control over outbound traffic, it requires configuring application parameters for HTTPS_PROXY. This setup is not the simplest solution and does not align with the requirement for minimal changes on the company’s end.
Similar to option C, this option uses an EC2 proxy server in a public subnet but also places EC2 instances in a public subnet. It complicates the setup unnecessarily and may expose the environment to the internet. Moreover, the use of both HTTPS_PROXY and NO_PROXY can create confusion in traffic routing, which is not ideal given the security constraints.