Azure Updates Q4 2019

It’s been a while since I wrote a blog post on the Azure updates which I have paid attention to in 2019. So strap yourself in, lets see which ones make the list!

Azure Spot Virtual Machines

Need to run some VM’s for a short period of time to undertake some testing or development work? Well look no further than Azure Spot Virtual Machines, which Microsoft use to sell unused capacity. Then when they need it back they shut the VMs down.

More information can be found here.

Azure Migrate – Agentless Dependency Mapping

Working out a migration to Azure for IaaS can be a bit tricky when a customer doesn’t have or know what makes up an application service. Step in Azure Migrate – Agentless Dependency Mapping, which can discover interdepentent systems that need to be migrated together.

Coupled with this Azure Migrate can now perform captivation discovery using WMI and SSH calls to to determine the apps, roles and features installed.

More information can be found here.

Azure Dedicated Hosts

It’s not often in this day and age that a dedicated host is required in the public cloud, however Microsoft now have the answer for this with the general availability of ‘Dedicated Hosts’, which provide a hardware isolated environment.

More information can be found here.

Azure Cost Management – CSP

It was always a tough call for customers to choose between the commercial attractiveness of a CSP or the human readable information provided using an EA.

On 1st November, Microsoft enabled CSP for Azure Cost Management, meaning customer now have end to end visbility of costs and budgets.

More information can be found here.

Azure Monitor

This particular service in Azure, has had oodles of updates, which now enables it to provide a centralised repository for collecting, analysing and altering. To be fair, I have used it extensively troubleshooting issues in particular when tuning Application Gateway with WAF functionality.

More information can be found here.

Azure Bastion

Providing secure audited remote access to third parties or employees used to mean deploying Just in Time Access. However this raised a few eyebrows as it was based typically based on source Public IP Address locked down to a specific TCP port.

Azure Bastion removes this risk and provides a PaaS service to enable you to connect over SSL to RDP or SSH sessions.

More information can be found here.

New Microsoft Azure “MFA Free Option”

Worth noting. Microsoft have sneaked in a “Free Version of MFA”. On the understanding that you agree to enable the new “Security Defaults”  (below) and only use the MFA Authentication App

It basically forces MFA for everyone and blocks legacy authentication too. There is no “trusted sites option” and a load of other features not available. See URL here.

Also everyone is prompted for MFA and must register regardless of been internal / external. But which may be useful for small / tactical deployments.

Credit to Mark Brumby for highlighting this.

AWS Concepts – S3

First of all, what does S3 stand for? The answer is Simple Storage Service which was launched by AWS in March 2006, so it’s over 13 years old at the time of writing this blog post!

S3 provides developers and IT teams with a secure, durable and highly scalable object storage. Examples of object storage are flat files such as word documents, PDFs, text documents etc.

S3 allows you to securely upload and control access to files from 0 bytes to 5TB into a ‘Bucket’ which is essentially a folder. The ‘Bucket’ requires a globally unique namespace across S3. AWS claim that S3 provides unlimited storage (not sure if anyone would or could test this claim!).

Data Consistency

S3 uses the concept of read after write consistency for new objects. In a nutshell this means when the object is committed to S3, you can read it.

However when you are updating or deleting the object you receive eventual consistency. So if you have a file which you have just updated and you access it immediately, you may get the old version, wait a few seconds and you will receive the new version.

S3 The Basics

S3 is built for 99.99% availability, however AWS only provides a 99.9% availability SLA see here. Which means you could have just over 8 hours 40 minutes of acceptable downtime per annum.

Think about the impact of AWS S3 availability SLA on any designs

Amazon provides a 99.999999999% (11x9s) durability SLA which means data won’t be lost. However does this same guarantee apply to data integrity?

S3 provides the option for tiered storage with lifecycle management, for example if an object is older than 30 days move it to a lower cost/class tier.

Outside of this, S3 allows versioning of objects, encryption and policies such as to delete an object you have to use MFA.

S3 Storage Tiers/Classes

At the time of writing this blog post, S3 offers six different classes of storage. Each of these has it’s own availability SLA, differing levels of costs and latency.

It’s easiest to explain this in the table below which is taken from AWS.

If we look at all of the different storage classes except for S3 One-Zone IA they can suffer the loss of two availability zones. Whereas only S3 Standard and S3 Intelligent-Tiering includes data retrieval fees.

Lastly if we examine ‘first byte latency’ this determines how quickly you will be able to access any objects.


When you create an S3 ‘Bucket’ you are able to replicate this from one AWS region to another, providing either high availability or disaster recovery (dependent on your configuration). This can also be coupled with S3 Transfer Acceleration which uses CloudFront edge locations. The benefits this provides are that users upload files to the closest of AWS’s 176 edge location which are then transferred securely to the S3 Bucket.

The diagram below provides a logical overview of this process.

A few things to note about S3 Cross Region Replication:

  • Only new objects and changed objects are replication, not existing objects
  • Cross Region Replication requires versioning to be enabled
  • The target bucket can use a different storage class
  • The target bucket receives the same permissions as the source bucket
  • Deletions and deletion markers are not replicated from the source to target region


S3 security is achieved by a number of elements, which include encryption in transit using TLS and at rest when the data is committed to the S3 bucket.

Dependent on how a business operates it may choose to either handle encryption at rest locally and then upload the encrypted object to the S3 bucket or trust AWS to encrypt the object within the bucket. This process is managed by keys to encrypt and decrypt the object.

  • S3 Managed Keys – Built Into S3, managed by AWS
  • AS Key Management Service – Managed by both AWS and the customer
  • Server Side Encryption with Customer Keys – Customer provides the keys

