Cloud connectivity – optimising traffic to Office 365 and remote access to on-prem applications

With the move of large numbers of university and college staff and students to working from home there has been a significant shift in traffic flows across Janet.

Microsoft have released guidance, How to quickly optimize Office 365 traffic for remote staff & reduce the load on your infrastructure, about how to optimise these new traffic flows and avoid unnessecary traffic flowing across your institutional networks and Janet. In short, if your staff, and possibly your students, are currently forcing all traffic through a VPN to your site, strongly consider split tunnelling in order to route any Office 365-related traffic directly over the Internet.

The article describes:

“the simple steps an organization can take to drastically reduce the impact Office 365 traffic has on the traditional corporate infrastructure when we have a large percentage of users working remotely all at once. The solution will also have a significant impact on user performance and also provide the benefit of freeing up the corporate resources for elements which still have to rely on it.

Most remote users who are not using a virtualized desktop will use a VPN solution of some sort to route all connectivity back into the corporate environment [i.e. your institutional network] where it is then routed out to Office 365, often through an on premises security stack which is generally designed for web browsing.

The key to this solution is separating out the critical Office 365 traffic which is both latency sensitive and that which also puts enormous load on the traditional network architecture. We then treat this traffic differently and use the user’s local internet connection to route the connectivity directly to the service”.

To summarise, it is inadvisable to route traffic that is destined for Office 365 via your institutional network using a VPN.

In a related article, Remote access to on-premises applications through Azure Active Directory’s Application Proxy, Microsoft describe how to provide secure access to on-prem applications via their Application Proxy without using a VPN. Note that such access is limited to applications that fall into the following areas:

  • Web applications that use Integrated Windows Authentication for authentication
  • Web applications that use form-based or header-based access
  • Web APIs that you want to expose to rich applications on different devices
  • Applications hosted behind a Remote Desktop Gateway
  • Rich client apps that are integrated with the Active Directory Authentication Library (ADAL)

Did you know?

Jisc are now offering weekly drop-in clinics to help our members with technology issues related to dealing with the coronavirus outbreak. We can also make limited amounts of free consultancy available to you (typically up to 3 hours) to help with the crisis. Consultancy will be provided by one of our cloud consultants, solutions architects or engineers. In all cases, these offers are for help with Office 365, Azure, AWS, cloud security or cloud connectivity.

Want to know more? Please contact your account manager.

Microsoft Azure and Office 365 resourcing issues

As must be clear to everyone by now, there has been a massive spike in demand for public cloud services since the coronavirus outbreak first hit us. Microsoft report that whole countries have gone from zero use of cloud to deliver teaching to 100% coverage of cloud-based remote learning in a matter of weeks. MIcrosoft Teams has probably borne the brunt of that demand.

It is therefore not surprising that we are beginning to see the first signs of resourcing problems. Yesterday, the Register reported that ‘Azure appears to be full’: UK punters complain of capacity issues on Microsoft’s cloud and I’ve seen similar reports elsewhere.

If you get errors when trying to provision VMs on Azure, the advice from Microsoft appears to be:

  • Wait and try again from time to time to see if the resources get released
  • Attempt to recreate the VM in the same region but with a different sizing
  • Attempt to recreate the VM in another region.

Obviously the last of these needs to be treated with some caution. Although all Azure regions are built to the same level of compliance there are obviously factors to consider with relocating data: for example, although the EU Model Clauses and Privacy Shield are recognised as GDPR-compliant, they are likely to require ongoing monitoring by the data controller.

That said, a recent blog post on the Information Commissioner’s Coronavirus blog says:

“We are a reasonable and pragmatic regulator, one that does not operate in isolation from matters of serious public concern. Regarding compliance with information rights work when assessing a complaint brought to us during this period, we will take into account the compelling public interest in the current health emergency.”

Remember that the cloud providers are prioritising government and emergency services use of the cloud.

Freeing up capacity for emergency health service use by temporarily moving less critical stuff to less-stressed regions seems to chime very well with that “compelling public interest”. Though, in the current emergency, are there any regions that are “less-stressed”?

Note that I do not believe that Microsoft will move data out of the region into which customers have put it – however, what customers choose to do is their decision and we may well be tempted to created resources outside of our normally prefered regions in response to the current crisis.

To the above three pieces of advice, I would add two more:

  • Turn off any VMs that are not required for production workloads. That will save capacity for others.
  • For production workloads, i.e. for things that you cannot afford to lose, turn off any tooling you have that auto-powers VMs off overnight – otherwise you may find that those VMs cannot be powered back up the next morning.

Sorry, I appreciate that these are both very obvious. But the main point is that we all need to provision resources carefully and being mindful of the wider impact on others. Otherwise we just become part of the problem.

Clearly, capacity issues in Azure will affect, and be affected by, capacity issues in Office 365. Microsoft have scaled their Office 365 capacity vastly, particularly in response to increased demand for Teams. Therefore, many of the same considerations will apply. That said, I’m unclear around best practice here, specifically in terms of how to provision Office 365 resources in order to minimise the impact on underlying services. As Office 365 is delivered as SaaS we, as customers, have relatively little control over the underlying resource allocation. But Microsoft are making adjustments to various features to maximise utilisation.

In all cases I would advise strongly against panic buying. We all know where everybody buying too much toilet roll gets us.

(Thanks to my colleague Andrew Cormack for advising on the GDPR-related aspects of this post).

Delivering your applications with AWS AppStream 2.0

One of the more recent inventions has been ‘streaming applications’. While the term sounds fancy, it is a relatively old technology – repackaged. Before I go into the specifics of AppStream 2.0, I would like to delve into the history of remote delivered content.

Back in the mid ‘80s, a range of technologies started emerging. While their implementations differed, they all did the same thing – delivered remote desktop to local clients. These ranged from Unix’s X Window System (X11) and commercial products, such as Norton’s pcAnywhere.

Fast forward a few years to the internet boom era of the-mid ‘90s and a new service was launched that allowed everyone to send and receive emails for free(!) It was, of course, Hotmail – a web application delivered to the user via their web browser. One of the unique features for its time was that it allowed access to their emails from any internet connected computer. There was no need to set up <insert_email_app_of_your_choice_here> with POP3 and SMTP settings.

The same year that Hotmail came out, Windows NT 4.0 was released to the public. One of the new features – for Microsoft, at least – was something called Terminal Services (TS). It did the same thing that products of the 80s did – allow remote server administration using a GUI. The technology was licensed from Citrix, which was based on their WinFrame app. A variant of the same component is still in use today and is now known as Remote Desktop Services (RDS).

Unlike Virtual Network Computing (VNC) based solutions, such as X11, which plugged into remote server’s framebuffer and sent the whole image across to the client, TS worked by sending descriptors of windows positions, sizes and styles. The client would then draw the desktop on a local computer using these descriptors. The result was that it was very responsive, even over slow connections – remember 56k? – compared to VNC.

All of the above technologies do similar things, but each has different use cases and different pros and cons. Web applications are centrally delivered and are easily accessible. However, they are difficult to port from their desktop variants. For example, Office 365 has several codebases for their set of applications; one for Windows, one for Mac and one for web. All have different functionalities, features and bugs, despite being the same set of apps. A web application itself may have different functionalities depending on the browser that they are being viewed on.

Remote desktop overcame limitations of web apps at the expense of more complicated management. On-prem based RDS solutions tend to rely on large servers, such as Citrix or Windows, with a set of applications available to the user. It comes with access challenges, such as requiring a user to log on to corporate VPN. There is also the management of the RDS infrastructure itself, such as OS, firmware and app updates as well as taking care of hardware failures.

This brings us back to AppStream 2.0, the streaming application service from AWS. It combines the idea of a web app with remote desktop. Why ‘streaming’? Well, just like streaming video, AppStream 2.0 uses H.264 compression to deliver a video of the application to the user’s browser window. This has more similarities with VNC than the descriptor-based RDS. The desktop’s framebuffer is captured, compressed and sent over the internet to the user. Compression rates change according to the available bandwidth to allow for a consistent user experience.

Why ‘application’? Unlike remote desktop services, such as AWS Workspaces, only the application window is streamed across to the user, rather than the entire desktop. This allows administrators to define one or more applications that a user can run from the AppStream 2.0 session.

So, what are the use cases and benefits?

Use cases:

  • Remote delivered computer lab and distance learning. Rather than having each computer set up with a set of applications on site, AppStream 2.0 sessions are created from a single image that is only created once. The students can then access the applications from their own computers.

Application selection:

Firefox, FreeCAD, Eclipse and Notepad++ Windows application running within a Chrome browser window on a Mac:

  • Demos and trial software. With AppStream 2.0, it is possible to create a time limited link to allow anyone to try out a piece of software, without having to download and install it.
  • Deliver your application using SaaS model without rewriting it.


  • Accessible from virtually any internet connected computer.
  • Centrally managed applications.
  • Consistent user experience – each user will have the same set up.
  • Persistent user storage for saving files.
  • Pay As You Go (PAYG) model to manage costs.
  • Wide range of specification available, including GPU enabled instances for graphic-intensive applications.
  • No need to install or troubleshoot applications on user devices.
  • Full integration with other AWS services, such as IAM and Managed AD.

We have helped a number of organisations to implement AppStream 2.0. If you think that you may benefit from the this technology then do get in touch.

Protecting your workloads behind AWS CloudFront

If you run a website serving static data and need a caching solution, AWS CloudFront is the go-to service for this. It works by providing multiple ‘edge’ locations, which are simply data centres located in geographical hot-spots around the world. Data is accessed from the nearest data centre. For example, when accessing your London-region hosted website through CloudFront in Australia a user will be redirected to their closest edge location. If there is already a cached version of the website, CloudFront will deliver this content without having to request it from the origin in London. Not only does this offer improved performance for your end-users, it also reduces load on the origin servers.

CloudFront also offers additional security. Among its many features, it only allows layer 7 traffic through, which protects origins from layer 4 vectors of attack. Additionally, it allows a Web Application Firewall (WAF) to be associated with the distribution, offering further layer 7 protection.

A layer 4 Distributed Denial of Service (DDoS) attack operates at transport layer of the TCP stack. A common method is to flood the site from multiple locations with SYN requests – part of the three-way SYN (client) -> SYN ACK (server) -> ACK (client) handshake – until all its resources are consumed waiting for the ACK packet from the client that never arrives. As CloudFront never passes layer 4 to the origin, the site is protected. (AWS Shield does go some way to detect and mitigate such attacks outside of CloudFront).

A layer 7 DoS attack operates at a specific application protocol level, such as HTTP. An HTTP attack may involve sending a large number of GET requests to the site, which would eventually become overwhelmed and unresponsive. CloudFront can potentially mitigate such attacks naturally by simply returning cached versions of the requested objects. It can also block malformed HTTP requests. The addition of a WAF to CloudFront would provide additional protection against various other attacks, such as SQL injection that aim to steal or corrupt data.

The distributed nature of CloudFront means that every edge location will have a different IP address range. These ranges frequently change as new edge locations are constantly added to the mix.

This means that origins need to permit access from a wide range of locations, which would require them to be open to all IP addresses at Security Group (SG) and Network Access Control List (NACL) levels. From security point of view, this poses an issue. While origin details are never revealed via CloudFront, there is still a possibility of finding them by randomly scanning IP addresses. With CloudFront bypassed, its security and performance benefits are too.

There are a number of ways to only allow CloudFront into your origins. For S3, it is possible to enable Origin Access Identity (OAI) at distribution level, which would only allow CloudFront traffic to S3 buckets. This can be configured when creating your distribution or distribution behaviour.

For Load balanced traffic using ELBs, while there is the usual AWS WAF and AWS Shield bundle that can be applied (Shield is deployed on all services automatically). Shield Advanced offers additional protection – at a price. However, none of these solutions would deny access to traffic outside of CloudFront.

A possible solution would be to apply custom headers at CloudFront level using Lambda@Edge and filter traffic to the ELB through a WAF, looking for these headers. However, headers can be spoofed, and it would add an overhead (however small) of having to tag each packet with the header.

The other common solution is to restrict traffic via a SG. However, keeping the SG updated would traditionally be an ongoing manual task and the maintainer would need some way to keep track of when IP address ranges for CloudFront change.

At Jisc we have come up with an automated solution to this problem. Luckily, AWS supply a ready-made SNS topic, which provides notifications when those IP addresses change. AWS also supply a list of all IP address ranges used by CloudFront in a JSON-formatted file.

The SNS topic, as well as triggering an email, can trigger a Lambda function. We have taken advantage of this and have created a Lambda function which downloads the updated JSON file, compares its list to the IP addresses in a SG and will automatically update the SG, if necessary. One of the challenges we faced is that a single SG, by default, has a limit of 50 rules. At the time of writing, there are 68 CloudFront IP ranges, which wouldn’t fit into a single group. One way to mitigate this is to have this limit raised by AWS, however, there is always a chance of the limit being breached as more CloudFront locations come online and the cycle would repeat.

A longer-term solution is to split the SG into two or more groups and maintain a list on each, through the Lambda function. Each SG has a tag identifying it as a CloudFront SG as well as the sequence/list number. This ensures that rules are split evenly across each SG. By using tags, it is not necessary to specify which SG needs to be updated with what rules as the Lambda can automatically identify them. Our single Lambda function can update several SGs attached to several ELBs across different VPCs in a single run.

So, there you have it. By utilising the SNS topic and a Lambda function, we have a totally automated way to keep your origins behind CloudFront secure.

Improved reporting for our Managed Azure customers using automation

One of the many things we offer as part of our Managed Azure service is a monthly report with advice on cost savings, security and cloud best practice. Fortunately, the native tool, Azure Advisor, provides personalized information on exactly these categories. However, we had a problem. Although Azure Advisor allows manual export of its reports from the Azure portal, this was time consuming for our Service Desk team to update into the format that we want to provide to our customers. This re-formatting includes customisation for each customer, adding a notes field so we can add more detailed explanations and the ability to track remediation progress and exclude categories or certain priorities of recommendations.

We knew some automation was needed!

Since PowerShell is now fully supported by Azure Functions and has a lot of built-in Azure functionality in the Az module, we decided this was the language to use.  Practicing what we preach, we leveraged Azure Platform as a Service resources to host a truly cloud-native solution. The script needed to be able to connect to the customer’s Azure Advisor and pull out any recommendations before exporting these to a customised Word document.

This is what we did – a fairly smart solution to our requirements.

To make the connection we used a Service Principal, which is a security identity used by apps, services, and automation tools to access specific Azure resources. To ensure we connected to the correct Azure Advisor instance for each customer, we needed to know the customer’s name, the ID of their Azure Active Directory tenant, the ID of their Subscription and the same for the Service Principal itself.  Finally, we required the Service Principal Client Secret, which is the equivalent of its password. The values of these parameters are stored in Table storage except for the Client Secret, which is kept in a Key Vault.

The script initially connects to Azure in a user context and pulls the previously described parameters for all the customers into an array. It then disconnects and uses the Service Principal with the Reader role in the customer’s subscription to re-authenticate to Azure. Once authenticated, it calls the Azure Advisor API to refresh and get the latest recommendations. Once it has filtered, sorted and exported them to an appropriately customised Word Document, it loops round to start the next customer. Finally, the Word documents are emailed to our Service Desk team via a free SendGrid account and also archived to cool tier blob storage in a Storage Account for future reference.

