Migrating on-prem to AWS with ease, using CloudEndure


BlogTech Community

The Why

We at Nordcloud have a multitude of customers that turn to us for migrating their on-premise workloads to a public cloud provider. Every migration case is different, each with their own unique starting points, technical challenges and requirements. Starting with an in-depth assessment of the current environment, we agreed with the customer that most of the workloads will be rehosted to AWS. During this process, the team has assessed the available tooling and services that could best facilitate a smooth and efficient migration. We found CloudEndure to be the best tool for lift-and-shifting more than a hundred servers.

The How

Lift-and-shift, aka. rehost means taking servers as they are in the current environment, and spinning up exact copies in the new environment. In our case the migration was from an on-premise datacenter to AWS. The on-premise datacenter architecture relied on VMware to virtualize the workloads but the decision was made not to migrate to VMWare on AWS, but directly to EC2. CloudEndure’s strength lies exactly in this. It makes the process of creating a snapshot of the server, transferring it to AWS, performing OS level changes – that are required because of the underlying infrastructure change – and ultimately starting the new instance up.

It executes the whole process without affecting anything on the source instance, enabling for minimal cutover downtime. The source doesn’t need to be powered off, restarted or modified in any way shape or form for a fresh copy of the instance to be started on AWS. Our cutover processes fell into a couple categories. For example, if the server in-scope was a stateful one and also required data consistency (eg. self-hosted databases), we first shut down the processes of the application, waited a very short time for CloudEndure to sync the changes to the target environment, then started up the instance in the new environment.

The way CloudEndure works is really simple. You execute the provided script on the source machine which installs and configures the CloudEndure agent. This agent in-turn will start communicating with CloudEndure’s public endpoints, aka. “Control Tower”. You set up a project within the console and the instances will automatically get added in the console. After you see your instance, the replication will start. CloudEndure takes a 1:1 snapshot of the instance and continuously replicates new changes, as long as it’s not stopped manually or the instance is powered off. It offers you an always up to date copy – with approx. 5 min latency – that you can spin up any time with a single button. During the cutover process, the OS level changes are performed. It will also ensure that Windows Servers will be on a licensed AMI. This is especially useful because it eases the burden of licensing, which many customers face. This functionality however is only supported for Windows and no other operating systems. (more on this in the Challenges section)

The Tech

From a technical perspective, CloudEndure’s console [Control Tower] makes API calls on your behalf to AWS services. It doesn’t deploy a CloudFormation stack or need anything special. It uses an IAM access and secret key pair, for which there is a pre-made IAM policy template following IAM best practices. After you set up your project, a Replicator EC2 instance will be spun up in your target region. This instance will be handling the temporary storage of the to-be-rehosted instances’ snapshots. Each disk on each source server [you deploy the agent to and start replication] will be created as an EBS volume and attached to the Replicator instance. You can specify what instance type you want your Replicator instance(s) to be, and I would highly recommend going with AMD based instances. In our experience, they have been noticeably faster in the cutover, plus they’re simply cheaper. Since your Replicator instance(s) will be running constantly throughout the whole period of the migration – which can take a long time – make sure to adjust the sizing to your needs. The second part of the game is the Machine Converter instance, which does the heavy lifting for the changes required on the OS and disk level. It is amazing how well it works, especially for Windows instances. It performs all the necessary modifications that are required by the complete change of the underlying hypervisor. Windows does not lose its domain join in the process either, the new server stands up as if it was a reboot.

From the moment you initiate a cutover from the console [or through the API], it generally takes ~20-30 minutes for Windows instances, and 5-10 minutes for Linux instances to be up and running in AWS. The latest snapshot at the start of the cutover is taken, the machine converter does its black magic, and voila! The new server is up and running.

CloudEndure Demo

In this short demo I’ll demonstrate the process of an instance’s migration. I’ve set up a simple web server on a RHEL7 instance in GCP, which we’ll be migrating to AWS. Here’s the instance in the GCP console, and the contents of its web server.

The source instance in GCP
A very simple web server running on the source

First you create a new project in the CloudEndure console after you sign up. With the plus sign you can create multiple projects. Each project is tied to a single target AWS account. If you want to spread your workloads through multiple accounts, this is a must. Then you paste the pair of access and secret keys for your IAM user, which has the following IAM policy attached.

