Modern Cloud Connectivity and Productivity

When needing to securely connect to cloud services, your private networks and the applications contained therein there are various options to consider. The trusty VPN remains a big part of this connection package – however a well-defined deployment of Amazon WorkSpaces offers a huge advantage to centralise and securely contain development activities, especially for offshore teams.

You just moved workloads to Amazon Web Services, everything is in place and the virtual servers are running in tip-top condition serving your customers. The architecture team, software engineers and QA engineers are eager to start their cloud native modernisation journey… this is where the excitement gets clouded with questions…

How should we develop in the cloud?
How can a local development environment be configured? Should it even be done?
How do we connect to cloud resources (efficiently & securely)?

The answers to the above generally depends on the cloud resources that make up the solution. DynamoDB and similar web accessible resources are easily addressed, however it is just a matter of time before VPC-based resources such as Amazon ElastiCache, Amazon Aurora, or Amazon Neptune makes an appearance in the solution.

During the past few months, this topic came floating to the top of my email conversations, normally highlighting the following two to three requirements:

Development and quality assurance teams require secure connectivity to VPC based resources (private subnets), generally in a DEV and TEST environment;
Scalable solution to get new team members going faster, especially contractors that move onto projects for short periods of time (productivity focus);
Onshore and offshore staff complement, with offshore staff needing a higher degree of information security applied to their development ecosystem.

With so many options to evaluate, it was time to put some of the most common connectivity and productivity options in a single article.

Common Cloud Connectivity Options

We will focus on using AWS Transit Gateway as the primary cloud network backbone to simplify the solutions and target scalable deployment solutions.

Direct Connect

The first option thrown into any conversation is always AWS Direct Connect. A mighty contender for on-premises to AWS network (VPC) connectivity. This option assumes that an on-premises (co-located datacentre) environment is still in use at a Direct Connect enabled location. To use this Direct Connect option, the organisation would still need to operate secure connectivity for staff from both the officeand remote locations to the on-premises environment. Virtual Private Network (VPN) deployments, both site-to-site and client-VPN just got added to the cloud connectivity requirement – that assuming the legacy on-premises environment in the datacentre still exists post migration. An on-premises client-VPN solution is assumed to be in place for most organisations, thus the preference may be to retain this solution and route traffic via Direct Connect. Various other network components such as Direct Connect gateways, routing configuration and hybrid-DNS have been omitted from this article for brevity. A common architecture for this hybrid connectivity is depicted in the diagram below.

Site-to-site VPN

Now, let us assume we went “all in cloud” and the last server in our legacy datacentre was decommissioned. Where does this scenario now leave us with connectivity for our development and testing teams? VPN’s still play a big role here for most organisations and will remain a key part for the foreseeable future, primarily to connect office networks (one or more locations) to private cloud resources. Various commercial vendors offer solutions for site-to-site VPNs (e.g. Fortinet’s FortiGate), however this commercial type deployment will introduce another moving part to be managed for high-availability and redundancy. In true cloud native fashion, we will be making use of AWS Transit Gateway, which offers Transit Gateway VPN IPSec attachments – this deployment is depicted in the diagram below.

Client VPN

Although a good start, the solution proposed above (site-to-site VPN) does not truly address the development team accessibility requirements to develop and test against VPC based resources. This is especially true now that the concept of a remote workforce has been embedded and fully adopted throughout the COVID-19 pandemic. Where does this now leave our development team to deliver a modernised, cloud native version of their migrated legacy application?

Client-VPN is the most common answer to this scenario – once again addressed by various commercial solutions (e.g. Fortinet), which may already be part of your organisations’ arsenal of security tooling, but managing a high-available 3^rd party Client-VPN solution in the cloud may just not be in the operational budget or staff capabilities. Keeping with a cloud native roadmap, AWS offers a highly available managed client-based VPN service that scales with your needs. AWS Client VPN offers several features commonly associated with enterprise solutions, including split-tunnel and active-directory based authentication. A truly cloud native solution without an on-premises component is depicted in the diagram below.

The client-VPN solution depicted address most of the requirements, however it does not fully address a higher degree of information security, and not necessarily improves overall productivity. To deliver on the information security and productivity requirements we need to look further – meet Amazon WorkSpaces.

In summary and simplified definition, Amazon WorkSpaces is a managed Desktop-as-a-Service (DaaS) solution. You can use it to provision either Windows or Linux desktops and scale to provide thousands of desktops to workers across the globe. Amazon WorkSpaces helps you eliminate the complexity in managing hardware inventory, OS versions and patches.

#####Amazon WorkSpaces – a deeper look

