I modified the CF template in my environment to resolve this:

  ElasticFileSystem:
    Type: AWS::EFS::FileSystem
    Properties:
      BackupPolicy:
        Status: ENABLED
      Encrypted: 'true'

If you want to do failovers from region to region create a new EFS share in the VPCs, copy the data/caches to it and symlink the data folder to that then you have only what you need during replication between regions and you wont need to mess around with any configuration files being replicated over causing issues.

Don't even use the Stack generated EFS for data like attachments and avatars, just keep it for the cluster config, then you have more control and stability with faster recovery times.

Teddy,

Why does it fail when I try to checkout the above from your Repo ? 

Complains about  fatal: The remote end hung up unexpectedly
Fetched in submodule path 'docs/boilerplate', but it did not contain 33af4906796fd1bbe72adf9cb8df56f1cc8b2e59. Direct fetching of that commit failed.
[root@ip-10-0-136-18 templates]# gh repo clone betterhealthpp/quickstart-atlassian-jira
bash: gh: command not found
[root@ip-10-0-136-18 templates]# git  repo clone betterhealthpp/quickstart-atlassian-jira

I actually have a fork of this that provides this for both Jira and Confluence: https://github.com/betterhealthpp/quickstart-atlassian-jira and https://github.com/betterhealthpp/quickstart-atlassian-confluence. I can submit a PR if Atlassian would consider implementing it.

That's great news Lewis. I will still put this our backlog for future consideration

Hi Mike,

Thanks for the feedback, we have since successfully edited the CF templates to create an encrypted EFS upon deployment, but it would be great if this was available for all out of the box. 

That being said we appreciate the offer of support for any customisations we may make, it's great we have this channel for communication

Lewis

this is good request. but Atlassian will not prioritise cloudformation template over ongoing projects. We will encourage our partner to build this theirselves and own it for customers. Atlassian team can support them during the build process

Hi,

thanks for submit this request.

At the moment we are not able to prioritise any request for cloud formations template, considering the work load and resource needed for this request indicate. That being said, If Clearvison can jump on to the issue and build this V2 for adding value to customers, we will be more than happy to support you by answering any question you have.

Cheers

+1 on Rodolfo's comment.

Trying to migrate from an unencrypted EFS to an encrypted one is providing us challenges, and as stated this is the no.1 request we see from DC customers

Thank you

Hi,

This is our number one request that customers ask us: encryption.
Ideally also on the nodes but at least start with the EFS.

I understand this is a breaking change for existing deployments ¹ and as such cannot be easily changed without breaking them.
So can I suggest that a new template "v2" is created and published to a new URL which new deployments could use.
In the documentation, state that the old one is now considered legacy and should only be used for existing deployments but new ones should use this "v2" going forward and the latest is not backwards compatible.
I do understand that this is not the ideal solution in terms of maintenance and long term support.

Thank you.

¹ From my experience with customers, the Cloudformation is used to deploy initially but then there are considerable changes outside Cloudformation that make doing any change through it like adding nodes almost impossible there is a considered drift status between what the Cloudformation stack states it's deployed vs what really is.