Paste the credentials of the IAM user here

Then you’re presented with the configuration. This is where you set the target region in AWS and your…well…settings. As I mentioned earlier, I recommend AMD instances and a beefy Machine Converter, as the latter will only run for short periods of time but makes a big difference in speed. Sometimes, you can throw money at the problem. You can also set it to use the dedicated Direct Connect connection so the migration doesn’t impact your regular internet. If you do need to use the internet, you can also restrict the max bandwidth CE will use.

Define your replication settings

Under “Machines” you’ll get the instructions on how to deploy the agent on the source server(s). It’s a simple two liner and it can be non-interactive. It’ll automatically assign the server with the console and even start replication to the target region. Or not, as you can turn off pieces of this automation by using flags during the execution of the install script.

Instructions on how to install the agent on the source machines

In this example I’m running it manually via a terminal on the source machine. You can however put this into your existing Ansible workflows for example.

After the agent is installed, CE can configure everything automatically and also begin the replication by deploying the Replication Server in your region – if there isn’t one already. Each disk on the source servers will be mounted on the Replication Server as a separate EBS volume. Since there is a maximum amount of volumes you can mount to an instance, multiple Replication Servers will be deployed if needed. CE will replicate the contents of each disk to each EBS volume, and continuously update if there are changes on the source disk.

You can monitor the replication in the console

By clicking on the instance in the console, you get to configure the Blueprint for the cutover. This is where you define your target instance’s details. The options are essentially 1:1 to what you’d be able to customize when launching an EC2 instance directly. It can also add an IAM role to the instance, but be aware that the provided IAM policy does not allow that (gotcha!).

Use your preconfigured resources or create new, all can do

After the console reports “Continuous Data Replication” for the instance, you can initiate a cutover any time with the “Launch target machine” button. You can choose between “Test Mode” and “Cutover”, however the only difference between the two is how the history is displayed in the CE console. There is no technical difference between the two cutover types. You can monitor the progress in the “Job Progress” section on the left.

Fire away and lean back to witness the magic – for 8 minutes

This is what the process looks like on the AWS side. Firstly, there was a snapshot taken of the respective [source] EBS volume from the Replication Server. Then the Machine Converter comes in and terminates as it finishes. Finally the cloudendure-source instance is started (even the hostname persists from source).

What a beautiful herd

Navigating to the DNS name or IP of the new server, we can see that the same page is served by the new instance. Of course this was a very limited demo, but the instance in AWS is indeed an exact replica of the source.

Learnings about CloudEndure

  • We only learned about CloudEndure’s post-launch-script functionality quite late in the project. We utilized it once to run a complex application’s migration, including self-hosted databases and multiple app servers. It allowed us to complete the cutover and all the post-migration tasks in under two hours. We have set up and tested the cutover process in-depth. At the time of the cutover this complex environment started in AWS with all the required configuration changes, without any need for manual input. With necessary preparation, this can allow for minimal service disruptions when migrating traditional workloads to the cloud.
  • CloudEndure has more potential. While our team has not explored other usage patterns, it could also be implemented as a disaster recovery tool. Eg. your EC2 instances in Frankfurt could be continuously replicating to Ireland. In case there’s a region-wide, business impacting outage in Frankfurt, you could spin up your servers in Ireland reliably and [most importantly] fast.
  • Windows is better supported than Linux based instances. The migration of Windows Server (from 2008 R2) will also make sure that the AMI of the AWS instance matches the OS. This is important for licensing, but it’s unfortunately not supported on Linux based instances. There were quite a lot of Red Hat servers in the scope of this migration, and we realized that AWS was missing the knowledge that they were running RHEL (the “AMI” in the instance details reported “unknown” essentially). Therefore licensing was not automatically channeled through AWS, and the team had to “fix them” in a timely manner. When we became aware of the issue, we learned that CloudEndure is capable of using pre-made instances as targets instead of creating brand new ones. This way, we could specify the AMI by creating a new target instance with the required details and CE would replace the drives of the instance only, thereby keeping the AMI and licensing. We have tried to use this “target-instance” functionality before but we received errors every time. This isn’t mentioned in the docs, but we found that the IAM policy the CE user has assigned in the AWS account, has limited access to EC2. It uses conditionals that restrict EC2 actions to resources tagged with CloudEndure Creation Time (however, any tag value works). Therefore both the instance and its current disk has to have that tag, otherwise CE will not be able to detach the existing, and attach the new disks to the instance.

