There was much rejoicing when AWS finally announced the long awaited melbourne region ap-southeast-4 a few months ago.
For many years Azure has boasted a Melbourne “region”, but without the support of “Availbility Zones”. AWS hold each region to a higher standard, in that a region MUST have a minimum number of availability zones.
This minimum number used to be 2, but has been increased to 3. The Melbourne region has 3 availability zones. At the time of writing Azure still doesn’t have support for availability zones in the Melbourne region,
but plans to bring this support online soon.
These subtleties are often lost on decision makers, or at best they have chosen latency over availability.
As a Melbourne based AWS Ambassador and .Net developer, I personally have been waiting with baited breath since AWS originally announced there was going to be a Melbourne region.
So it’s time to take the shiney wrapping off the ap-southeast-4 region and take a look… from a .Net developer’s perspective.
First thing to note is that the Melbourne region (unlike the Sydney AWS region) is not a “default” region. This means you (or someone with appropriate permissions) has to explicitly enable it. This can be done in the AWS Console by clicking on the region selector, and choosing “manage regions” at the very bottom, and then clicking the “Enable” action for the Melbourne region.
As of the AWS cli version 2.10.0, this functionality can be accessed using aws account enable-region ... or aws account disable-region. You can also list the regions and the corresponsing state (enabled/disabled)
using aws account list-regions --max-results 50, so be sure to update your aws cli version if you want to script this.
OK, so I can now switch my console to the ap-southeast-4 region, and start provisioning resources at will. However, as a developer, I try to avoid any form of click-ops where possible… my mantra is… “if it’s not in
code and committed to source control… it never happened”. So my next task is to see if I can re-deploy one of my existing projects… that is committed to source control… into the melbourne region. Should be fairly simple right?
Well, you’d think so, but alas it seems there are a few hurdles. Last year I did an entire series on “How to Productionize an AWS .Net Serverless Application”
(Part1,
Part2).
I figured this would be a good project to try moving to the ap-southeast-4 region.
The first hurdle came from a tool that I have been using to set up my aws profiles in powershell called AwsCredentialsManager. The maintainer (a fellow Melbourne based developer), discovered an issue with using sts tokens for non-default regions, and has since fixed it. I simply needed to update my version of that powershell module.
Turning to the project itself, as I use the aws-lambda-tools-defaults.json file to store my deployment defaults, this is a fairly logical place to start. Currently this file looks like this
{
...
"profile": "sbaldwin:dev",
"region": "ap-southeast-2",
"configuration": "Release",
"s3-bucket": "sbaldwin-dev",
"s3-prefix": "Productionize/",
"template": "serverless.yml",
"stack-name": "productionize",
"template-parameters": ""
}
NOTE: you can specify all of these parameters from the dotnet lambda deploy-serverless ... command, which will override any values set in the json file, but I personally prefer to use this file as it saves typing.
Obviously, we need to change the region from ap-southeast-2 to ap-southeast-4, this should ensure that regardless of what your profile defaults to, the Melbourne region is used. Unfortunately, due
to the issue in AwsCredentialsManager with using sts tokens mentioned above, the powershell module fixes this by looking at the default region, and using the region specific sts endpoint. So I needed to create a new profile defaulting
to the Melbourne region. Next, you need a bucket in the Melbourne region for your deployment. So we get this:
{
...
"profile": "sbaldwin:dev-mel",
"region": "ap-southeast-4",
"configuration": "Release",
"s3-bucket": "sbaldwin-dev-mel",
"s3-prefix": "Productionize/",
"template": "serverless.yml",
"stack-name": "productionize",
"template-parameters": ""
}
OK, that should be job done right? If only!
At this point, it seems I hit a bug in the dotnet lambda tooling. It seems as though there is an issue using AssumeRole (as I was) with non-default regions. So next I attempted using a simple IAM user with long-term credentials (access-key+secret-access-key). This then allowed me to successfully deploy my serverless application without any dramas. Granted, using AssumeRole profiles as I am currently doing, is non-standard. Most people use SSO as recommended by AWS. I use this set up due to one of my current clients having this configuration, so I need to be across any issues that might occur.
So now I have my application deployed to the Melbourne region. While AWS have got their reasons for having default and non-default regions, the nuances of using them and the gotchas that come up in the various tool chains can be a bit of a challenge. Hopefully this will get better as more non-default regions come online, but it’s something to keep in mind if you want to migrate your applications closer to home.
Update - 15-Mar-2023
After some helpful assistance from the github issue I raised with respects to being unable to deploy using AssumeRole, I was able to progress, and discover some more regional nuances. Before I discuss those though, the fix to the deployment issue (if you happen to be using AssumeRole) is to force your sdk to use regional endpoints by setting the appropriate environment variable.
In powershell:
$env:AWS_STS_REGIONAL_ENDPOINTS="regional"
In Command line (Windows)
set AWS_STS_REGIONAL_ENDPOINTS=regional
For more details, refer to this and this.
Lambda Insights layer
It seems that Lambda Insights is currently not available in ap-southeast-4 region, which means I had to remove the layer from my deployment.
Keep an eye on this website for when it does become available.
XRay Not available for API Gateway
As with all new regions, not everything is available when first launched. It seems XRay for API Gateway is one of those, and so I was forced to remove this in order for my API to deploy. This will undoubtebly be resolved over time… hopefully soon.