At the start of September, AWS launched the long-awaited New Zealand Region. The launch of the region marks a turning point for the Kiwi tech sector – for the first time ever, Kiwi businesses have more than one hyperscaler in-country to choose from.
While this is great news, businesses now have more options, and so choosing the right ones becomes more difficult. The purpose of this article is to provide a pragmatic look at the new region and when it makes sense to use it.
At the end of the day, the New Zealand Region is just another AWS Region. An AWS Region is a geographic area into which AWS customers can deploy resilient workloads.
An AWS Region always has more than one Availability Zone (a cluster of one or more datacentres). These datacentre clusters are connected via fast, durable, low-latency connections and are spread over areas with different geographic tolerances. For example, if an Availability Zone is in an area susceptible to flooding, another Availability Zone will be placed in an area highly resistant to flooding.
Figure 1 - AWS Availability Zone Architecture. From AWS Whitepaper: AWS Fault Isolation Boundaries
In addition to Availability Zones, Regions are also isolated from each other so that changes that impact one Region don’t impact another, reducing the likelihood of correlated failures.
Essentially, an AWS Region is a safe place to deploy infrastructure and applications – although at the end of the day, the safety of your application depends on how you’ve architected it.
When AWS designs a new service or updates an existing service, they usually roll out changes incrementally, starting with the North Virginia Region (US-East-1), meaning that service updates can take additional time to reach Regions in Australia and New Zealand.
AWS Services are designed to a specification and even in regions where the service has not yet been updated, the service will always function according to its specification.
To view available services in the New Zealand Region and compare them with the existing Sydney Region, we can use the AWS Region Comparison Tool, which compares available CloudFormation Resources to determine service availability and readiness.
AWS Regions adhere to the highest compliance standards, as can be seen on the AWS Website. Despite their high security however, there are additional considerations when deploying on AWS such as the Shared Responsibility Model.
Figure 2 - AWS Shared Responsibility Model - From the AWS Website
The Shared Responsibility Model describes the responsibilities of AWS and the customer when it comes to the security, configuration and operations of AWS services. It’s important to understand the model when building on AWS: just because AWS builds security into each layer they control, that doesn’t mean your application is deployed securely.
Adopting the Shared Responsibility Model means that you choose the right service that suits your compliance needs; you configure the service securely; and that you build and deploy your applications in a secure manner.
Essentially, you are responsible for everything above the ‘service’ layer depending on the model you consume (IaaS, PaaS, SaaS). To assist with this, the following AWS security services provide you with visibility of your cloud security posture:
Additional services like Control Tower, GuardDuty and Inspector are also useful for understanding security posture and will most likely arrive in the New Zealand Region in the coming months.
Each AWS Region is priced slightly differently based on several factors such as demand and infrastructure costs. At the time of writing, the New Zealand Region on-demand costs are a few percent more expensive than the Sydney Region.
Figure 3 - Price Comparison (USD/Month) for the same EC2 Instance between AWS Regions
AWS offers spot instances (such as Fargate Spot) that allow customers to purchase on-demand instances for less when there’s low-demand—however, they aren’t guaranteed to stay running. They’re commonly used in modern application deployments, when additional scaling capability is required during periods of high load.
Due to the low demand within the New Zealand Region, spot instances are more affordable than other Regions. It’s important to remember that this price will change as the Region is used.
Figure 4 - Price Comparison (USD/Hour) for the same EC2 Spot Instance between AWS Regions
You can now reference the New Zealand Region in the AWS Pricing Calculator Tool and the Vantage Instance Comparison Tool, allowing you to compare regional costs and create detailed estimates for any workload you’re considering moving into the new AWS Region.
AWS Regions can connect to varying degrees over network or via multi-region AWS services. It’s also possible to integrate an AWS Region with other cloud providers, allowing for multi-cloud deployments where you can take advantage of each cloud’s best features.
It’s important to note that multi-region and multi-cloud deployments can have significant cost-implications due to cross-region and cross-cloud traffic costs, so you must carefully consider your architectural pattern of choice.
Every Region and service can have slightly different network costs. Use the AWS Pricing Calculator to calculate your estimated network transfer costs in and outside of the region.
There is a plethora of multi-region architectural patterns available from the AWS Blog and AWS Prescriptive Guidance that can assist you when developing a cost-effective multi-region architecture.
Figure 5 - Multi-Region active/active deployment - from AWS Architecture Blog
Some common approaches to achieving multi-region operations are:
In summary, AWS Regions can operate together, and you aren’t restricted to using AWS exclusively; in both cases, it’s important to consider a resilient and cost-effective architecture.
While the new AWS Region creates an opportunity for Kiwi businesses, it’s important to use it for the right reasons. Below are some reasons you might want to adopt the new AWS Region.
Some businesses operate latency-sensitive workloads, such as file servers, which are used by offices in New Zealand. Running file servers from an Australian Region requires configuring high-speed and low-latency connections, and even then, geographical distance will always create a bottleneck. If you’ve deployed workloads such as this in Australia, consider migrating to the New Zealand Region.
Figure 6 - Latency from each city in New Zealand to an EC2 Instance in the AWS New Zealand Region
As the New Zealand Region gains more services, businesses will be able to extend many latency-sensitive workloads to the Region, such as:
Some of these services already exist in the New Zealand Region, while others continue to be introduced. As explained earlier, make sure you factor any cross-region or cross-cloud traffic into your pricing estimates.
If you have IaaS workloads that are currently running on-premises or within another cloud provider, you may be looking to optimise and modernise your applications. AWS offers several types of funded engagements that can perform assessments of and migrate/modernise existing workloads onto AWS.
One option that can prove the value of this choice is the AWS Optimisation and Licensing Assessment (OLA). Usually funded, these assessments provide you with a business case for moving a particular workload to AWS by proving the achievable cost savings over a one, two, and three-year period.
Once an OLA has been completed, if desired, you can move on to migration under the Migration Acceleration Program (MAP), which provides a framework and funding for the migration through a three-phase process: Assess, Mobilise, and Migrate & Modernise.
AWS has particularly refined the developer experience and provides many services and frameworks for application modernisation, such as a dedicated Refactor Spaces feature. This in turn provides teams with the foundational infrastructure to break apart monolithic applications into microservices. Even if the service is unavailable, the architectural pattern can be replicated for application-modernisation projects.
This service, combined with other AWS tooling such as The Cloud Development Kit (CDK), App2Container, and Lambda Powertools provide developers with convenient ways to modernise legacy applications using best practices.
The AWS ecosystem has first-class support for event-driven architecture patterns, for which most of the services used in these patterns are already available in New Zealand. Combined with the other tools and frameworks discussed, the New Zealand Region is a great option for Kiwi businesses looking to plan a long-term migration and modernisation project.
With global uncertainty high, many countries and businesses are looking to place critical workloads in sovereign datacentres where local laws can be enforced. If your business deals with sensitive data, you may want to consider moving your workloads or data to the New Zealand Region.
As businesses look to accelerate AI adoption, even if your data isn’t sensitive, it’s still valuable training data, so it’s important to consider where you store and process it.
The New Zealand Region currently supports S3 and KMS, allowing you to store large amounts of data securely onshore. With many compute services already available such as Step Functions and Batch, you’re able to build complex data pipelines to process and train models from your data entirely within a New Zealand Region.
AWS supports checking against the NZISM standard recommendations through the use of an AWS Conformance Pack, in addition to other standards such as CIS, PCI-DSS, NIST and the like.
The combination of onshore data and adherence to New Zealand standards, allows Kiwi businesses to assure customers that data is both kept onshore, and systems adhere to local standards.
Choosing a cloud provider is a long-term commitment and requires domain-specific knowledge. At Inde Technology, we have expertise across a variety of technologies and platforms and can help you weigh the benefits and costs of technical decisions before you make them.
If you’re considering using the AWS New Zealand Region, consider reaching out to Inde.