How to connect to JIRA aws quickstart ec2 server without bastion?

[Sebastian Kouba]

I'm looking at the AWS Quickstart for JIRA. It puts the App and DB server into a private subnet but doesn't include a bastion instance. The confluence template does use a bastion instance which makes it possible to connect to the app server through the bastion.

How am I supposed to connect to the Jira app ec2 instance without a bastion server? Am I missing something?

Cheers

edit: My personal opinion... To other potential AWS / Atlassian users... I would not consider the templates production ready without modification. There are obvious things like missing bastions and other silly things. The core mechanisms work and the apps start but look out for things like a 3600s load balancer timeout on the Jira Loadbalancer and other fun things to mess with the setup.

The templates should be considered mostly as inspiration to make them your own.

[Steffen Opel _Utoolity_]

Hi Sebastian,

We (Utoolity) are currently improving the public AWS Quick Starts for Atlassian products for our own needs, with a primary focus on cost reduction for development scenarios, and a secondary focus on UX/DX in terms of consistency across all products (many differences seem to be arbitrary indeed).

We have made resp. changes across the board, for example the option to use a shared bastion host within a shared VPC, which implies enabling a bastion host for Jira in the first place (see pull request #5). We have also added options to use EC2 spot instances and a free ACM SSL certificate, plus a few other changes (see the merged pull requests for details).

You can find our ongoing work in the 'utoolity' branches in the Utoolity AWS Quick Starts (Labs) project on Bitbucket (also mirrored to GitHub):

• quickstart-linux-bastion
• quickstart-atlassian-bitbucket
• quickstart-atlassian-confluence
• quickstart-atlassian-jira

While we hope to merge some of our changes into Atlassian's actively worked upon upstream versions at https://bitbucket.org/atlassian/atlassian-aws-deployment/ down the road, those are too much in flux currently to make this viable, which is why we have been basing our changes on the older published versions maintained within the https://github.com/aws-quickstart/ organization instead (thus requiring some overlapping changes, e.g. instance type updates).

I hope it goes without saying that these changes are work in progress, unsupported, and unfortunately also undocumented right now due to lack of time for a summarizing blog post or so. In other words, you probably need to consult the commit history to infer details about a particular difference to the official version, and referencing our forks here is not a commitment to quality of life improvements of any kind ;)

[Sebastian Kouba]

Hi Steffen,

thanks for providing so much information and links! We're also making a bunch of changes in a similar direction. We're trying to stay close to the official recommendations so we can rely on official support but as you have also noticed there is room for improvement with the official cloud formation files. 

Hopefully I'll have time to compare notes with what you guys are doing and maybe contribute.

Either way thanks for posting since it will probably be useful for others as well. 

Unfortunately I haven't received any emails from Steve thus far. 

[Daniel Eads]

Hi Sebastian,

If your internal subnets are addressable, you should be able to connect using the public address and the PEM provided in the AWS console. Sounds like you may have been down this road already and the subnets aren't addressed externally though. If that's your situation, the recommended approach is spinning up another instance that is addressed externally and using that to hop to your internal boxes. Sounds like a DIY-bastion server right? Documentation for doing this with the Jira Quickstart is available here if you'd like to read it.

I'll follow up with our team to see why the templates differ. In the meantime, yes, it's likely you may need to spin one up.

Cheers,
Daniel

[Sebastian Kouba]

Hi Daniel,

thanks for getting back to me.

The private subnet which contains the JIRA server is, well, private so not accessible. That was my assumption which you seem to have confirmed. I would have to spin up a bastion in the public subnet and allow the jira instance to be accessed from there.

That's exactly the setup in the confluence cloudformation template. It's what I expected. AWS / cloudformation is pretty complex though so I wanted to make sure I'm not missing anything in terms of reasons for the architecture. So far it seems the difference between Jira and Confluence is arbitrary...

We're (Anarcon GmbH) Platinum Atlassian Partners in Munich and have a large client looking to deploy into AWS. I'm currently going through the templates and this isn't the only perceived oddity (SSL Cert being addressed by name is another that comes to mind). If anybody on the Atlassian side is willing I'd be keen to talk about the templates and what seems odd to me. We're deploying Jira, Confluence and Hipchat...

Cheers

[steve]

Thanks for the feedback on this. 

Firstly, you are correct there is no bastion host on AWS. In order to connect to the individual nodes to administer, or control them you have a few options:

• Add an internet gateway/modify the routing table to allow the hosts to connect (not recommended).
• Use the AWS VPN to connect to your VPC.
• Build a bastion host.

We are constantly looking for ways to improve our AWS offerings and so I've marked this as a feature request, https://jira.atlassian.com/browse/JRASERVER-67550 

RE: Your other notes, I'm happy to have a chat, I'll send you an email to kick off the conversation.

Steve.