Private Administrative Access on AWS: How Private Does It Really Need to Be?

“Keep the database private, but our administrators still need access.”

It is a common requirement.

The resource might be an Amazon RDS database, an internal application, an administration endpoint, or another service that deliberately has no public exposure. Yet DBAs, support engineers, or platform teams occasionally need direct access for troubleshooting or administration.

For years, the familiar answer was some variation of:

Corporate network → VPN → bastion host → private resource

or:

Administrator → SSH → jump host → private resource

Those designs are still valid in the right environment. But on AWS, Systems Manager Session Manager gives us another option: reach a managed node without opening inbound ports, maintaining a traditional bastion entry point, or managing SSH keys.

AWS itself recommends Session Manager instead of SSH or RDP for many administrative-access scenarios.

That sounds like the architecture decision has already been made.

It hasn't.

The more important question is:

How private does the access path actually need to be?

That question changes the architecture considerably.

---

Start with the requirement, not Session Manager

Suppose an organization has an RDS database in private subnets.

The requirement initially sounds simple:

A database administrator occasionally needs MySQL access from a workstation.

There are several ways to solve it.

The database could become reachable through a corporate VPN or Direct Connect network path.

A bastion host could provide a controlled entry point.

A dedicated administrative environment could be placed inside the VPC.

AWS Client VPN could extend private network access to selected users.

Or Systems Manager could provide a managed access path through an EC2 instance that already has network reachability to the database.

The interesting architecture decision isn't whether each option works.

Most of them can.

The decision is about what kind of access boundary the organization wants to operate.

A traditional bastion says:

Permit administrators to establish an inbound network connection to a controlled host.

Session Manager changes that assumption.

The managed node establishes outbound communication with AWS Systems Manager. An authorized administrator asks Systems Manager to start a session. No inbound administrative port needs to be exposed on that node.

That is a meaningful change in the trust model.

But it is only the first layer.

---

The first level: remove inbound administrative access

Consider the simplest Session Manager architecture:

Administrator → AWS Systems Manager → managed EC2

The administrator authenticates to AWS and needs IAM authorization to start the appropriate session.

The EC2 instance runs SSM Agent and has an IAM role that allows it to participate as a Systems Manager managed node.

Most importantly, the instance does not need an inbound SSH or RDP rule for Session Manager access.

SSM Agent initiates its communication outward toward Systems Manager.

This immediately removes several things from the traditional bastion model:

• publicly reachable SSH/RDP;

• inbound administrative security-group rules;

• management of persistent SSH keys for Session Manager shell access;

• direct network reachability from the administrator to the managed node.

For many organizations, that is already a significant improvement.

But there is an architectural detail that is easy to miss.

The managed instance still needs to reach the Systems Manager service.

How?

One option is ordinary outbound connectivity.

A private subnet might route outbound traffic through a NAT gateway, allowing the SSM Agent to reach the public AWS service endpoints over HTTPS.

There is still no inbound Internet access to the EC2 instance.

That means this architecture can truthfully say:

The managed node has no inbound administrative exposure.

It cannot necessarily say:

The managed-node management path has no Internet dependency.

Those are different claims.

---

The second level: make the managed-node path private

Some environments have a stronger requirement:

The managed instance must not depend on Internet or NAT connectivity for management traffic.

Now the architecture changes.

AWS Systems Manager supports interface VPC endpoints powered by AWS PrivateLink. Instead of the SSM Agent reaching Systems Manager through public service endpoints, the relevant service names resolve to private endpoint interfaces inside the VPC.

The architecture becomes conceptually:

Managed EC2 → private VPC endpoint → AWS Systems Manager

The important endpoint in modern Session Manager communication is ssmmessages, which provides the secure data channel used by SSM Agent. The ssm endpoint participates in Systems Manager API interactions as well. Current SSM Agent versions prefer ssmmessages when it is available.

Private DNS is an important piece of this design.

The application—or in this case SSM Agent—continues using familiar AWS service DNS names, while DNS resolution directs the traffic to the private endpoint IP addresses.

This is why a PrivateLink design isn't simply:

“Create some VPC endpoints.”

It is a combination of:

DNS + interface endpoints + security groups + routing + IAM + SSM Agent

Each piece solves a different part of the problem.

With that architecture, the managed node can operate without NAT or Internet Gateway dependency for the relevant Systems Manager communication.

AWS describes this as keeping traffic between managed nodes and Systems Manager on the Amazon network.

Now we can make a stronger statement:

The managed node has no inbound administrative exposure, and its Systems Manager path does not require Internet/NAT connectivity.

That still doesn't mean the complete administrator-to-resource journey is private.