As mentioned, our original intent was to run the script from an Azure Function with a timer trigger. This would mean we would pay only when the script was running and there would be no need for patching or other maintenance.  Unfortunately, we found during testing that the PowerShell module used to create the Word document was not able to work properly in a Function due to a .Net dependency in a piece of middleware. To overcome this hurdle without redeveloping the whole module, we currently run the script from a virtual machine using the Windows Task Scheduler. The virtual machine is, in turn connected to the Azure Automation On-Off solution which powers it on for a few hours each month to allow the script to run and for patching to take place. This means that the Pay-As-You-Go virtual machine is only costing us the few pounds per month whilst it’s powered on.

We also contacted the developer of the module to make him aware of the issue and we hope in a future release it will be resolved so that we can move to the much neater solution using an Azure Function.

The final part of the automation was a separate script to allow on-boarding new customers. This pulls the name, tenant and subscription information from the customer Low Level Design document to create the Service Principal and Client Secret with the appropriate Azure role and then save this information in the Table storage and Key Vault ready for the next time the reports are generated.

The end result is a fully customised report delivered to our Service Desk team ready for them to check and annotate before passing on to our customers which helps us align to our ISO accreditations.

End-to-end this was about three days of work to put together, including writing the script and some infrastructure as code around the Azure resources. We’d estimate this is probably a saving of 12 days a year for our Service Desk manager and saving him the task of manual exporting, filtering and formatting. It also means that our reporting is completely consistent across all our Azure customers and much less susceptible to human error.

Are you well-architected?

If you currently work in a UK university or college, then the chances are that somebody, somewhere in your institution is already a customer of AWS or Microsoft Azure. Maybe both? In most cases, that usage of AWS or Azure will be known about and managed by the central IT deparatment, in some cases, possibly not.

Maybe you have one or two public cloud proof-of-concept projects on the go. Or maybe you’ve gone further and have some production workloads running on AWS or Azure?

If so, how confident are you about the way you are using public cloud? Is security locked down? Do you have the right mechanisms in place to control and manage your spend? How resillient is your cloud-hosted service to component failures? How will it respond to spikes in demand?

We can offer you an independant, external and impartial review of your existing cloud usage in the form of a Cloud Architectural Review. The review will assesses your current public cloud estate and associated operational processes against your business objectives from the perspectives of:

  • operations
  • security
  • reliability
  • performance
  • cost optimisation.

We can then make architectural and operational recommendations with respect to cost-benefit, best practices, processes, implementation approaches and timescales. All our Solutions Architects are certified in line with Azure and AWS best practices and all have experience of deploying a wide range of services to the cloud.

If that sounds of interest, please speak to your Account Manager or get in touch with Jisc Cloud Solutions via the usual channels:

We also understand that not all universities and colleges have yet started their move into public cloud. If you fall into this group then you may be interested in a new service that we are developing, tentatively called Public Cloud Landing Zone.

In this context, a ‘landing zone’ is a well-architected public cloud tenancy, or group of tenancies, into which a university or college can start deploying services to the cloud. Well-architected in both a technical sense but also in a policies and processes sense. A Public Cloud Landing Zone engagement will involve both workshop type activity (to understand requirements and current practice), technical deployments using infrastructure as code, as well as documentation, etc. Although we have done much of this kind of activity many times in the past (when deploying a particular service to the cloud) we haven’t wrapped the component parts together into a single service and we haven’t really done it at the scale of a whole university or college – hence the reason we are treating it as a new service.

The creation of a well-architected ‘landing zone’ allows technical, operational and governance stakeholders in the institution to develop the skills, experience and confidence needed to use public cloud technologies. In turn, this allows IT staff, researchers and academics to experiment and explore capabilities within the confines of secure, compliant and well-governed platforms, providing reassurance against unexpected costs and security risks.