Amazon WorkSpaces is not just a solution for basic compute functions and general office staff productivity to replace the common Virtual Desktop Infrastructure (VDI) – the flexibility and available compute options easily support development and quality assurance tasks, with the benefit of supporting high-bandwidth compute requirements for AWS and VPC-based resources. This low-latency and high-bandwidth capability also offers huge benefits for data engineers and business analytics team members when doing local workflow development.

The table below dives into the various facets that make up Amazon WorkSpaces - and why it is a great substitute for desktop-based development and enabling cloud-based development.

Common use cases and benefits

Standard VDI – simple and easy, Amazon WorkSpaces is a Virtual Desktop Infrastructure (or Desktop as a Service) solution - so why not use it for its intended purpose. The major benefit is that Amazon WorkSpaces can be setup in minutes for simple use cases supporting Small to Medium Business development teams and office staff, or it can be deployed as a fully integrated, encrypted desktop environment within the enterprise. Multifactor Authentication (MFA) and Certificate based authentication adds to the security and compliance capabilities of the service.
Contractor and team productivity – how much time is spent on configuring the device of a new team member, especially when laptops are not ready by the time they start. For developers I have seen this happen time and time again. The day they walk into the new office their ordered laptop or MacBook is on backorder. 1-2 days are spent configuring some older under spec device and two weeks later the real device arrives. Just to do it all over. The same can be said when a device needs a replacement or warranty fix. Amazon WorkSpaces easily offers the development team the ability to manage 1-2 standard images (Windows and Linux) – whenever a new team member or contractor starts, a bit of authentication credentials, GitHub config (or AWS CodeCommit credentials) and they are on their way to the races.
Improved information security– perhaps one of the greatest challenges in a modern remote workforce setting is controlling the flow of data, more importantly confidential, sensitive, or personally identifiable data. Given the best of intentions, developers and quality assurance team members eventually find their way to full or partial copies of production data (to test that problem) – this varies from industry to industry and governance plays a big part, however over the years I have been surprised as to what is considered standard practice. Using Amazon WorkSpaces, especially for offshore team members or short-term contractors ensure that any sensitive or confidential data (including source code) remains in full control of the organisation, inside the appropriate network zones, and within the intended geography. Various security features and the ability to control the clipboard (disabling copy/paste from WorkSpaces) enhance the compliance features of WorkSpaces.
Persistent – ever needed to execute a long running task to make sure things works as expected before committing it and raising a pull-request ? For many developers and quality assurance engineers, this happens from time to time and may be very much dependent on the type of services they are building or testing. The answer to this problem is normally to leave the laptop (or MacBook) at the office or kill the test now and restart it from home. This is of course dependant on the home connection supporting the task at hand whilst the family is watching Netflix or Amazon Prime. Amazon WorkSpaces offer a persistent desktop environment with no concerns over consistent bandwidth or accidental shutdown (if AutoStop is not enabled of course)
Bandwidth – this requirement varies from project to project, however at times the need to have consistent high-speed bandwidth to VPC-based resources such as Elasticsearch or Amazon RDS, or public endpoint resources such as DynamoDB is crucial to validate code changes before committing the new feature or fix. This is where Amazon WorkSpaces offer a great advantage over and above a VPN Client based solution.
Access from anywhere– this point is also addressed by a standard client-VPN solution; however, a fully capable development environment can be accessed from any device with the Amazon WorkSpaces client configured, or if enabled, the environment can also be accessed from an internet browser.

To Docker or not to Docker locally

Docker and Amazon WorkSpaces is an interesting topic – at least in theory, if you have access to all AWS services from the workspace, configuring various local mock-services on Docker will be less of a necessity. It is stated as “at least in theory” it is not needed. The type of development being performed, or the tools being used in the process may impact this assumption. How the CI/CD processes are defined may require Docker on the developer device – although it is not best practice to build the image from the developer device, in the real world this does occur. In such a scenario, reviewing the build and deployment processes may be advised.

As a tooling example, Amazon Web Services’ SAM CLI development kit offers an effective test-pack solution when developing Lambda functions. This local testing requires Docker to be installed.

Docker on Amazon WorkSpaces is officially not supported (read not possible) for Windows WorkSpaces. For Linux WorkSpaces, Docker can be configured given some care is taken around the IP-addresses allocated to the containers.

Broadband or networking connection requirements

A common point raised by engineering teams against adopting solutions such as Amazon WorkSpaces is that (a) teams will be tools-down should the network connection be affected and (b) the developer experience will be slow and terrible. The point raised towards the impact of a failed Internet connection is very true, however, unless working exclusively on features that can truly be developed and tested on the local device (with complete façade’s or local mock services in place), not having access to the VPC or Internet based cloud services (AWS services) will have a similar, if not the exact same impact. On the second point, the bandwidth requirement for a smooth and real time local experience is very dependent on what is happening on the remote session and the protocol in use (PCoIP or WSP), however under basic usage for programming related tasks the average streaming bandwidth needed for a good experience is approx. 200-400Kb/s. Should 30-50 staff members constantly access their WorkSpace from an office location, it may place some strain on the broadband infrastructure (or other enterprise networking) – however this is not considered excessive bandwidth requirements by any means and it does trade off any bandwidth that would have been used for development or testing against cloud-deployed resources – which may have large burst capacity needs.