CloudEndure; the good, the bad and the small amount of ugly

CloudEndure makes lift-and-shift migrations [to AWS] quite effortless. As we discovered however, it is not as mature as other AWS services, given that CE has been acquired by AWS in 2019. We could rely on it for all our tasks but were presented with multiple shortcomings.

One of these is regarding documentation. It is extensive and covers most scenarios, but not-so edge cases like the “target instance cutover” lacked a crucial part of information (tagging). The other major pain point was the inconsistency of the web interface. There were multiple times where instances reported an up-to-date “continuous replication” state, but suddenly jumped to “replicating…10 minutes left”. This would have been understandable in cases where there was a lot of data change ongoing on the source servers, but it occurred many times where that wasn’t the case. The cutover still proceeds successfully, but seeing the instance suddenly jump to “wait, let me catch up, it’ll take 10 minutes” and shortly after going back to “nope, all good, just kidding” was quite frustrating at times. This was especially nerve wrecking just before a sensitive cutover. The UI can also have inconsistencies, eg. when you save the blueprint, make sure to come back to it and double check that your configuration has been saved. Getting the AMI correct is also limited to Windows Server. Support for other major operating systems would be great, such as industry standard RHEL. The documentation should describe how to fix the AMIs after. Or better yet, how to use the Target Instance ID functionality to avoid this issue.