Again, if this sounds of interest, please get in touch.

AWS silly season – here we go

The AWS re:Invent annual conference in Las Vegas kicks-off next week, which means we are about to be snowed under by hundreds of new service announcments, product updates and the like. This year, AWS have started this process slightly early, so as not to overwhelm people during the week of the conferenece. There have been lots of announcements already.

Here are a few that I’ve spotted slipping past in my inbox that I think will be of interest to our members and customers. But there’s probably a lot of things that I’ve missed, so I suggest you keep an eye on the AWS blog for yourself. There will be so much coming out of AWS over the next week or so that keeping up will be more or less a full time job.

SES account-level suppression lists – For those of our customers that are sending large amounts of outbound email from their AWS-hosted services using SES (Simple Email Service), keeping up with bounces and complaints is a challenge. If they fail to stop sending mail to email addresses that have previously bounced, they run the risk of being blocked by AWS. (AWS have to do this to preseve the integrity of the SES service as a whole). AWS has now announced the availability of account-level suppression lists, which can be used by customers to protect their sender reputations and improve overall delivery rates for messages.

AWS managed rules for AWS WAF – AWS WAF is a web application firewall. It lets you define rules that give you control over which traffic to allow or deny to your application. You can use AWS WAF to help block common threats like SQL injections or cross-site scripting attacks. You can use AWS WAF with Amazon API Gateway, Amazon CloudFront, and Application Load Balancer. For most of our customers, we define and manage a set of rules in collaboration with them. AWS managed rules gives us a way of piggy-backing on the knowledge in AWS, choosing sets of rules that are maintained by AWS staff.

Least outstanding requests algorithm for load balancing requests – Sounds like a minimal announcement but I suspect it will actually be very useful. You can now use a ‘least outstanding requests’ algorithm, as well as plain old round-robin, to determine how Application Load Balancers share load across their target resources.

AWS Cost Categories – You can use use AWS Cost Categories to define custom rules to map to your internal business structures. After defining categorization rules, the system will organize your costs starting at the beginning of the month. Customers can visualize and monitor spend by viewing these categories in AWS Cost Explorer and AWS Budgets. We will look at the options here, particularly with regards to how we utilise this in our forthcoming Billing Portal.

Use employee attributes from your corporate directory for access control – You can now use your employees’ existing identity attributes, such as cost center and department, from your directory to create fine-grained permissions in AWS. Use these  to implement attribute-based access control to AWS resources and simplify permissions management.

As I say above, these are just a few of the many announcements that AWS have made over the last couple of days. I’ll be keeping an eye of future announcements and summarising the ones that I think are most relevent to our members and customer here.

The Capex to Opex Shift

Despite all the benefits of cloud, we often hear concerns about cloud. These generally fall into the following 6 categories which can be addressed with skills/knowledge or processes, be that creating or updating.

One concern within Business is the capex to opex shift. Whilst on premise kit is treated as capex because they are owned assets, consuming cloud services is opex which is treated differently.

I have created a little video of less than 9 minutes – an Accounting 101 demonstrating the capex to opex shift and giving some tips on how to understand it, accept it and move on – there is no magic wand!

A key takeaway is that only assets that you own can be treated as a capex and therefore depreciated. Prepaying for future services can go to the balance sheet as a prepayment and hit the P&L in the month you benefit from the service, but it will hit the P&L as the type of cost it is, eg IT costs, not depreciation. Why is this important? Because IT costs impact the ‘operating profit’ line whereas depreciation is taken into account after ‘operating profit’. Why is ‘operating profit’ important? It is deemed to be a key metric of an organisations’ financial health; the ongoing profitability from day-to-day operational trading. In many industries remuneration schemes use this figure.