Common deployment model

Amazon WorkSpaces have several deployment options to consider which will be dependent on organisational security principles and overall user management considerations. Some deployment patterns to consider are:

A WorkSpaces domain per AWS Account

A WorkSpaces domain per network zone

- data classification zone (PROTECTED vs. OFFICIAL:Sensitive)

- non-production vs. production

A centralised WorkSpaces domain

Diving into the AWS best practice deployment guide for Amazon WorkSpaces we are presented with a design consideration and deployment pattern that position trusted and untrusted user personas. This pattern offers a higher degree of security and control. This trusted and untrusted deployment pattern can further be combined with the three patterns already mentioned – that is if managing a multitude of AD-connectors and WorkSpaces domains can be accommodated by operations staff.

A best practice deployment pattern is depicted in the diagram below. It highlights the use of two distinct WorkSpaces domains, which can be independently configured to allow or not allow user self-service, different applied security controls, and placement into different network zones (subnets in this architecture). Although depicted as different subnet placements, in practice this could be different AWS accounts or different VPCs.

A few downsides of WorkSpaces

Amazon WorkSpaces is a very versatile Desktop as a Service (or VDI) solution; however, it does come with a few downsides – nothing to kick it to the kerb, but worth noting when considering the most appropriate deployment pattern.

Only one workspace per username (per directory) is supported. For the enterprise with strict named user and identity control, wanting to keep their Active Directory footprint to a minimum, this may be become tricky. A developer or tester may need access to a Windows and Linux workspace, or two workspaces in different security zones (non-prd vs. prd / trusted vs. untrusted / PROTECTED vs. OFFICIAL). In this scenario the user will need to have multiple usernames (e.g. john and john-dev) or multiple directories (Ads) operated for each zone, should the same username need to be used. Onboarding and offboarding may become a challenge with the latter approach.

The timeframe to deploy a fresh workspace is not winning any speed contest – a deployment of a new workspace is around 20minutes, with similar timing when it is rebuilt (reset). Not a major downside unless you are in a big hurry to help a user out.

Building out the enterprise

Various options for our development and QA team have been positioned – so what is the recommendation and best approach for your business you may ask? As always, there is no one solution that fits all use cases and the best approach may just be a good combination of the available services.

In the solution depicted below two connectivity use cases are highlighted. Firstly, users at the office can access applications and services deployed within privileged cloud networks (private subnets). Commonly, these are HR systems, private Wiki’s, and Financial/ERP systems that is best not exposed publicly. Secondly, our development teams can use their Amazon WorkSpaces environment to develop from home or the office, and given the correct setup, our development team can access the private Wiki also from their WorkSpaces environment. In this configuration, our development team will be using their WorkSpaces as a jump host to access the Wiki.

The architecture depicted above has just limited our HR personnel and Financial Controllers who need to do payroll, to either having to work from the office or be issued with an Amazon WorkSpaces environment when working from home. For various reasons such as licensing, cost, and complexity this may not be the best approach for the complete workforce – especially in a larger enterprise, but not impossible for smaller organisations who have very few private applications and limited use for an office-to-cloud site-to-site VPN. Therefore, we need one last option in our connection mix – the trusty Client VPN. Such an architecture is depicted in the diagram below.

With all the puzzle pieces in place – the solution now caters for:

Offshore/Untrusted users & developers – with full control over the device that accesses the privileged networks (WorkSpaces);
Onshore development team – with standardised development ecosystems that improve productivity and vastly improves high-bandwidth development tasks (WorkSpaces);
General office staff (HR, Finance, or developers) to access non-public (private) company applications from both the office and remote locations (site-to-site VPN or Client-VPN)

Conclusion

Amazon WorkSpaces is a competitive solution or replacement for an existing VDI solution to support a remote workforce. Comparing the service to other industry recognised VDI solutions, WorkSpaces offers several advantages such as flexibility (monthly plan with no commitments) and a low-cost start-up with the minimum number of users being one. Although WorkSpaces is a great development environment solution, it is difficult to get away from the trusty VPN requirement when private applications need to be accessed by all staff.amazon

Reader Notes:

The designs herein do not address DNS resolution across the various VPCs, office locations and on-premises locations in detail.
The designs depicted herein, further does not fully address the Identity Providers (IdP) / Active Directory that underpin VPN and WorkSpaces authentication and authorisation management.

This article was written by Jaco Olivier, AWS Practice Lead at AC3 and AWS APN Ambassador.

How can we help you?