By default a bucket is private e.g. the objects within this are not accessible over the internet. You can apply access policies to a bucket either on the resource directly or via a user policy.

AWS Concepts – Billing Alarms

So you have set up your first AWS Account and want to make sure that the costs don’t spiral out of control? This quick guide will help you put things in place to ensure that you are notified when costs exceed a predefined limit.

First of all select your Organisation > My Billing Dashboard and then Billing Preferences

Next tick ‘Receive Free Tier Usage Alerts’ and enter an email address along with ticking ‘Receive Billing Alerts’. Finally click on Save Preferences.

This is the initial configuration at account level on how we want our billing preferences to be set. Now we need to use CloudWatch to send an alert when a metric his hit.

Select Services > CloudWatch. Then Select Alarms > Create Alarm.

Select Metric > Billing and then Total Estimated Charge > Currency USD > Select Metric, as shown below.

We now need to specify our metric conditions. Using a ‘Maximum’ value over a period of ‘6 Hours’ when it is Greater than 10 USD….do something!

In the notification screen select ‘in Alarm’ which essentially means when the alert is triggered, do something. We want that something to be a Simple Notification Service (SNS). Select NotifyMe. Finally we now need to click on the SNS Console to setup and verify the email address.

Within the SNS Dashboard, we should have a Topic named ‘NotifyMe’ without a Subscription assigned to it. Click ‘Create Subscription’

Select Protocol > Email and the Endpoint, in this example it’s Finally select Create Subscription.

Before the alert subscription goes live, we need to confirm that we have access to the email endpoint. Check you inbox (or spam). Once confirmed you should receive a verification such as this.

Double check your Subscription in SNS to verify the status.

Back into the CloudWatch dashboard and if we remove and re-add NotifyMe, we should see the email (endpoint) change to our verified address.

Lets give the alarm a unique name. I have chosen BillingAlarm with the description Greater than 10 USD.

Finally click ‘Create Alarm’ and verify the details. Voila we will receive an email alert when our expenditure is over 10USD within a six hour window.

AWS Concepts – Identity & Access Management

When we talk about Identity and Access (IAM) what do we really mean? For me, it boils down to who you are and what you are entitled to access.

Simple statement, but it does start to get rather complicated when you think about Identity Management.

If you think about your own organisation what directory service does it use? Probably Active Directory Domain Services (AD DS). Think about how many years it has it been fine tuned with integration with third party solutions such as MFA, SSO and VPNs.

The list does truly go on and on. Most organisations will treat their on-premises Active Directory Domain Services (AD DS) as the one source of all truth for users, groups, permissions and passwords.

So the question is how does AWS deal with IAM?

What Is AWS IAM?

It is AWS hyperscale web service that allows users and services shared access to your AWS account. It uses an eventually consistent model, which in a nutshell means that changes are not immediately available.

Users are authenticated and then authorised to use AWS services. To ease the management of individual users, groups are used. Policies are applied to groups which then dictate what the user or service can do.

Policies are JSON documents, used to define actions, effect, resources and conditions on what can be evoked for example:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
            "Resource": "*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": ""

When you create an IAM user, they can’t access anything until you give them permission.

It should be noted that actions or resources which are not explicitly allowed are denied by default.

We also have IAM Roles, which are similar to users but are AWS identities with permissions (JSON policy) which determines what can or can’t do. It is important to note that IAM Roles don’t have any passwords or long terms access credentials. Access keys are created dynamically and provided on a temporary basis. Typically they are used to delegate access to applications or services.

IAM Roles can also be used to provide users with enhanced privileges on a temporary basis for example a user requires occasional admin access to an S3 bucket.

To enable policies to be tested before you apply them into production, AWS have a handy policy simulator which can be found here.

Identity Federation

AWS IAM supports identity federation for delegated access to either the AWS Management Console or APIs. Federated users are created within your corporate directory outside of the AWS account.

These can be web identity providers such as Amazon, FaceBook, Google or an OpenID Connect provider.

Within the enterprise world, we tend to see Active Directory Domain Services used in conjunction with Active Directory Federation Services. AWS have integration using Security Assertion Markup Language 2.0 (SAML 2.0) using STS AssumeRoleWith SAML.

A high level overview of this is shown below in the diagram below.

  1. User browsers to URL and is redirected to AD FS sign in page
  2. User enters Active Directory credentials
  3. User authenticated by Active Directory Domain Services
  4. Users browser receives a SAML 2.0 assertion
  5. User browser posts the SAML 2.0 assertion to AWS STS
  6. AssumeRoleWithSAML requests temporary security credentials and constructs a sign in URL for the AWS Management Console
  7. User browser receives the sign in URL and is redirected to the AWS Management Console

Single Sign On Cloud Applications

To provide easier integration with popular cloud applications
such as Dropbox, Office365 and SalesForce. AWS provide single sign on (SSO) using SAML 2.0via a configuration wizard.

Further information can be found here.

MultiFactor Authentication

AWS MFA provides an extra later of security to reduce the overall risk of compromised credentials. Providing a secondary authentication step for Management Console and API users.

For the MFA device, you have a choice of three items:

  1. Virtual MFA Device
  2. Hardware Key
  3. Hardware Device

This link shows which form factors can be used across devices.

Final Thoughts

AWS IAM is a web scale directory that can provides integration with on-premises directory services and cloud applications. Interestingly this is an added value service with no extra cost, which is a different approach from traditional licensing vendors.