Migrate Data from AWS to Azure

Azure and AWS both offer reliable, scalable and secure hosting environments for enterprise workloads in the cloud. Many organisations have already adopted a “cloud first” policy to leverage these benefits and have gone all-in with either Azure or AWS. But what if something changes and a company wants to leave that cloud service provider?

Why Move from One Cloud to Another?

Reasons why users in Azure or AWS would want to switch to the competing cloud service provider include:

1. Changes in the terms and conditions: Initial cloud adoption for enterprises often depends on a unique value proposition offered by a vendor. However, changes in the terms and conditions of a cloud service provider over time could lead to cloud lock-in concerns for organizations.

2. Application portability: Another example of cloud lock-in possibility is the use of heterogeneous platforms used by different cloud vendors which can affect application portability. For example, workloads that use AWS community-contributed Amazon Machine Images (AMIs) or applications configured to make Amazon S3 API calls might limit the ability for enterprises to use other services outside of AWS. In such a case, it might be desirable to migrate out. Another lock-in example is how Azure Site Recovery provides automated mechanisms for moving workloads from AWS to Azure, but requires multiple complex manual steps or third-party tools to migrate in the opposite direction.

3. Contract renewal: Organizations often reevaluate hosting options during the contract renewal period to explore differentiating features offered by competing service providers. With new products and features being introduced by cloud service providers, customers have more choices than ever before to choose an optimal hosting platform for their applications.

4. Cost-benefits: Services offered at premium rates by one service provider could be available at competitive rates with a different provider. For example, Azure Hybrid Benefit along with reserved instances can provide up to 80% cost saving and offers a great value proposition for organizations with pre-existing investments in Microsoft licenses. AWS, on the other hand, provides Microsoft Licensing on AWS, in which customers can use their Microsoft licenses with or without Software Assurance to reduce cloud hosting charges.

5. Compliance standards: The compliance standards to be met for hosting data and application with a cloud service provider or on-premises varies across different industry sectors. Any instance of non-compliance flagged during an audit could lead to re-hosting or migration of application/data to a compliant platform.

6. Data consolidation: In hybrid cloud architectures, a company’s data could exist across public/private clouds or on-premises deployments. Consolidation of data and seamless management is important for optimizing the spend on data storage and operations. One example of this is in the case of M&A (Mergers & acquisitions), where companies with different platforms need to consolidate.

Cloud Migration Challenges between AWS and Azure

Data is the nexus of enterprise IT, and migration from AWS to Azure and vice versa is one of the most challenging aspects when implementing multicloud architectures. Let’s look at some of the challenges.

1. Data Migration: The fact that Azure and AWS use proprietary storage offerings and APIs make the data migration process complex. Leveraging third party tools for data transfer could lead to integration challenges as both the platforms use diverse technologies in the backend. And the entire process of transitioning between the two clouds may not be a feasible option for business-critical applications due to time and cost constraints involved.

2. Secure Data Transfer: Secure transfer of data between Azure and AWS should be done using a process that meets industry-specific governance and compliance standards. Direct download and upload of data can lead to security concerns as the data at rest and in transit should always be encrypted. While Azure Site Recovery offers a feasible solution for large scale secure migration between AWS and Azure, it requires additional infrastructure to be set up in AWS, which may not be feasible in cost-sensitive environments.

3. Access Control Privileges: When data is migrated between AWS and Azure platforms, administrators need to ensure that consistent data access and protection policies are applied in the destination as well. Security and access control are configured using different sets of tools and policies in AWS and Azure. While AWS depends on IAM user policies and resource-based policies for Amazon S3 access, Azure storage uses RBAC assigned to Azure AD users. Hence, redesign and reconfiguration of the entire system might be required to maintain the same level of security after migration. Management of data across AWS and Azure environments using unified tools and interfaces is also a major challenge.

4. Other Challenges: There are a few other additional challenges to the migration process between platforms. It will be necessary to find a way to evaluate the costs and calculate the differences. You’ll also need a way to measure and maintain the same or acceptable performance and SLA’s of different devices, instances, VM’s, storage types, etc. on the new platform.

Please follow and like us:

Supporting Azure in the Terraform Module Registry

After this was announced last year I have been itching to find the time to contribute – Now I finally have to support Azure.

My Module creates a VM and installs Active Directory, it can be found here.

For those of you who haven’t heard of it, The HashiCorp Terraform Module Registry gives Terraform users easy access to templates for setting up and running their infrastructure with verified and community modules.

 

Please follow and like us:

Build an FTP Site in Azure with Azure Storage File Share

If you want to host an FTP site in Azure there’s currently not a dedicated resource for this so the next best option is to spin up a virtual machine and use IIS for running the FTP site. It’s also possible to set the FTP site to use an Azure Storage file share to host the files.

Virtual Machine

When you create your VM  you will also need to allow traffic on port 3389 to allow you to remote desktop into it.

Once your VM has been provisioned go to it’s networking settings in the Azure portal and add port 21 and the range 9990-10000 to it’s inbound ports.

Azure Storage File Share

Within the Azure Storage account that’s created when you provision the VM go to Files and add a file share, when this has created click on it in the portal and then click Connect, this will open a blade containing PowerShell commands for adding the file share as a UNC drive to a Windows machine, copy this code and save it somewhere as you’ll need it soon.

IIS

Log into the VM using the admin credentials set at creation and open PowerShell, run the code copied from the file share blade in the Azure portal to add it as a UNC drive.

Next you need to install IIS on your server, this can be done from the Server Manager dashboard by choosing Add Roles and Features from the Manage menu.

  • Proceed to Installation Type step and confirm Role-based or feature-based installation.
  • Proceed to Server Roles step and check Web Server (IIS) role. Note that it is checked already, if you had IIS installed as a Web Server previously. Confirm installing IIS Management Console tool.
  • Proceed to Web Server Role (IIS) > Role Services step and check FTP Server role service. Uncheck Web Server role service, if you do not need it.
  • Proceed to the end of the wizard and click Install.
  • Wait for the installation to complete.

In order to have your FTP server play nicely with the Azure Storage file share you need to create a user capable of logging into the file share as the UNC path needs to be referenced rather than the mapped drive used within Windows which was added by the PowerShell commands above, as explained here.

Users can be added though Tools > Computer Management in the Server Manager. The username should be the name of the storage account and as usernames can’t be over 20 characters long or have the same name as the VM this is the reason for the restrictions in naming our storage account earlier. The password should be the access key for the storage account and “User cannot change password” and “Password never expires” should be selected. This user should then be added to the IIS_IUSRS group.

Once the connecting user has been added you need to create the FTP site, this is done from Tools > Internet Information Services (IIS) Manager in the Server Manager.

First add the ports that you opened in the Azure Firewall to the FTP Firewall Support setting at the server level, the external IP address should be that of your VM.

Next, right click in Sites and add a new FTP site, the physical path parameter should be the UNC path to your file share, rather than the drive alias used by Windows.

When creating an FTP site you should disallow anonymous authentication and use basic, users can be granted access by adding them in the local users step above an either assigning them to a relevant group or just granting all users of the machine access to the FTP site.

You will now have an FTP site set up and available but if you try to connect to it you’ll get an access denied error, this is because FTP on IIS fails to pass through the credentials and so you need to set these explicitly. This is done from the Basic Settings dialog in the right hand menu bar of the FTP site, within the connect as section of this enter the username and password of the user you created earlier (this will be the name of your storage account and the access key), once done save and then test the connection settings.

The FTP site should now be up and running and uploaded files saved on the Azure file share!

 

Please follow and like us: