Microsoft announced last week that the ability to use Azure Monitor to monitor Windows Virtual Desktop environments is now at the “general availability” commercial-release stage.

Windows Virtual Desktop is Microsoft’s virtual desktop infrastructure service, commercially launched in September 2019. It houses the operating systems (Windows 7 and Windows 10) and apps on Microsoft’s servers for remote access by end users. While Windows Virtual Desktop lets organizations have a more centralized management control over Windows apps and devices, which can even be thin-client devices, it possibly comes with complexities.

However, an “insights” capability in Azure Monitor at least promises better monitoring of Window Virtual Desktop service health.

“With Azure Monitor for Windows Virtual Desktop, you can find and troubleshoot problems in the deployment, view the status and health of host pools, diagnose user feedback and understand resource utilization,” Microsoft’s announcement indicated.

The new Azure Monitor capability brings improved data collection. Cost estimates are said to be better optimized. The user interface for Windows Virtual Desktop setups is said to be easier, including when setting up virtual machines and Windows Event Logs. Warnings now appear at the top of the Host Diagnostics page, as well.

Microsoft warned preview users of the Azure Monitor for Windows Virtual Desktop solution that they will have to go through some manual configuration steps in order to optimally switch to the general availability release version. Those steps are needed to “help reduce your Azure Monitor Log Analytics cost,” Microsoft explained in this March 25 announcement.

The use of Azure Monitor comes with its own complex cost structure, which is outlined at this Microsoft pricing page. Organizations pay for what they use, but there are various charges associated with Azure Monitor use, which are broken down in detail on the pricing page.

Organizations using Azure Monitor for Windows Virtual Desktop will need to have an Azure Log Analytics account for the data storage aspects.

“To start, we recommend you choose the pay-as-you-go model and adjust as you scale your deployment and take in more data,” Microsoft indicated in this document on Azure Monitor for Windows Virtual Desktop regarding the Log Analytics account that’s needed.

Azure Monitor for Windows Virtual Desktop doesn’t appear to support complex virtual desktop infrastructure environments right now.

“Windows Virtual Desktop currently only supports monitoring one subscription, resource group, and host pool at a time,” Microsoft’s document explained in a note.

To use Azure Monitor for Windows Virtual Desktop, organizations will need to be using “the latest release of Windows Virtual Desktop that’s compatible with Azure Resource Manager,” the document indicated, without naming the version. Organizations also need a Log Analytics workspace where data collection is enabled for Windows Virtual Desktop diagnostics and performance. Some read-access permissions also need to be turned on.

Microsoft also recommends using “Windows Events Logs from your Windows Virtual desktop session hosts” with Azure Monitor for Windows Virtual Desktop.

Most enterprises are still migrating workloads from data centers to the cloud. Although saving money is generally not the driving force for such migrations, it doesn’t hurt if money is saved along the way for better scaling or reliability, or an end to IT capital expenses.

The financial benefits of cloud computing, though not as inevitable as years of hype made folks expect, are real. The following are the top five strategies CIOs can use to reap those cost benefits.

1. Avoid lift and shift
It gets easier to shift a workload or a set of integrated workloads into a cloud environment with minimal modification. If a cloud migration is motivated by a looming data center lease expiration, a lift and shift of virtual machines (VMs) and data sets may be the only way to meet the deadlines. However, it will probably come with a cost increase for providing the shifted services in the near term.

Systems that were not designed to run in the cloud usually don’t take advantage of the features of cloud that hold the greatest potential for savings: the ability to scale infrastructure dynamically both up and down in response to load, and the ability to scale horizontally by spinning up new VMs or containers. Between them, these features allow IT to pay for only as much infrastructure as the workload needs, when it needs it. In-house resources must always be present to handle the peak load of the system and shifting a workload to the cloud unchanged usually means it is overprovisioned most of the time. As a result, enterprises wind up paying more to run in the cloud.

Nemertes Research found that IT shops on average spend about 12% more to run a workload in the cloud than in their own data center.

Therefore, IT should be seeking to refactor workloads to be more cloud-friendly wherever possible or seeking to replace pre-cloud architectures with cloud-native ones built on the premise of just-in-time infrastructure. In Nemertes’ research on cloud operations, the organizations best at this were, on average, running workloads for just 40% of what they had spent on premises.

To facilitate a cloud migration, IT should have in place a consistent workload placement process (WPP) to follow in evaluating workloads for migration. The WPP should take into account the architecture of the workload, prioritizing cloud-friendly systems over cloud-hostile ones, and weigh numerous other factors such as the risk associated with hosting in cloud versus on premises (it is often lower risk to provide service from the cloud now), the performance requirements of the workload and so on.

2. Utilize commitment and tiering
Too many cloud teams fail to take full advantage of committed instance pricing, and therefore are unable to get discounted rates on their resources. They do so out of an overabundance of either caution or optimism — not wanting to make a long-term commitment on a system that might be refactored or replaced in the near term.

CIOs should set up a process for sequencing such changes and utilize as much long-term pricing as they can based on the schedule that falls out of it. Any slight overcommitment will be more than balanced by savings.

3. Pay attention to data gravity
Surprise expenses often come in the form of data egress charges — the cost of moving data out of a cloud environment into another or back on premises. The WPP must include consideration of data affinities and should be used to group together systems that produce heavy traffic among themselves.

4. Use PaaS
Nemertes’ research on cloud operations found that organizations can save on average 15% to 20% on staff costs by shifting to database as a service or application server environments consumed as PaaS.

5. Empty racks, rooms, buildings
One of the primary goals should be supporting infrastructure in data centers and to realize savings there as fast as possible. Being able to empty racks entirely means also being able to reduce cooling and UPS service.

Ultimately, the important takeaway is that financial benefits of cloud computing are possible but not inevitable. All CIOs, even if they are pursuing cloud for reasons other than cost savings, should factor the possibility of savings into their decisions and planning, aiming to realize them when it doesn’t prevent them achieving their strategic goals for cloud.

Microsoft has announced to extend its confidential computing options available to Azure Cloud customers in partnership with chip-maker AMD.

The company said it will be the first major cloud provider to offer confidential virtual machines on the new AMD ‘EPYC 7003’ series processors.

With the third-gen AMD EPYC CPU-backed confidential computing virtual machines (VMs), Azure confidential computing now enables customers to encrypt entire VMs confidentially, enable confidentiality without recompiling code, and benefit from a host of Azure-specific enhancements.

“Today you can deliver confidential workloads on Azure with the broadest choice of hardware as well as resources spanning virtual machines, containers, SQL, and beyond,” the company said in a statement on Monday.

As a founding member of the Confidential Computing Consortium, Microsoft is also an innovator in confidential computing which extends those protections to data running on the processor itself.

“For more than three years, financial services, governments, health care providers, and even messaging companies have been using Azure confidential computing to unlock new scenarios like multi-party machine learning and move their more sensitive applications to the cloud,” said Mark Russinovich CTO and Technical Fellow, Microsoft Azure.

The AMD EPYC-CPU powered Azure VMs are fully encrypted at runtime, fulfilling the promise of confidential computing by protecting your data even when it is in use.

You’ve probably heard of the dot-com bubble of 1995–2000 and one more recently referred to as the Bitcoin bubble, both of which have proven not to be a bubble at all but rather a thriving new asset class, which would be hard to imagine in a world of innovation without it today. Our new concept, Bubble Network, is a deflationary token designed to embrace and even adopt the idea of being called a bubble as a positive thing if in terms of price appreciation.

Bubble Network is a decentralized peer-to-peer transaction network and store of value, providing a solution for new investors to be part of an innovative network of asset holders. The direction of Bubble is to ultimately be governed by the community as well as the value of the asset.

A Liquidity Generation Event recently took place in November 2020, in which the presale completely sold out in only four days. Liquidity has been locked for a minimum of six months, using Unicrypt services. Trading began on Uniswap also in November 2020, seeing the price initially surge approximately 87% before retracing slowly and stabilizing for several weeks.

What makes BBL a great investment opportunity?
BBL, Bubble’s native token, is a deflationary ERC-2O token built on the Ethereum network with a maximum and minimum supply of 100,000 and 30,000 tokens, respectively. Deflation will happen due to a slow-burn mechanism. Every transaction will trigger a burn rate of 5% that will continue until the supply reaches 30,000. This will protect pooled Ether for a sustained period.

The initial 100,000 tokens have been minted. The BBL token contract has no functionality to mint more tokens. However, BBL farming and staking will be implemented by using the new Bubble Valve token (BBV), which will be released in mid-December 2020. BBV was created to complement BBL and add additional utility. Users can farm BBL to earn rewards in BBV and also stake BBV to earn extra BBV rewards. The BBV UI will also have an automatic compounding feature that will enable more staking power for users.

There are further announcements expected over the next few weeks in December 2020 related to insurance solutions and non-fungible tokens that are slated for 2021. Bubble Network aims to be eventually listed on a range of centralized exchanges and could be a rising star in the decentralized finance space. The Bubble network token is currently trading on Uniswap’s decentralized exchange and can be stored on multiple ERC-20 cryptocurrency wallets, such as MetaMask or Trust Wallet, to name a few.

Technology has enabled businesses to continue operating this year, and the cloud has taken center stage — going forward, it will only play a larger role in the enterprise.

According to CloudTech, public cloud spending is expected to grow from US$229 billion in 2019 to US$500 billion in 2023, with a compound annual growth rate (CAGR) of 22.3%.

Key players Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Alibaba, and are expected to grow yet bigger, and by the end of 2021, 60% of companies will leverage containers on public cloud platforms and 25% of developers will use serverless.

As this market continues its growth and evolution, here are three trends to watch in 2021.

Serverless computing
A cloudless server is a technology that implements functions in the cloud on a necessary basis. Enterprises rely on serverless computing because it provides space to work on core products without the pressure to operate or manage servers. Microsoft CEO Satya Nadella favors serverless cloud and he believes serverless computing can not only respond and focus on back-end computing but also become key to the imminent future for distributed computing.

Serverless was among the top five fastest-growing PaaS cloud services for 2020, according to the Flexera 2020 State of the Cloud report.

Hybrid cloud joins providers
Choosing between public, private, or hybrid cloud environments, has proved challenging for some organizations — each offers advantages and disadvantages when it comes to flexibility, performance, security, and compliance.

According to Gartner, in 2019, the actual number of companies using hybrid cloud was 58%, up 6% from 2018. Hybrid cloud benefits include speed, control, and security. In terms of speed, it optimizes the network to reduce the latency and speeds up the data so that it can reach where it needs to be. For control, companies can customize the end of their hybrid cloud model, optimize it, and adjust it according to their needs rather than trusting a third-party cloud provider.

The continued demand for hybrid cloud could lead the world’s biggest providers to partially break out from their walled garden approach. By collaborating and introducing some interoperability, they can continue to satisfy multi-cloud demands. This will enable better data sharing and access between partners, who may be working across diverse applications and standards.

Virtual Cloud Desktops
A virtual cloud desktop refers to the software requirements of a device being fully managed by cloud service providers. The user just needs to have a screen and some basic hardware while the rest of the processing power will be seamlessly handled by cloud-based services.

Virtual cloud desktop users only pay on cloud usage, eliminating costs associated with acquiring powerful new hardware, updating the existing hardware, and the disposal of redundant computing equipment.

Sometimes known as desktop-as-a-service, this model of computing is offered by Amazon via the Workspaces platform and Microsoft with Windows Virtual Desktop. Google also offers functionality through its Chromebook devices. In practice, this can increase efficiency across a workforce by ensuring everyone is using up-to-date, synchronized technology.

What Is AWS Lightsail?

Lightsail is AWS’s managed virtual private server (VPS) product. It abstracts much of the underlying infrastructure configuration required when working directly with EC2, making it a practical choice for:

• Small and medium-sized businesses (SMBs) deploying web applications or websites
• Developers who need fast, disposable test or staging environments
• Teams running managed application stacks (e.g., WordPress, LAMP, Node.js)
• Workloads that benefit from predictable, flat-rate monthly billing

Lightsail bundles compute, SSD storage, data transfer, DNS management, and a static IP address into a single monthly price, removing the need to configure and cost each resource independently.

Lightsail Pricing Overview

Lightsail uses flat-rate monthly plans rather than the pay-per-resource model used by core AWS services. Entry-level plans start at a low monthly cost and scale up as you need more vCPUs, RAM, and data transfer capacity. Each plan includes a bundled monthly data transfer allowance. Always check the current Lightsail pricing page for up-to-date plan specifications, as AWS adjusts tiers and prices over time.

Available Lightsail Instance Types and Blueprints

When creating a Lightsail instance, you select a blueprint — a pre-configured OS or application image. Available options include:

Operating System Blueprints

• Amazon Linux
• Ubuntu
• Debian
• FreeBSD
• Windows Server (additional licensing costs apply)

Application Blueprints (One-Click Stacks)

• WordPress
• Drupal
• Joomla
• LAMP (Linux, Apache, MySQL, PHP)
• Node.js
• MEAN
• Nginx
• GitLab

Application blueprints install and pre-configure the chosen stack automatically, so the instance is ready to use almost immediately after launch.

Lightsail vs. Amazon EC2: Key Differences

If you outgrow Lightsail, AWS provides a migration path to export a Lightsail instance to Amazon EC2, giving you access to the full range of AWS compute features without needing to rebuild your environment from scratch.

How to Create a Virtual Machine Using AWS Lightsail

The following steps walk through creating a basic Lightsail instance. You will need an active AWS account and sufficient permissions (administrator or a policy that includes Lightsail access).

Step 1: Sign In and Open the Lightsail Console

1. Sign in to the AWS Management Console using an account with administrator credentials.
2. In the search bar at the top of the console, type Lightsail and select the service from the results, or navigate directly to lightsail.aws.amazon.com.
3. If this is your first time using Lightsail, you will see a welcome screen. Click Create instance to proceed.

Step 2: Select an Instance Location (Region and Availability Zone)

1. Choose the AWS Region closest to your end users. Selecting the right region reduces latency and may affect data residency compliance.
2. Select an Availability Zone within that region. For most simple use cases the default zone is fine.

Step 3: Choose a Blueprint (Platform and Application)

1. Under Select a blueprint, choose either Apps + OS or OS Only.
2. If you want a pre-configured application stack (e.g., WordPress), select Apps + OS and click the appropriate tile.
3. If you prefer a clean operating system, select OS Only and choose your preferred Linux distribution or Windows Server.

Step 4: Configure the Launch Script (Optional)

Lightsail allows you to add an optional launch script — a shell script that runs automatically when the instance first boots. This is useful for installing packages, setting configuration values, or pulling application code without requiring manual SSH access after launch.

#!/bin/bash
apt-get update -y
apt-get install -y git
git clone https://github.com/your-org/your-app.git /var/www/html/app

Step 5: Add an SSH Key Pair

1. Under SSH key pair, you can use the default Lightsail key pair, create a new key pair, or upload an existing public key.
2. Download and securely store the private key (.pem file) if you create a new key pair. You will need it to SSH into the instance later.

Step 6: Choose an Instance Plan

Select a monthly plan that fits your workload. Plans differ in vCPU count, RAM, SSD storage size, and bundled data transfer. For a simple website or small application, a lower-tier plan is usually sufficient to start. You can always upgrade to a higher plan later.

Step 7: Name Your Instance and Launch

1. Give your instance a meaningful name in the Identify your instance field. Use a name that reflects the environment and purpose (e.g., prod-wordpress-01).
2. Optionally, add resource tags for cost allocation or organisational purposes.
3. Click Create instance.

Lightsail will provision the instance within a few minutes. The instance card in the Lightsail dashboard will show a Running status when it is ready.

Connecting to Your Lightsail Instance

Once the instance is running, you have two primary ways to connect:

• Browser-based SSH: From the Lightsail dashboard, click the instance name and then click Connect using SSH. This opens a terminal directly in your browser — no local SSH client required.
• Local SSH client: Use the private key you downloaded during setup. For Linux/macOS: ssh -i /path/to/key.pem ubuntu@<public-ip>. For Windows, use PuTTY or Windows Terminal with the key converted to the appropriate format.

Assigning a Static IP Address

By default, a Lightsail instance is assigned a dynamic public IP that changes if the instance is stopped and restarted. To ensure your DNS records remain valid and users can always reach your server at the same address, attach a static IP:

1. In the Lightsail console, go to the Networking tab.
2. Click Create static IP.
3. Attach the static IP to your instance.

Static IPs in Lightsail are free as long as they are attached to a running instance. Unattached static IPs incur a small charge.

Migrating from Lightsail to Amazon EC2

If your workload grows beyond what Lightsail plans can support, AWS provides an export path. From the Lightsail console, you can create a snapshot of your instance and then export it to Amazon EC2. This converts the snapshot into an Amazon Machine Image (AMI), which you can use to launch standard EC2 instances with access to Auto Scaling, Elastic Load Balancing, and the full suite of AWS networking features.

Summary

AWS Lightsail is a practical starting point for teams and businesses that want cloud-hosted virtual machines without the configuration overhead of EC2. Its blueprint system, flat-rate pricing, and browser-based management console make it accessible to users who are new to cloud infrastructure, while the EC2 export path ensures you are not locked into its constraints as requirements grow.

For production workloads with complex networking, multi-region deployments, or sophisticated scaling needs, Amazon EC2 and the broader AWS ecosystem remain the better long-term choice.

The Cloud Visibility Problem

Cloud adoption is no longer optional for most enterprises — but the shift to virtualized infrastructure introduces a visibility gap that many organizations are only beginning to acknowledge. According to an Ixia study on virtualization, only 37% of organizations monitored their virtual environments at the same level as their physical networks. That means the majority of businesses are operating with significantly less insight into what is happening inside their virtual infrastructure than they had in on-premises environments.

