Can we deprecate jump boxes?

[bagira-kr]

Hello,

I see in the example on this page that a jump box exists. The concern is that this could be viewed as a suggestion of a best practice. Jump boxes are largely out of practice in contemporary environments and constrain the toolsets available to service / operations personnel unnecessarily -- as well as constrain orchestration models unnecessarily.

Could we maybe shift this to be reflecting some sort of VPN-based configuration or a rule-driven style requiring domain joined machines or similar for entry into the environment?

While not core to the content topic, these contexts do get absorbed by readers when they are designing if they use the article as a reference.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 5e5ad897-88ad-5298-b9ff-4d988af52466
• Version Independent ID: 8a3904d9-17ed-0ac0-f006-6997095c86bb
• Content: N-tier architecture style - Azure Application Architecture Guide
• Content Source: docs/guide/architecture-styles/n-tier.md
• Service: architecture-center
• Sub-service: cloud-fundamentals
• GitHub Login: @MikeWasson
• Microsoft Alias: pnp

[absheik]

Thanks for reporting - this issue is under review. This is a Microsoft Internal DevOps Bug ID AB#210868

[ckittel]

Thanks @bagira-kr - Generally speaking, we do not create new content with literal jump boxes as part of the architecture anymore, and instead prefer the use of Azure Bastion where possible. When we revisit existing architecture pages, substituting jump boxes with Azure Bastion is in scope for consideration. We do not have a timeline when any specific article will be updated to reflect that shift.

[DixitArora-MSFT]

@ckittel Thanks for providing the clarification.

@bagira-kr For now I will proceed with closure of this and If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[bagira-kr]

I don't understand. Why would we close an issue if it is not resolved.

[DixitArora-MSFT]

@bagira-kr Chad has already made the clarification. Is there anything more you are looking for ?

[bagira-kr]

@DixitArora-MSFT Yes this issue was for deprecation of jumpboxes from the architecture documentation? It was mentioned that there is a general plan but the issue is still outstanding.

As for supplanting jumpboxes with bastion in future revisions, this is not an established or even proven pattern at scale, and something more flexible should be offered as a best practice or even established precedent at market as the same problems exist with bastion for remote access. Forcing users to use a web browser for shell or RDP access is not an acceptable solution.

VPN access with virtual network peering or similar is an established pattern for mid and large environments. Even just an authenticated socks proxy is more heavily used (though I don't recommend it) for entry to an environment than this new service offering only provided by a single vendor -- this a generic cloud architecture problem domain even if it is in the context of MSFT Azure. I think some use cases with system interfacing are not being considered there.

While I can certainly understand the desire to use a MSFT Azure composite service offering, there are more generic approaches that can serve as best practices. Can we explore a "generic first" approach when writing architectural documentation due to safely assumed impact to consumers of that documentation?

[bagira-kr]

(apologies for the repeated edits -- Englishing is hard today)

[caseythechicken]

Agree 100% with bagira-kr. I'm a security person looking at this for the first time, deeply concerning that we are teaching new users a way of doing things that belongs in the 1990s. This promulgates the idea that MSFT and Azure are either insecure by nature or unconcerned with security.

Closing the issue without making a needful change does nothing to fix a very real problem here. Suggest you pull a resource from a security team and update your documentation accordingly.