You are building a fleet of EC2 Linux Instances in the AWS environment to manage heavy workloads and write data into AWS Redshift. The developers and administrators need to login to these EC2 machines to develop, fix, deploy, and manage workloads within your organizational network ONLY. Which of the following would allow only the personnel within the organization to access the resources most securely?

Answer options:

A.EC2 instances on public subnet with secure SSH keys to login, RedShift in private subnet.
B.A bastion host in public subnet with secure SSH key to login, EC2 instances in private subnet with secure SSH keys to login, RedShift in private subnet.
C.AWS VPN connection from your organization to AWS VPC, a bastion host in VPN enabled subnet with secure SSH key to login, EC2 instances in private subnet with secure SSH keys to login, Redshift in private subnet.
D.AWS VPN connection from your organization to AWS VPC, EC2 instances in VPN enabled subnet with secure SSH keys to login, Redshift in public subnet.

Answer: C
 For
Option A, this is not secure because EC2 instances are in public subnet and are open to attacks such as DDoS. If you do not have a requirement to access the internet, try not to put AWS resources in the public subnet as a security best practice.
 For more information on DDoS attacks, refer to documentation here 
https://aws.amazon.com/answers/networking/aws-ddos-attack-mitigation/
For Option B, Although EC2 instances are secured by putting them on private subnet and only enabling bastion host on public subnet looks correct, the requirement states, these instances should only be accessed via their organization network. So this option is incorrect.
A bastion host is a server whose purpose is to provide access to a private network from an external network, such as the Internet. It does not act as a proxy to route traffic from the internet to private EC2 instance.
AWS Document says:
The solution architecture
In this section, I present this solution`s architecture and explain how you can configure the bastion host to record SSH sessions. Later in this post, I provide instructions about how to implement and test the solution.
Amazon VPC enables you to launch AWS resources on a virtual private network that you have defined. The bastion host runs on an Amazon EC2 instance that is typically in a public subnet of your Amazon VPC. Linux instances are in a subnet that is not publicly accessible. They are set up with a security group that allows SSH access from the security group attached to the underlying EC2 instance running the bastion host. Bastion host users connect to the bastion host to connect to the Linux instances, as illustrated in the following diagram. 
For Option C, VPN connections are used to connect AWS VPC from your organization’s network. By default, instances that you launch into an Amazon VPC can`t communicate with your own (remote) network. You can enable access to your remote network from your VPC by attaching a virtual private gateway to the VPC, creating a custom route table, updating your security group rules, and creating an AWS managed VPN connection.
 For more information on VPN, refer to documentation here. 
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html
So, in this option, even from a VPN connection, only bastion host is exposed from AWS to VPN, and you only open one connection from your organization to AWS. From bastion host, you can open connections to other resources in private subnet or other resources in peering VPCs.
https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/
Option D is INCORRECT because Redshift needs to be placed in the "private" subnet and not in the "public" subnet."
Note:
In the question, they mentioned that "Developers and Administrators need the login to the EC2 instances Only within your organization network." So, they should access it via their organization network.
Establish a VPN connection between your Organization network and your AWS.