Jeff Harris, then VP of Solutions Marketing at Ixia, framed the risk clearly: “Most organisations cannot take that chance, so they need to bridge the visibility gap quickly. Visibility will enable better control, to maintain security no matter where their data goes and, of course, to ensure reliability of their core business applications.”

Why Virtual Environments Are Harder to Monitor

In physical networks, traffic monitoring is relatively straightforward: taps or SPAN ports on physical switches capture traffic and send it to monitoring, analytics, and security tools. In virtualized environments, the challenge is compounded by the volume and nature of internal traffic.

Internal east-west traffic — communication between virtual machines, containers, and services within the same data center — typically accounts for around 80% of total traffic in virtual data centers. Much of this traffic never leaves the host, making it invisible to traditional network monitoring tools positioned at the perimeter.

Virtual network taps address this by sending traffic copies to monitoring and security tools. However, without intelligent filtering, the result can be a flood of data that overwhelms downstream tools. The goal is to identify and extract the most relevant traffic efficiently, not to mirror everything indiscriminately.

Four Key Areas for Deploying Virtual Network Taps Effectively

Ixia identified four areas that organizations should address when deploying virtual taps to ensure meaningful, granular access to critical application traffic across virtualized networks.

1. Horizontal Scalability

Virtual environments grow rapidly — new VMs spin up, user counts increase, and data volumes expand, often without much notice. Virtual network taps must be able to scale horizontally to keep pace with this growth without requiring manual IT intervention each time the environment changes.

Ideally, taps should scale automatically in response to traffic volume increases and new workloads, while having zero impact on the performance of monitored applications. If a monitoring solution becomes a bottleneck, teams will be tempted to disable or bypass it — defeating the purpose entirely.

2. Visibility Across Network Segments (“Securing in the Dark”)

Virtual firewalls are commonly used to segment virtualized networks — isolating workloads, enforcing compliance boundaries, and limiting lateral movement in the event of a breach. This segmentation is valuable for security, but it creates blind spots: traffic flowing between segments may not be visible to monitoring or security tools unless the taps are explicitly designed to operate across segment boundaries.

Virtual taps must be capable of capturing inter-segment traffic to ensure that security policies governing each network segment are actually being enforced. Without this visibility, an attacker moving laterally between segments could go undetected.

3. Container Environment Support

Container adoption has grown substantially alongside virtual machine usage, and containers introduce their own visibility challenges. Container lifecycles are short — containers may exist for seconds or minutes — and inter-container communication often bypasses traditional network monitoring points entirely.

Virtual taps must be able to capture traffic within container environments, especially when an organization uses container-based virtualization to boost application performance or density. Monitoring solutions that cannot see into container networking leave a significant portion of application traffic unobserved.

4. DevOps Elasticity and Continuous Deployment Compatibility

Modern DevOps practices mean that new builds, updated services, and changed configurations are deployed continuously across virtual environments. Individual VMs, containers, and microservices now have shorter lifespans than ever, and the topology of a virtual environment can shift significantly between deployments.

This creates a specific risk: a deployment pipeline should never be able to inadvertently take a virtual tap offline or block the traffic path it is monitoring. Monitoring infrastructure must be resilient to — and aware of — rapid changes in the environment, automatically updating its view of the current state without human intervention.

The Takeaway: Visibility and Cloud Speed Are Not Mutually Exclusive

A common misconception is that achieving deep visibility in cloud and virtual environments requires sacrificing the agility and cost benefits that motivated cloud adoption in the first place. Harris argued against this tradeoff: “With the right architecture they can have both.”

The architecture he described is environment-agnostic — capable of monitoring traffic across VMs, containers, and multi-cloud environments — and elastically scalable, distributing relevant traffic intelligently to analytics, security, and compliance tools rather than flooding them with everything.

For DevOps and platform engineering teams, the practical implication is that monitoring and visibility should be treated as first-class infrastructure concerns, built into the platform from the start rather than bolted on after incidents occur. The four areas above — scalability, cross-segment visibility, container support, and deployment resilience — provide a useful checklist for evaluating whether a virtual tap or network visibility solution is truly fit for a modern, dynamic cloud environment.

Summary Checklist

• Horizontal scale: Can the solution grow automatically without manual intervention or performance impact?
• Cross-segment visibility: Can virtual taps capture traffic flowing between network segments created by virtual firewalls?
• Container support: Does the solution monitor traffic inside container environments, not just VM-to-VM traffic?
• DevOps resilience: Will continuous deployments and infrastructure changes leave monitoring intact and current?