Get in Touch.

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

    SaaS Business Model and Public Cloud are a Winning Combination for ISVs



    ➡️Ready to join the conversation? Check out the full workshop agenda & sign up! ⬅️

    With the seemingly unstoppable growth of cloud computing, and the rising trend of subscription-based services, many large organisations are committed to purchasing software as a service (SaaS) rather than buying and hosting software internally.

    The already crowded software market is evolving, and industry researchers and commentators are taking note.

    Gartner has for a long time asserted that “by 2020, all new entrants and 80% of historical vendors will offer subscription-based business models”.

    For independent software vendors (ISVs) that built their business around the traditional model of selling licenses and maintenance agreements, moving to SaaS involves changes in everything from their business model, to their development strategies and their own IT requirements.

    Cloud based models allow ISVs to focus on their core goals of developing and delivering applications and improving their customer experience.


    SaaS turns the traditional model of software delivery on its head. Rather than purchasing licenses, paying an annual maintenance fee for upgrades and support and running applications in-house, SaaS allows organisations to buy only the number of “seats” they require at any time.

    This is not only less expensive than the traditional license model, but it also allows them to reduce or increase their software purchases as their needs fluctuate.

    However, SaaS requires ISVs to transform from software developers to services providers. From an operational perspective, this requires new capabilities, such as meeting service level agreements, establishing real-time usage monitoring and billing capabilities and meeting strict security requirements.

    The robust infrastructure required to provide SaaS services 24×7 requires a substantial investment.

    The business challenges are even greater, ranging from the dramatically lower margins provided by SaaS, to changes in cash flow and pricing models, to requirements for customer support.

    Faced with all these challenges, and because there are no standard pricing models, it may at first seem too daunting to embark on this journey. However, your competition may not feel the same way.



    The SaaS model is creating new opportunities for both ISVs and their customers.

    Consumption based charging models enable low-cost-of-entry and low-cost-of-software so clients can experiment with applications that optimise business processes, drive higher efficiency, productivity and growth.

    Cloud based models allow ISVs to focus on their core goals of developing and delivering applications; and improving their customer experience. Tasks like capacity management, infrastructure budget management and platform availability can all be offloaded to a cloud partner; and importantly these costs can be married to usage and revenue for the ISV.

    Potentially other tasks can be offloaded too – ISVs working with a Managed Service Provider can also offload tasks such as patching, replication, redundancy and security. With the right partner the ISV can deliver agility to the DevOps cycle and then rely on the MSP to implement change control, security or compliance enhancements, business continuity and a robust availability and performance SLA for the production applications.

    It may at first seem too daunting to embark on the modernisation journey, however, your competition may not feel the same way.

    Is it right for your software business?

    The combination of opportunities presented by cloud and SaaS business models has expanded the options available to ISVs for software development and delivery; and in turn provided a greater number of options and better value solutions for end-users. The cloud is reducing barriers to entry for new software businesses and allowing existing ISVs to be more agile, customer responsive and innovative.

    Both customers of these solutions and the ISVs themselves stand to gain considerable benefits in transitioning to the cloud and taking advantage of cloud infrastructure and managed services as long as due diligence is undertaken in this transition.

    Nordcloud have helped many ISVs to leverage cloud technologies to effectively transition their business from that of a traditional software vendor to a SaaS provider, and are hosting a series of workshops to share our experiences and help you to decide when (or indeed, whether) to embark on this modernisation journey.

    In the workshops, we will explore the business and technology challenges for ISVs moving to a SaaS model and highlight how effective use of cloud technologies and expertise can overcome many of them by providing entitlement, analytical, billing/payment and security services.

    All ISVs are invited to attend, whether you might be considering taking those first steps, or perhaps you are well on your way and looking for some guidance and advice on best practice…?  Come along and join the conversation.

    Dates & locations 

    Amsterdam, the Netherlands

    12.11.2019, 09:00 – 12:00
    21.11.2019, 09:00 – 12:00
    17.12.2019, 09:00 – 12:00

    Microsoft Nederland

    READ MORE AND SIGN UP (in Dutch)

    Utrecht, the Netherlands

    3.12.2019, 09:00 – 12:00

    REGUS Oorsprongpark

    READ MORE AND SIGN UP (in Dutch)

    Get in Touch.

    Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

      Benefits and risks of lift & shift migration to public cloud



      Lift & shift is a common option for moving on-premises apps in the cloud while avoiding application re-designing. The aim of Lift & shift is to provision, import, and deploy applications and infrastructure resources to match existing, on-premises architecture without modification. Our customer companies choose to lift and shift in order to reduce on-premise infrastructure costs and then re-architecture application once it is in the cloud.  

      Typical example of Lift & shift is copying virtual machines (containing applications and data) and storage files (just data) across the internet into a pre-deployed target public cloud account. Although Lift and shift can be done manually, the process can and should be automated with tools such as AWS Server Migration Service.


      Benefits of Lift and shift cloud migration

      While Lift and shift is not the only way of migrating to the cloud, it can be the fastest and cheapest migration method. Compared to replatforming and refactoring business are limited cost, effort and complexity. Some of our customers also find that it is easier to re-architecture applications once they are running in public cloud, mostly because during the process of migrating the application, data and traffic, they also develop better skills.

      Summary of benefits:

      • Migrate fast to public cloud
      • Reduced risk compared to replatforming and and refactoring
      • Lower initial cost compared to replatforming and and refactoring
      • Thanks to multiple cloud native and partner tools available, the process can be highly automated with limited or no downtime.


      Risks of Lift and shift

      Lift and shift is appeals because it is easiest way of migrating to public cloud, but it isn’t without its risks and opportunity costs.

      Most typical challenge we see with Lift and shift is that existing applications are not properly resized for public cloud, as outside the cloud applications are often over-provisioned for peak load. In worst case scenario the application architecture is not cloud ready or cloud friendly resulting in degraded performance, or operational issues.

      Secondly, just copying applications and data without understanding what’s what, means everything is pulled to the public cloud, including insecure configurations and malware. Therefore lift and shift project should not be conducted with lack of effective security governance, risk management, compliance with company’s security policy.  

      Also actual costs may be more than estimates, which can be caused by inaccurate resource estimates, providers changing prices due to upgrading, or bad performance resulting in the need for more resources.

      Thirdly, applications that are lift & shifted to the public cloud may be able to take full advantage of the cost-efficiencies of native cloud features such as autoscaling and ephemeral computing.

      Summary of risks:

      • Inefficient and expensive cloud consumption.
      • Lack of understanding of the cloud. Inefficiency of work, or data leakage with wrong operation due to lack of cloud knowledge.
      • Poor cost & workload estimation to due to lack of cloud skills or understanding of application data.


      Nordcloud has proven services that can effectively mitigate lift and shift risks. Our post migration capacity optimisation service reduces cloud spend to optimal level and our training and advisory services can train IT organisation and create operating model that leverages cloud benefits. We believe that lift and shift is a valid option for IT organisations that want to progress fast.

      Read about Nordcloud Migration Factory here

      Get in Touch.

      Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

        Migrate to Azure & get 3 years support for SQL and Windows Server 2008. Check our special offer!


        Microsoft Azure

        Microsoft Azure extends support for both SQL Server 2008 and Windows Server 2008 that are quickly approaching their end of support:

        • Extended support for SQL Server 2008 and 2008 R2 will end on July 9, 2019.
        • Extended support for Windows Server 2008 and 2008 R2 will end on January 14, 2020.

        Extended security updates will be available for free in Azure for 2008 and 2008 R2 versions of SQL Server and Windows Server to help secure your workloads for three more years after the End of support deadlineThis means that Azure is an ideal place for older SQL and Windows servers. 


        Here is how to make a business case out of migrating to Azure:

        • Azure costs: using reserved instances, hybrid benefits, rightsizing
        • Extended support cost if left as-is (20% of server license costs per year)
        • Free extended security updates
        • Azure also provides other excellent services for older servers, such as network micro-segmentation, automatic OS patches etc.


        Migrate to Azure with Nordcloud, a Microsoft Azure Expert Managed Services Provider

        Companies need to evaluate the workloads they have running and consider their options to avoid infrastructure and applications going unprotected, dramatically increasing risk to their IT operations. By migrating to Azure, Microsoft will provide extended security updates for Windows Server 2008 for an additional three years. That means protection for workloads plus ability to access the benefits Azure such as flexibility, cost reductions, reduced time to market and access to new services (such as PaaS, AI and ML).

        Nordcloud, a Microsoft Azure Expert MSP, can help you to evaluate your workloads and ensure that you are selecting the best and more cost effective migration process for your at risk workloads.


        We Discover – Migrate – Optimise – Manage

        • Discover: In depth discovery of 25 `VMWare’ hosts, enabling Nordcloud to provide cost analysis for running in Azure and a migration plan.
        • Migrate: Secure deployment of the required Azure infrastructure to ‘land’ your virtual machines. Once you have confirmed that everything is as it should be, Nordcloud conducts the final migration, allowing you to benefit from the security updates though to 2023.
        • Optimise: Once your applications are running smoothly in Azure, Nordcloud will start an optimisation process to ensure you are minimising your costs when running in Azure.
        • Manage: Nordclouds Managed Cloud Services team will manage the Azure infrastructure on your behalf, quickly resolving or escalating any issues that are detected.

        Get our special offer with project details here

        DOWNLOAD OUR OFFER – Migrate to Azure

        You can also read about our migration services here or  contact us directly here.

        Get in Touch.

        Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

          Security in the Public Cloud: Finding what is right for you



          Security concerns in the cloud pop up every now and then, especially when there has been a public breach of some sort. What many businesses still don’t realise is that the public cloud is a shared responsibility, from both the cloud provider and customer. Unfortunately, 99% of these breaches are down to the customer, not the cloud provider. Some of these cases are due simply to the customer not having the competences in building a secure service in the public cloud.

          Cloud comes in many shapes and sizes

          • Public cloud platforms like AWS, Azure and GCP
          • Medium cloud players
          • Local hosting provider offerings
          • SaaS providers of variable capabilities and services: From Office 365 to Dropbox

          However, if the alternative is to use your own datacenter, the data center of a local provider, or a SaaS service, it’s worth building a pros and cons table and making a selection after that.

          Own data centre
          Local hosting provider
          Public cloud
          • Most responsibility
          • Competence varies
          • Variable processes
          • Large costs

          However – Most choice in tech

          • A lot of responsibility
          • Competence varies
          • Variable processes
          • Large costs

          – Some choice in tech

          • Least responsibility
          • Proven competence & investment
          • Fully automated with APIs
          • Consumption-based

          -Least amount of choice in tech

          Lack of competence is typical when a business ventures into the public cloud on their own, without a partner with expertise. Luckily:

          • Nordcloud has the most relevant certifications on all of the major cloud platforms
          • Nordcloud is ISO/IEC 27001 certified to ensure our own services security is appropriately addressed
          • Typically Nordcloud builds and operates customer environments to meet customer policies, guidelines and requirements

          Security responsibilities shift towards the platform provider the more high value services like IaaS, PaaS, SaaS are used. All major public cloud platform providers have proven security practices with many certifications such as:

          • ISO/IEC 27001:2013 27013, 27017:2015
          • PCI-DSS
          • SOC 1-3
          • FIPS 140-2
          • HIPAA
          • NIST

          Gain the full benefits of the public cloud

          The more cloud capacity shifts towards the SaaS end of the offering, the less the business needs to build the controls on their own. However, existing applications are not built for the public cloud and therefore if the application is migrated to the public cloud as it is, similar controls need to be migrated too. Here’s another opportunity to build pros & cons table: Applications considered for public cloud migration ‘as is’, vs app modernisation.

          ‘As is’ migration
          • Less benefit of cloud platform
          • IT-driven


          • You start the cloud journey early
          • Larger portfolio migration
          • Time to decommission old infra is fast
          • Slower decommissioning
          • Individual modernisations


          • You can start you cloud-native journey
          • Use DevOps with improved productivity
          • You have the most benefit from using cloud platforms

          Another suggestion would be to draw out a priority table of your applications so that you gain the full benefits of the public cloud.

          In any case, the baseline security, architecture, cloud platform services need to be created to fulfil requirements in the company security policies, guidelines and instructions. For example:

          • Appropriate access controls to data
          • Appropriate encryption controls based on policy/guideline statements matching the classification
          • Appropriate baseline security services, such as application level firewalls and intrusion detection and prevention services
          • Security Information and Event Management solution (SIEM)

          The areas listed above should be placed into a roadmap or project with strong ownership to ensure that the platform evolves to meet the demands of applications at various stages in their cloud journey. Once the organisation and governance are in place, the application and cloud platform roadmaps can be aligned for smooth sailing into the cloud where appropriate, and the cloud-native security controls and services are available. Nordcloud’s cloud experts would be able to help you and your business out here.

          Find out how Nordcloud helped Unidays become more confident in the security and scalability of their platform.

          Get in Touch.

          Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

            Persisting Docker Volumes in ECS using EFS



            Last week we faced a new challenge to persist our Docker Volume using EFS. Sounds easy, right? Well, it turned out to be a bit more challenging than expected and we were only able to find a few tips here and there. That is why we wrote this post so others may succeed faster.

            Before digging into the solution, let’s take a minute to describe our context to elaborate a bit more on the challenge.
            First of all, we believe in Infrastructure as Code and thereby we use CloudFormation to be able to recreate our environments. Luckily Amazon provides a working sample and we got EFS working quite easily. The next part was to get Docker to use a volume from EFS. We got lucky a second time as Amazon provides another working sample.

            We managed to combine these resources and everything looked alright, but a closer look revealed that the changes did not persist. We found one explanation for why it didn’t work. It appears that we mount EFS after the Docker daemon starts and therefore the volume mounts an empty non-existing directory. In order to fix that we did two things, first we orchestrated the setup and then we added EFS to fstab in order to auto-mount on reboot.

            The solution looks a bit like the following:

                Type: AWS::ECS::Cluster
                Properties: {}
                Type: AWS::AutoScaling::LaunchConfiguration
                      - setup
                      - mount
                          nfs-utils: []
                          content: !Sub |
                            CW_JSON_OPEN='{ "Namespace": "EFS", "MetricData": [ '
                            CW_JSON_CLOSE=' ] }'
                            for COL in 1 2 3 4 5 6; do
                             while read line; do
                               if [[ COUNTER -gt 0 ]]; then
                                 LINE=`echo $line | tr -s ' ' `
                                 AWS_COMMAND="aws cloudwatch put-metric-data --region ${AWS::Region}"
                                 MOD=$(( $COUNTER % 2))
                                 if [ $MOD -eq 1 ]; then
                                   METRIC_NAME=`echo $LINE | cut -d ' ' -f $METRIC_FIELD`
                                   METRIC_VALUE=`echo $LINE | cut -d ' ' -f $DATA_FIELD`
                                 if [[ -n "$METRIC_NAME" && -n "$METRIC_VALUE" ]]; then
                                   INSTANCE_ID=$(curl -s
                                   CW_JSON_METRIC="$CW_JSON_METRIC { \"MetricName\": \"$METRIC_NAME\", \"Dimensions\": [{\"Name\": \"InstanceId\", \"Value\": \"$INSTANCE_ID\"} ], \"Value\": $METRIC_VALUE },"
                                   unset METRIC_NAME
                                   unset METRIC_VALUE
                                   if [ $METRIC_COUNTER -eq 20 ]; then
                                     # 20 is max metric collection size, so we have to submit here
                                     aws cloudwatch put-metric-data --region ${AWS::Region} --cli-input-json "`echo $CW_JSON_OPEN ${!CW_JSON_METRIC%?} $CW_JSON_CLOSE`"
                                     # reset
                               if [[ "$line" == "Client nfs v4:" ]]; then
                                 # the next line is the good stuff
                             done <<< "$INPUT"
                            # submit whatever is left
                            aws cloudwatch put-metric-data --region ${AWS::Region} --cli-input-json "`echo $CW_JSON_OPEN ${!CW_JSON_METRIC%?} $CW_JSON_CLOSE`"
                          mode: '000755'
                          owner: ec2-user
                          group: ec2-user
                          content: "* * * * * /usr/sbin/nfsstat | /home/ec2-user/post_nfsstat\n"
                          owner: ec2-user
                          group: ec2-user
                          command: !Sub "mkdir -p /${MountPoint}"
                              - ""
                              - - "mount -t nfs4 -o nfsvers=4.1 "
                                - Fn::ImportValue:
                                    Ref: FileSystem
                                - ".efs."
                                - Ref: AWS::Region
                                - ".amazonaws.com:/ /"
                                - Ref: MountPoint
                              - ""
                              - - "echo \""
                                - Fn::ImportValue:
                                    Ref: FileSystem
                                - ".efs."
                                - Ref: AWS::Region
                                - ".amazonaws.com:/ /"
                                - Ref: MountPoint
                                - " nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0\" >> /etc/fstab"
                          command: !Sub "chown -R ec2-user:ec2-user /${MountPoint}"
                          command: !Sub "service docker restart && start ecs"
                  AssociatePublicIpAddress: true
                    - AWSRegionArch2AMI
                    - Ref: AWS::Region
                    - Fn::FindInMap:
                      - AWSInstanceType2Arch
                      - Ref: InstanceType
                      - Arch
                    Ref: InstanceType
                    Ref: KeyName
                  - Fn::ImportValue:
                      Ref: SecuritygrpEcsAgentPort
                  - Ref: InstanceSecurityGroup
                    Ref: CloudWatchPutMetricsInstanceProfile
                    Fn::Base64: !Sub |
                      #!/bin/bash -xe
                      echo ECS_CLUSTER=${EcsCluster} >> /etc/ecs/ecs.config
                      yum update -y
                      yum install -y aws-cfn-bootstrap
                      /opt/aws/bin/cfn-init -v --stack ${AWS::StackName} --resource LaunchConfiguration --configsets MountConfig --region ${AWS::Region}
                      crontab /home/ec2-user/crontab
                      /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource AutoScalingGroup --region ${AWS::Region}
                - EcsCluster
            Here is what we did compared to the original AWS provided template:
            1. extracted FileSystem EFS into another CF template and exported the EFS identifier so that we can use ImportValue
            2. added -p to the mkdir command just in case
            3. enhanced mount to use imported filesystem reference
            4. added mount to fstab so that we auto-mount on reboot
            5. recursive changed EFS mount ownership
            6. restarted Docker daemon to include mounted EFS and started ECS as it does not automatically restart when the Docker daemon restarts
            7. added ECS cluster info to ECS configuration
            8. added ECS agent security group so that port 51678 which the ECS agent uses is open
            9. added yum update just in case
            10. included launch configuration into auto scaling group for the ECS cluster and added depends on ECS cluster

            We were a bit surprised that EFS does not require an additional volume driver to function. It appears to work out-of-the-box and turned out to be quite straightforward. Thank you for reading and enjoy using EFS as a means to persist your Docker Volumes in your ECS cluster!

            Get in Touch.

            Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.