nobeastsofierce - Fotolia


Cloud lock-in tops list of AWS cons for adoption

One benefit of AWS is it's a quick and easy way to spin up resources. But cloud lock-in can be a serious concern for enterprises that go all-in on AWS.

AWS can be a guilty pleasure for enterprise IT. It's easy to use and convenient, which often means IT teams find...

themselves tangled in its web of proprietary cloud services.

AWS offers everything an enterprise wants -- from multicore virtual machines with solid-state drives to a machine learning engine. The public cloud provider entices customers with higher-value services tailored to various constituencies -- IT admins, developers and business managers -- and compels them to expand their AWS use. But AWS cons exist; depending on multiple AWS cloud services creates the possibility of lock-in.

What happens when AWS changes its terms of service, experiences reliability issues or a security breach, or doesn't offer a specific feature that would put your company ahead of its competition? It's a question that haunts many AWS adopters.

AWS cons and lock-in risks

Cloud lock-in can sneak up on an organization. It starts small and quickly grows into a problem. There are several warning signs that your organization risks an AWS lock-in problem.

First, extensively using proprietary AWS cloud services and APIs in custom applications can create issues. Although many don't see this as one of AWS' cons -- and the public cloud provider doesn't embrace this categorization -- AWS is a platform-as-a-service (PaaS) stack. Like other application platforms, it's difficult to disentangle code from the platform after architecting complex, n-tier applications around cloud services that don't have comparable competitive offerings.

Weigh the future portability of an application against the convenience of lock-in services, such as Lambda serverless computing; CloudFormation and Elastic Beanstalk orchestration; or ElastiCache, Kinesis Streams and Elasticsearch big data tools.

Enterprises also should avoid building admin processes around AWS-specific services. This mistake is the IT equivalent of architecting applications around the AWS PaaS. Although proprietary services, such as CloudFormation, CloudWatch and CloudTrail, are valuable tools for monitoring and managing resources, they can be a source of AWS lock-in when used indiscriminately and without an eye toward building multicloud processes.

AWS-specific services make it difficult to move to IT automation tools elsewhere. Consolidating large data repositories in storage services that are expensive and time-consuming to move elsewhere is a mistake. AWS makes it more convenient and cheaper to ship data into AWS than to get it out of AWS.

Finally, uncontrolled, unmonitored use of AWS can feed into lock-in. Freewheeling AWS consumption allows Elastic Compute Cloud instances to sprawl, spawning large numbers of orphaned or underutilized VMs. In addition, some applications become dependent on seldom-used rogue or unauthorized services and fail if those services are decommissioned.

Avoid AWS cloud lock-in

Mitigating the AWS cons around lock-in doesn't necessarily mean eschewing innovative, higher-level services that make AWS so powerful. Instead, it requires mindfulness and planning to ensure you don't paint yourself into a corner. Follow these six points when building out your cloud environment on AWS.

Enterprise IT must keep AWS cons, such as cloud lock-in, top of mind when making decisions about AWS use. Don't unwittingly build applications, management processes and data lakes that are difficult to migrate. Insulate application design from cloud implementation; don't create infrastructure or topology dependencies. Design applications with a cloud-agnostic layer that isolates custom application code from AWS-specific services and API calls. Don't use native AWS APIs directly.

Use open, portable third-party alternatives to AWS-specific features. For example, it's possible to run the Google Kubernetes container manager to orchestrate containerized applications on AWS. In addition, if you don't design cross-cloud portability into applications from the start, confine AWS use to core infrastructure as a service and limit the use of application platform services.

Use a hybrid cloud data architecture that maintains master copies of business data on site and replicates or caches it to AWS using Direct Connect or a virtual private cloud. And automate processes with a cloud-agnostic configuration management software, such as Ansible, Chef, Puppet or Salt. Chef is the logical choice for AWS because AWS OpsWorks uses Chef recipes that can be easily ported to a stand-alone Chef instance or Chef-compatible service on another cloud.

Finally, implement processes and controls that limit ad hoc use of AWS and eliminate shadow use that can create hidden application dependencies and lock-in. Exploit services that facilitate IT governance -- the AWS Service Catalog, Identity and Access Management, managed policies and IAM groups.

An inherent trade-off between freedom and convenience becomes apparent when discussing AWS cons and cloud lock-in. Obsessively trying to avoid AWS lock-in has downsides, such as decreased productivity, stunted capabilities and added costs. Organizations must always consider how deeply embedded they want to be with a single vendor.

Next Steps

AWS faces competition in public cloud services from two main sources: Microsoft's Azure platform and the Google Cloud Platform suite. Compare the three on overall suitability for the application and IT team, storage offerings, cost and other factors before committing to one.

Dig Deeper on AWS instances strategy and setup