AWS Bastion Host

~ Last updated on : ~ jayendrapatil
Table of Contents hide
Bastion Host Overview
AWS Certification Exam Practice Questions

Bastion Host Overview

  • Bastion means a structure for Fortification to protect things behind it
  • In AWS, a Bastion host (also referred to as a Jump server) can be used to securely access instances in the private subnets.
  • Bastion host launched in the Public subnets would act as a primary access point from the Internet and acts as a proxy to other instances.

Bastion Host

Key points

  • Bastion host is deployed in the Public subnet and acts as a proxy or a gateway between you and your instances
  • Bastion host is a security measure that helps to reduce attack on your infrastructure and you have to concentrate to hardening a single layer
  • Bastion host allows you to login to instances in the Private subnet securely without having to store the private keys on the Bastion host (using ssh-agent forwarding or RDP gateways)
  • Bastion host security can be further tightened to allow SSH/RDP access from specific trusted IPs or corporate IP ranges
  • Bastion host for your AWS infrastructure shouldn’t be used for any other purpose, as that could open unnecessary security holes
  • Security for all the Instances in the private subnet should be hardened to accept SSH/RDP connections only from the Bastion host
  • Deploy a Bastion host within each Availability Zone for HA, cause if the Bastion instance or the AZ hosting the Bastion server goes down the ability to connect to your private instances is lost completely

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A customer is running a multi-tier web application farm in a virtual private cloud (VPC) that is not connected to their corporate network. They are connecting to the VPC over the Internet to manage all of their Amazon EC2 instances running in both the public and private subnets. They have only authorized the bastion-security-group with Microsoft Remote Desktop Protocol (RDP) access to the application instance security groups, but the company wants to further limit administrative access to all of the instances in the VPC. Which of the following Bastion deployment scenarios will meet this requirement?
    1. Deploy a Windows Bastion host on the corporate network that has RDP access to all instances in the VPC.
    2. Deploy a Windows Bastion host with an Elastic IP address in the public subnet and allow SSH access to the bastion from anywhere.
    3. Deploy a Windows Bastion host with an Elastic IP address in the private subnet, and restrict RDP access to the bastion from only the corporate public IP addresses.
    4. Deploy a Windows Bastion host with an auto-assigned Public IP address in the public subnet, and allow RDP access to the bastion from only the corporate public IP addresses.
  2. You are designing a system that has a Bastion host. This component needs to be highly available without human intervention. Which of the following approaches would you select?
    1. Run the bastion on two instances one in each AZ
    2. Run the bastion on an active Instance in one AZ and have an AMI ready to boot up in the event of failure
    3. Configure the bastion instance in an Auto Scaling group Specify the Auto Scaling group to include multiple AZs but have a min-size of 1 and max-size of 1
    4. Configure an ELB in front of the bastion instance
  3. You’ve been brought in as solutions architect to assist an enterprise customer with their migration of an ecommerce platform to Amazon Virtual Private Cloud (VPC) The previous architect has already deployed a 3- tier VPC. The configuration is as follows: VPC vpc-2f8t>C447
    IGW ig-2d8bc445
    NACL acl-2080c448
    Subnets and Route Tables:
    Web server’s subnet-258bc44d
    Application server’s subnet-248DC44c
    Database server’s subnet-9189c6f9
    Route Tables:
    rtb-2i8bc449
    rtb-238bc44b
    Associations:
    Subnet-258bc44d: rtb-2i8bc449
    Subnet-248DC44c: rtb-238bc44b
    Subnet-9189c6f9: rtb-238bc44b
    You are now ready to begin deploying EC2 instances into the VPC. Web servers must have direct access to the internet Application and database servers cannot have direct access to the internet. Which configuration below will allow you the ability to remotely administer your application and database servers, as well as allow these servers to retrieve updates from the Internet?
    1. Create a bastion and NAT Instance in subnet-258bc44d and add a route from rtb-238bc44b to subnet-258bc44d. (Route should point to the NAT)
    2. Add a route from rtb-238bc44b to igw-2d8bc445 and add a bastion and NAT instance within Subnet-248DC44c. (Adding IGW to routertb-238bc44b would expose the Application and Database server to internet. Bastion and NAT should be in public subnet)
    3. Create a Bastion and NAT Instance in subnet-258bc44d. Add a route from rtb-238bc44b to igw-2d8bc445. And a new NACL that allows access between subnet-258bc44d and subnet-248bc44c. (Route should point to NAT and not Internet Gateway else it would be internet accessible.)
    4. Create a Bastion and NAT instance in subnet-258bc44d and add a route from rtb-238bc44b to the NAT instance. (Bastion and NAT should be in the public subnet. As Web Server has direct access to Internet, the subnet subnet-258bc44d should be public and Route rtb-2i8bc449 pointing to IGW. Route rtb-238bc44b for private subnets should point to NAT for outgoing internet access)
  4. You are tasked with setting up a Linux bastion host for access to Amazon EC2 instances running in your VPC. Only clients connecting from the corporate external public IP address 72.34.51.100 should have SSH access to the host. Which option will meet the customer requirement?
    1. Security Group Inbound Rule: Protocol – TCP. Port Range – 22, Source 72.34.51.100/32
    2. Security Group Inbound Rule: Protocol – UDP, Port Range – 22, Source 72.34.51.100/32
    3. Network ACL Inbound Rule: Protocol – UDP, Port Range – 22, Source 72.34.51.100/32
    4. Network ACL Inbound Rule: Protocol – TCP, Port Range-22, Source 72.34.51.100/0