Whilst there isn’t a magic wand to make cloud capex, it is important to understand that moving to cloud is much more than a cost conversation. If you haven’t read it already, check out my previous blog on Digital Economics, which highlights that cost is just one aspect of moving to cloud, the real value is in growing the revenue as a result!


AWS Savings Plans

AWS have announced a new pricing feature called Savings Plans, offering a way of saving up to 72% on your compute (EC2 and Fargate) spend. Even though I suspect that in most cases the realised savings will be lower than this headline figure, there is no doubt that they will be substantial in many cases. This is a pretty big innovation in how customers can buy AWS resources.

Full details on the AWS Savings Plans web page.

Savings Plans is a new flexible pricing model that allows you to save up to 72% on Amazon EC2 and AWS Fargate in exchange for a commitment to a consistent amount of compute usage (e.g. $10/hour) for a 1 or 3 year term. Savings Plans offers significant savings over On Demand usage, just like Reserved Instances, but automatically reduces your bills on compute usage across any AWS region, even as usage changes.

For members and customers who buy their AWS thru us, we will be assessing your usage and making recommendations for how best to take advantage of this new facility. For anyone else, I strongly suggest doing this analysis yourselves, even if you already make use of Reserved Instances (RIs).

Savings Plans look to give much greater flexibility than RIs in the way they can be applied, particularly from the perspective of moving workloads between EC2 and Fargate.

Working with the Warwick Employment Group

The Cloud Solutions team in Jisc works with a variety of members and customers from across education and the wider public- and third- sectors on a variety of projects and activities. For many, our primary focus is to help them with the strategic planning for their IT infrastructure, particularly as it relates to cloud adoption (obviously!). What are the pros and cons of moving to the cloud? How does the TCO compare to on-prem? How ready are they to move? Where are they with their digital transformation? What does their infrastructure roadmap look like? That kind of thing.

For others, the strategic decisions have already been made. What they need is practical help in the form of professional services and/or managed services, typically focusing on architecting new services in the cloud, re-architecting existing applications to take advantages of the new functionality offered by the cloud, or, in a few cases, simply migrating services to the cloud pretty much as they are.

Over the next few months, we’ll share some of the work we have been doing with members and customers, just to give a flavour of the kinds of areas we can help with.

One such customer is the Warwick Employment Group (part of Warwick University Services Limited) who are responsible for, the leading international job board for careers in academic, research, science and related professions. The team had been an existing customer of Eduserv for a long time – since well before the public cloud as we know it today became available and well before the merger between Jisc and Eduserv was first mooted. Back in early 2017 they came to us wanting to gain greater agility in the way their service was delivered, better resilience against server failures and the ability to think about taking their services to a much wider audience.

As far as I recall, they already had Amazon Web Services (AWS) in mind. We talked to them about the benefits they would gain from re-architecting their services on AWS and did some analysis of what their likely costs would be. A migration project was agreed. I doubt that we told them at the time but they were the second AWS customer that we did any significant re-architecting for (after Bristol City Council for whom, at the time, we had just completed a migration of their website to AWS).

As with all our cloud projects, we adopted an infrastructure as code approach from the ground up, using CloudFormation to capture the deployments and designing an AWS account and Virtual Private Cloud (VPC) structure in line with UK Government OFFICIAL guidance and AWS best practice. We took their database layer into the Amazon Relational Database Service (RDS) and used multiple Availability Zones to provide much greater resilience than had previously been possible in the Eduserv data centre.

One of the features of the service is the large numbers of email messages that get sent out – that is their primary job alerting mechanism. The volume of emails required the use of the Amazon Simple Email Service (SES) – our first experience with that service. As a well-known public-facing service, we have also had to work hard to keep the service secure.

I’m pleased to say that we continue to work closely with the team, now as Jisc Cloud Solutions rather than Eduserv, providing them with a mix of ongoing managed service (patching, backups, etc.) as well as professional services and advice where they need it.