AMA - QandA on anything AWS related

This is an open QandA forum for the AWS Hands on Thursdays. In these sessions AWS Solution Architects run hands on workshops on all things AWS.

Upcoming AWS Hands on Labs

  • 11Aug - Amazon CloudWatch and Systems Manager Workshop - 4 hrs
  • 18Aug – AMA – QandA on anything AWS related with Ian Falconer
  • 25Aug - Fircy and A3C - Cloud Incident Response and Forensics Training shorturl.at/jPQ38
  • 1Sep - AWS Containers Immersion Day - 7 hrs
  • 8Sep - No workshop scheduled or running Microsoft workloads on AWS
  • 15Sep – No workshop scheduled
  • 22Sep - Fundamentals of Windows on AWS Workshop
  • TBD - CloudEndure Disaster Recovery Workshop - 6 hrs
  • TBD - AWS Managed Services (AMS) self-paced labs - 4 hrs

Qanda

Q: STNO aka Serverless Transit Network Orchestrator workshop request A: The STNO The Serverless Transit Network Orchestrator solution automates the process of setting up and managing transit networks in distributed AWS environments. https://docs.aws.amazon.com/solutions/latest/serverless-transit-network-orchestrator/serverless-transit-network-orchestrator.pdf#welcome

Q: AWS Melbourne region. How will that support multi region Disaster Recovery? A: When the AWS Melbourne region becomes available later in 2022 the following benefits and considerations are worth calling out:

  • Australia will become only the fifth country to have more than one AWS region. ANZ in 2024 offers a third in the region. This highlights the importance of Australia to AWS globally. This is also reflected in AWS being certified strategic and having more than 124 AWS services IRAP assessed.
  • AWS reliability since 2006, as reflected in publically available data has a higher reliability than the alternatives. Therefore the need for operating in more than one region, from a business continuity or disaster recovery perspective, is statistically less needed. But some sectors, healthcare and finance, have legacy and in some cases legislated requirements around multiple regions.
  • Most workloads, not born in the cloud, are challenged in leveraging multi region cloud benefits. There are workarounds but they are often expensive and complicated and the benefits may not be sufficient to justify making them multi region aware; at least for low and critical RTO / RPO. This limits the ability of customers to fail over to another region in any significant capacity. NOTE: this is not an AWS limitation.
  • Network, routing and latency are also to be considered. Again this is not an AWS limitation but hybrid, multi hop, bottleneck routing is complex. It’s time to rethink legacy networking architectures; but this is a journey for many customers. Moving to modernisation, or born in the cloud workloads, is a way to leapfrog here. Something to consider when migrating.
  • AWS and our networking partners, have significant experience and capability here. Those unicorn problems have probably been solved, or architected out by others. Leverage the work of others rather than reinvening the wheel unless it’s necessary.
  • AWS Global infrastructure is designed and implemented differently than legacy technologies. If you are capacity constrained, struggling to automate and suffering reliability issues with legacy infrastructure, then AWS is a different and better option in most cases. You do need to think differently about how you architecture to meet your measures of performance and success. https://aws.amazon.com/about-aws/global-infrastructure/regions_az/?p=ngi&loc=2
  • The pending Melbourne region will, at launch have a smaller availability of all the AWS services. Check out https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/?p=ugi&l=ap as you architect to ensure all the services you want to use are available in the regions you plan to use. If not then reach out to your AWS account and we can submit your requests.

Continue reading articles in my Amazon Web Services series