There is another side of the architecture.

---

The third level: what about the administrator?

This is where the word private starts causing confusion.

Imagine an engineer sitting on a corporate laptop and running a command to start a Session Manager session.

The EC2 side might be beautifully private:

EC2 → PrivateLink → Systems Manager

But how did the administrator reach the AWS service?

Potentially through the organization's normal Internet egress path to the AWS public API endpoint.

Nothing is inherently wrong with that architecture.

The session is authenticated and authorized through AWS, and the managed node still has no inbound administrative exposure.

But if the requirement says:

Administrative connectivity from the corporate network must remain on private enterprise connectivity into AWS,

then private VPC endpoints on the managed-node side alone do not satisfy it.

Now we are solving a hybrid networking problem.

The design may involve:

• Direct Connect or Site-to-Site VPN;

• appropriate routing into the VPC;

• interface endpoints reachable from the enterprise network;

• Route 53 Resolver inbound endpoints or another DNS integration model;

• corporate DNS forwarding rules;

• endpoint security groups permitting the required enterprise source networks;

• potentially centralized endpoint architecture in a shared-services or network VPC.

The requirement has changed from:

“Don't expose my EC2 instance.”

to:

“Keep the administrative service path private from enterprise workstation to AWS.”

That is a materially different architecture.

---

Think in privacy levels, not “private or public”

This is the model I find more useful when discussing Session Manager architectures.

Level 1 — No inbound administrative exposure

The managed node has no SSH/RDP ingress.

SSM Agent reaches Systems Manager using outbound connectivity, potentially through NAT.

This is often enough when the primary concern is removing inbound management ports and bastion exposure.

Level 2 — Private managed-node control path

Add Systems Manager interface VPC endpoints.

The managed node can communicate with Systems Manager without relying on NAT/Internet connectivity for that path.

This fits environments that tightly control workload egress or intentionally operate isolated private subnets.

Level 3 — Private enterprise administrative path

Extend the design through corporate private connectivity and hybrid DNS so the administrator's path to the relevant AWS service endpoints also remains private.

This is appropriate where enterprise security policy requires management-plane connectivity to remain on controlled private network paths.

The important point is that Level 3 is not automatically “better” than Level 1 or Level 2.

It satisfies a stronger requirement at the cost of more infrastructure and operational responsibility.

That's an architecture trade-off.

---

Session Manager can reach more than the managed node

There is another useful capability that changes how we think about this architecture.

Sometimes the target isn't the EC2 instance at all.

Suppose the actual requirement is:

A DBA needs temporary access to a private RDS database.

The managed EC2 instance already has network reachability to RDS.

Session Manager supports remote-host port forwarding.

Conceptually:

Database client → local port → Session Manager → managed EC2 → RDS

The RDS instance does not need to be managed by Systems Manager. The managed EC2 instance acts as the network origin for the final connection to the remote host. AWS explicitly supports this remote-host forwarding model.

This gives us a useful architecture pattern:

Use a managed node as a controlled access bridge to a private resource without exposing a traditional inbound bastion interface.

The remote resource could be a database or another TCP-accessible internal service, provided the managed node can resolve and reach it.

But this introduces another boundary architects need to remember.

Session Manager creates the tunnel.

It does not override the downstream network architecture.

If EC2 cannot resolve the RDS hostname, the tunnel will not fix DNS.

If the RDS security group rejects traffic from EC2, the tunnel will not bypass the security group.

If the database rejects the credentials, Session Manager does not change database authentication.

The downstream connection still follows ordinary network and application rules.

---

IAM and network authorization solve different problems

This architecture also demonstrates why cloud security should rarely be discussed as only “IAM” or only “networking.”

IAM answers questions such as:

Is this administrator allowed to start this type of Session Manager session against this managed node?

The EC2 instance profile answers another:

Is this node authorized to participate in Systems Manager?

Security groups answer different questions:

Can the managed node establish HTTPS connectivity to the VPC endpoints?

and:

Can this managed node establish a database connection to RDS?

DNS determines where service names lead.

Routing determines whether the resulting addresses are reachable.

The SSM Agent maintains the managed-node communication channel.

The Session Manager document controls the type of session being requested.

Each component is a small piece of the architecture.

None replaces the others.

This is why troubleshooting the solution by asking only “Is SSM working?” is usually too broad a question.

---

What does Session Manager actually remove?

It removes some operational problems very effectively.

You can eliminate the need for inbound SSH/RDP access to managed nodes.

You can avoid operating a traditional publicly reachable bastion entry point for many use cases.

You can move administrator authorization toward IAM.

You can use short-lived managed sessions rather than persistent administrative network exposure.