16 thoughts on “AWS Bastion Host”

  1. Can you please shed a little more light on the bastion host question and why you picked that answer above? There is only one IP address mentioned in the question so why the CIDR block in the answer? Also in the case of a security group, why the specific mention of “inbound”? Aren’t security groups supposed to be stateful meaning you don’t specify whether it is inbound or outbound?

    1. Bastion are like jump servers to allow access to the host in the private subnet.
      The configurations usually work like below :-
      1. Bastion needs to configured to allow inbound ssh access (TCP – 22) only from restricted ips (72.34.51.100/32, 32 here indicates exact IP address)
      2. Instances in Private subnet then allow inbound ssh access only from bastion host

  2. Also why can’t the same thing be accomplished with NACLs? What makes the security group the correct choice?

    1. NACLs inbound alone would not work in this case as they are stateless, it would need a Outbound rule also and the answer does not include that

      1. jayendra do you mean the Linux bastion needs outbound NACL to get to 72.34.51.100/32 to give results back (of whatever is done in SSH?)

        1. ACL is stateless so you yes you need to add outbound NACL with ephemeral port range which will depend on the OS running at SSH client (72.34.51.100/32)

        2. assuuming traffic flow

          your notebook–>internet—> jump server in DMZ —> backend server in private subnet

          1)CIDR for DMZ 10.0.0.0/24 , private ip for jump server : 10.0.0.100
          2)CIDR for private subnet: 10.0.1.0/24
          3)ephemeral port range is 1024-65535 (exact range depends on which OS is running on source/destination host), you can also edit this https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#Changing

          The ideal way to do this is to create 2 ACL in your VPC

          A)First ACL (attach this to public subnet)

          1)inbound rule: Allow – port: 22 – source: 0.0.0.0/0 –>this will allow SSH traffic from internet to the jump server

          2)inbound rule: Allow – port: 1024-65535 – source: 10.0.1.0/24 –>this will allow SSH traffic from EC2 hosts in the private subnet to the jump server

          3)outbound rule: Allow – port: 1024-65535 , destination: 0.0.0.0/0 –> this will allow SSH traffic from jump server to internet

          4)outbound rule: Allow – port: 22 , destination: 10.0.1.0/24 –> this will SSH traffic from jump server to ec2 instance in your private subnet

          B)Second ACL (attach this to private subnet)

          inbound rule: Allow – port: 22 , source: 10.0.0.46/32 –> this will SSH traffic from jump server to ec2 instance in your private subnet

          outbound rule: Allow – port: 1024-65535 , destination: 10.0.0.46/32 –>this will allow SSH traffic from EC2 hosts in the private subnet to the jump server

          for security groups make sure both instances(the jump server and the backend server) belong to the default VPC security group or customize it as below:

          jump server EC2 instance —>attached to security group A

          inbound —> allow port TCP-22 from 0.0.0.0/0 or better replace 0.0.0.0/0 with your public ipv4 if it’s static or your organization public ipv4 range
          outbound –> allow port TCP-22 to 10.0.1.0/24

          backend server EC2 instance–>attached to security group B

          inbound —> allow port TCP-22 from 10.0.0.46/32
          outbound –> empty

          for more info:

          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-examples

          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-recommended-nacl-rules.html

  4. Hi,
    Shouldn’t a route be added to rtb-238bc44b for Bastion? Is just adding a route to NAT good enough? I mean, would it take care of Bastion as well?

    1. NAT is to route the traffic and hence should be specified in the Route table for enabling the instances in private subnet to route traffic to internet.
      Bastion is more of a jump server and is used for enabling users to login to the instances in private subnet. This communication is taken care security groups.

  6. Need answer of below question

    An Amazon EC2 instance is in a private subnet. To SSH to the instance, it is required to use a bastion host that has an IP address of 10.0.0.5. SSH logs on the EC2 instance in the private subnet show that connections are being made over SSH from several other IP addresses. The EC2 instance currently has the following inbound security group rules applied:

    Protocol: TCP –

    Port: 22 –

    Source: 10.0.0.5/32 –

    Protocol: TCP –

    Port: 22 –

    Source: sg-xxxxxxxx –

    Protocol: TCP –

    Port: 389 –

    Source: 0.0.0.0/0 –
    What is the MOST likely reason that another IP addresses is able to SSH to the EC2 instance?

    A. The rule with 0.0.0.0/0 means SSH is open for any client to connect
    B. The rule with /32 is not limiting to a single IP address
    C. Any instance belonging to sg-xxxxxxxx is allowed to connect
    D. There is an outbound rule allowing SSH traffic

    1. Option C as the traffic from all instances belonging to sg-xxxxxxxx– is allowed.

Comments are closed.