Why Bastion Hosts Add Risk

To administer servers inside a private network, teams traditionally used a bastion host (also called a jump box): a hardened, internet-facing instance you SSH into first, then hop to internal machines. While common, this pattern widens your attack surface in several ways the SCS-C02 exam expects you to recognize and eliminate.

A bastion host sits in a public subnet with a port (usually 22 for SSH or 3389 for RDP) open to the internet or a corporate IP range. Administrators connect to it, then reach private instances. It is the single guarded door into the environment, which makes it both critical and a prime target.

The biggest risk is the open inbound port. Any internet-reachable SSH or RDP port is constantly scanned and brute-forced by attackers. Even with key-based auth, an exposed port invites attacks, and a single misconfiguration or unpatched vulnerability on the bastion can hand attackers a foothold into your whole network.

Bastion access usually relies on long-lived SSH key pairs distributed to administrators. These keys can be copied, lost, or left on former employees' laptops. Rotating them across a fleet is painful, and there is rarely a clean record of which key opened which session, undermining accountability.

Tracking who did what through a bastion is hard. Native SSH gives little centralized logging of the commands run on downstream hosts. Investigating an incident means stitching together host logs, and a compromised bastion could let an attacker erase its own traces, exactly the visibility gap auditors flag.

The bastion itself is an instance you must continuously patch and harden. If it falls behind on updates, it becomes the weakest link. Maintaining a highly available, always-secure jump box is ongoing operational overhead that adds cost and risk without delivering business value.

Because all administrative traffic funnels through the bastion, it is both a single point of failure and a high-value target. If it goes down, admins lose access; if it is breached, the attacker gains a launching pad. Concentrating risk in one exposed host is an architecture the exam wants you to avoid.

AWS Systems Manager (SSM) Session Manager removes the need for bastions entirely. It provides shell access to instances through the SSM service with no open inbound ports, no public IP, and no SSH keys. Access is controlled by IAM and every session is logged, addressing every weakness of the bastion model at once.

SSM works because the instance runs an SSM Agent that makes an outbound connection to the SSM service; nothing inbound is opened. Security groups can deny all inbound traffic and administration still works. This inversion, outbound instead of inbound, is the key insight that makes bastions obsolete.

On the exam, any scenario describing open SSH/RDP ports, distributed key pairs, or a jump box almost always has a better answer: replace the bastion with Session Manager. It shrinks the attack surface, centralizes access control in IAM, and produces a full audit trail, the secure, least-privilege design AWS recommends.

A bastion host exposes an inbound port, depends on standing SSH keys, audits poorly, and must be constantly patched, making it a concentrated, attractive target. The recommended replacement is SSM Session Manager, which grants IAM-controlled, fully logged shell access with no open ports, public IP, or keys at all.

Test why bastions are risky.

A bastion host opens an inbound SSH/RDP port, relies on long-lived SSH keys, audits poorly, and demands constant patching, concentrating risk in one exposed target. SSM Session Manager replaces it with IAM-controlled, fully logged access over an outbound agent connection, needing no open ports, public IP, or keys.