With PrivateLink, managed nodes can also communicate with Systems Manager without depending on Internet/NAT access for that management path.

But Session Manager doesn't eliminate everything.

You still need:

• IAM governance;

• SSM Agent lifecycle management;

• endpoint and DNS architecture if using PrivateLink;

• network authorization from the managed node to downstream resources;

• downstream application/database authentication;

• monitoring;

• a recovery strategy if the management agent or control path fails.

Removing SSH also removes a familiar recovery path.

That is usually a desirable security decision—but an architect should immediately ask:

If Session Manager becomes unavailable, what is our controlled recovery mechanism?

The answer might be automated agent recovery, instance replacement, an EC2 recovery process, or a tightly governed break-glass mechanism.

The important part is having an answer before an incident.

---

There is also an auditing trade-off worth knowing

Session Manager can provide centralized session history and can log commands and output for supported interactive sessions.

However, there is an important limitation: AWS does not provide Session Manager session-content logging for port-forwarding and SSH sessions. In those modes, Session Manager is acting as the tunnel and cannot inspect the encrypted application traffic flowing through it.

That matters for architecture.

If an organization requires a complete record of every SQL statement executed during a database administration session, Session Manager port forwarding alone does not provide that control.

Database auditing, application-level logging, or another monitoring mechanism may still be required.

Again, the right question isn't:

“Does Session Manager provide auditing?”

It is:

Which activity must be audited, and at which layer can that activity actually be observed?

---

Choosing the right version of the architecture

When evaluating this pattern, I would start with a handful of questions.

What are we actually protecting against?

Is the goal simply to eliminate exposed SSH?

Or must workloads have no Internet egress?

Or must administrator traffic remain private from the enterprise network all the way into AWS?

Those are three different requirements.

What resource does the administrator actually need?

If the administrator only needs database connectivity, providing a general-purpose interactive shell may grant more access than necessary.

A constrained port-forwarding model may be more appropriate.

Where should authorization happen?

Consider IAM authorization for Session Manager separately from network authorization and downstream resource authentication.

What must be audited?

Session establishment is different from shell command history, which is different again from database query auditing.

What happens when Systems Manager isn't available?

A no-SSH architecture needs an intentional recovery strategy.

How much complexity is justified?

PrivateLink endpoints, hybrid DNS, Direct Connect routing, centralized endpoint architectures, and enterprise resolver integrations are valuable when requirements justify them.

They are not architectural trophies.

Every additional component becomes something that must be secured, monitored, operated, and troubleshot.

---

Validate the boundaries, not just the happy path

Once the architecture is selected, I would not consider it validated merely because someone successfully opened one Session Manager connection.

Instead, verify the important boundaries.

Can the managed node communicate with Systems Manager through the network path you intended?

If PrivateLink is part of the requirement, do the relevant service names actually resolve to the private endpoint path?

Can the administrator establish only the types of sessions they are supposed to establish?

Can the managed node reach the downstream resource on only the required port?

Does the downstream resource see the expected source?

If a downstream security rule is removed, does only downstream connectivity fail while the management channel remains healthy?

If the Systems Manager path is interrupted, does the failure occur where you expect?

And most importantly:

Does the observed network behavior match the privacy claim you are making about the architecture?

You don't need an elaborate test suite to answer those questions.

You do need clear checkpoints.

---

The architecture decision is really about boundaries

Session Manager is often introduced as an SSH replacement.

That's useful, but incomplete.

From an architecture perspective, its more interesting property is that it lets us reconsider where the administrative boundary should exist.

Instead of automatically extending administrator network reachability to every managed resource, we can separate:

identity and session authorization

from:

managed-node connectivity

from:

downstream resource connectivity

from:

enterprise network connectivity

And then make each boundary as private—or as simple—as the organization's actual requirements justify.

For one environment, removing inbound SSH may be sufficient.

For another, private managed-node connectivity through PrivateLink may be mandatory.

For a regulated enterprise, the design may extend through Direct Connect, private DNS resolution, centralized endpoints, database auditing, and tightly controlled recovery mechanisms.

All three can be valid architectures.

The mistake is calling all three simply “private access” without defining what private means.

That is the architectural question worth answering first.

---

Going deeper

This article intentionally stays at the architecture-decision level. I've documented the underlying network paths, DNS behavior, service interactions, and implementation separately for readers who want to go deeper.

Architecture Deep Dive
Private Access to AWS Systems Manager: Understanding the End-to-End Network Path

Architecture perspective
Secure Private Administrative Access on AWS

Hands-on implementation and validation
Private RDS Administrative Access with AWS Systems Manager