{"id":593803,"date":"2025-04-28T10:00:00","date_gmt":"2025-04-28T08:00:00","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/aws-well-architected-application-deployment-best-practices\/"},"modified":"2025-04-28T10:00:00","modified_gmt":"2025-04-28T08:00:00","slug":"aws-well-architected-application-deployment-best-practices","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/","title":{"rendered":"AWS Well-Architected: Best Practices for Application Deployment"},"content":{"rendered":"\n

AWS Well-Architected Framework Deployment<\/h3>\n\n\n\n

Any workload running on AWS has a release strategy. Even if it’s less than perfect, involves many manual steps, and includes areas where problems can creep in, it’s still a strategy. This article aims to help you appreciate why a good AWS Well-Architected Framework Deployment strategy \u2013 one that ensures controlled and reversible changes if things go wrong \u2013 is so important.<\/p>\n\n\n\n

We\u2019ll explore the methods of a good release strategy and the AWS tools that can help us implement them. We\u2019ll reinforce the idea that release velocity and quality are functions of CI\/CD capability\u2014the theory that with greater automation and control comes an increase in high-quality throughput.<\/p>\n\n\n\n

Releasing changes properly is of utmost importance. The right way for one workload isn\u2019t necessarily the right way for another. For example, a mission-critical workload, where any downtime creates a major problem, has different requirements than a rarely used internal tool, where people would likely not even notice periods of downtime.<\/p>\n\n\n\n

It\u2019d be amiss to talk about releasing changes on AWS the right way without talking about infrastructure-as-code (IaC) tools like AWS CloudFormation and Hashicorp Terraform. These tools allow you to define AWS infrastructure in either a procedural or declarative manner, enabling the control and audit of any changes to resources deployed. Whilst we won\u2019t talk about these tools in every subsequent section, know that all strategies should utilise IaC.<\/p>\n\n\n\n

CI\/CD<\/h3>\n\n\n\n

CI\/CD is likely a term you\u2019ve heard before. The acronym stands for \u2018Continuous Integration and Continuous Deployment\u2019. Let\u2019s explore each individually before bringing them back together and looking at some of the tools AWS has to offer.<\/p>\n\n\n\n

Continuous Integration<\/h4>\n\n\n\n

Continuous Integration (CI) refers to automated pipelines that do everything short of releasing workloads within the software development lifecycle. Some activities may include building artefacts, running tests, performing static analysis, checking code formatting and quality, and notifying developers of success or failure. The key driver behind a CI pipeline embeds the concept of \u2018shifting responsibility left\u2019, empowering developers to find out earlier if their proposed change will successfully integrate into the live system \u2013 also known as \u2018failing fast\u2019.<\/p>\n\n\n\n

Continuous Deployment<\/h4>\n\n\n\n

Continuous Deployment (CD) automatically deploys software or infrastructure configuration when it detects changes in source code. Typically, teams set this up with Git branches as the source, and pipelines trigger when they merge feature branches into these. Infrastructure-as-code is especially important here \u2013 defining your infrastructure in a way that you can compare against actual deployed infrastructure becomes invaluable when you incrementally release changes.<\/p>\n\n\n\n

For example, consider the following command from the AWS CLI. If this was in a script that ran to set up infrastructure, it could only run once before failing on subsequent attempts due to the bucket already existing.<\/p>\n\n\n\n

\"AWS<\/figure>\n\n\n\n

Let\u2019s compare it to an infrastructure-as-code tool, Terraform. The configuration below defines the desired state of our infrastructure rather than the commands required to create our infrastructure. When Terraform runs for the first time, it will create the bucket. On subsequent runs, it knows that the bucket already exists and doesn\u2019t try to create it again.<\/p>\n\n\n\n

\"AWS<\/figure>\n\n\n\n

Combining CI and CD<\/h4>\n\n\n\n

CI\/CD combines the best of both worlds. With greater confidence in proposed changes via CI pipelines and greater control of enacting changes via CD pipelines, the velocity and quality of releases increase. Any development team in this day and age should be utilising modern DevOps techniques such as CI\/CD pipelines.<\/p>\n\n\n\n

AWS tools<\/h4>\n\n\n\n

There are many tools on the market for CI\/CD pipelines. AWS has a first-party offering that supports both CI and CD use cases: AWS CodePipeline.<\/p>\n\n\n\n

AWS CodePipeline<\/a> is there to help orchestrate the varying stages in a pipeline, pulling from a source code repository and doing something with it. CodePipeline can pass artefacts between stages by storing outputs in an Amazon S3 bucket. Typical stages a pipeline might run through are Source, Build, Test, and Deploy. CodePipeline also supports manual approval steps, where stakeholders can be notified that a release is ready for human validation before progressing.<\/p>\n\n\n\n

AWS CodeBuild<\/a><\/strong> often pairs with CodePipeline as a way to run shell scripts. It runs these scripts inside a container and can serve a variety of purposes. Ultimately, you can implement any commands you need to run for deployments in a CodeBuild job, and they will form part of your CI\/CD pipeline.<\/p>\n\n\n\n

CodePipeline integrates with much more than just CodeBuild. Check out the full list of integrations<\/a>.<\/p>\n\n\n\n

AWS Well-Architected Framework Deployment Strategies<\/h3>\n\n\n\n

There are several deployment strategies that can be employed, and each has its place. Let\u2019s explore each one in more detail before moving on to the AWS tools that are there to make our lives easier.<\/p>\n\n\n\n

In-place<\/h4>\n\n\n\n

In-place deployment refers to releasing a new version of the application on the same infrastructure that\u2019s currently serving the live version. If you’re only running one instance of your application, this will cause downtime because you have to stop the existing version and then install and start the new one.
To avoid downtime, you can combine the in-place deployment strategy with the rolling strategy.We\u2019ll explore this a bit further later.<\/p>\n\n\n\n

All-at-once<\/h4>\n\n\n\n

All-at-once deployment is pretty much what it says on the tin. Consider a horizontally scaled application running on ECS. This deployment strategy would replace all the ECS tasks in the service at once with the new version of the application. As soon as the new version is released, the old tasks no longer exist.<\/p>\n\n\n\n

A major disadvantage of this is that you do not have the opportunity to test a release with production traffic before the new release serves all production traffic. If a bug is introduced, all users could be affected and experience downtime while you redeploy the old version.<\/p>\n\n\n\n

Blue\/green<\/h4>\n\n\n\n

A blue\/green strategy involves deploying two variants of the application at once, where only one is live. Blue refers to the live version, and green refers to the idle version. To begin with, the blue variant is the existing release of the application, whilst the green variant is the new release sitting idly. After they test the new variant, blue and green switch, so the new variant goes live and the old version becomes idle. If all goes well, the old version (green) should be tidied up.<\/p>\n\n\n\n

This strategy offers an advantage over all-at-once because if bugs appear in the new version, you can easily and quickly redirect all traffic back to the old release. However, a disadvantage is that you still don\u2019t test it with any production traffic before switching everything over.<\/p>\n\n\n\n

Canary<\/h4>\n\n\n\n

Canary deployments start to introduce some nice behaviours and resolve the disadvantages we’ve seen so far. With a canary deployment, someone deploys a new version of the application and makes it available to a small subset of users. These users are the \u2018canaries\u2019. If they experience no errors, the deployment proceeds incrementally and slowly. When it reaches a pre-determined point, and there’s a high degree of confidence that the new version works, the system shifts all traffic to the new version and destroys the old one.<\/p>\n\n\n\n

The major advantage is that the system gradually exposes the new release to production traffic, and you have plenty of opportunities to switch back to the old version. Switching back doesn\u2019t sacrifice any capacity, as the system maintains the two application variants independently.<\/p>\n\n\n\n

A\/B testing<\/h4>\n\n\n\n

A\/B testing is slightly different from the others in that it could be combined with each of them. It\u2019s more of a way of testing features and determining impact. This is often also referred to as feature flags.<\/p>\n\n\n\n

Suppose your application has a new feature you want to test with only 10% of your users. Rather than deploying a whole new set of infrastructure and shifting 10% of the traffic to it, which wouldn\u2019t guarantee the same users each time, you deploy a new release with logic at the application level to determine what functionality to serve. Certain users could have a flag set in the database that signifies they are within the chosen sample, and then code similar to the snippet below could handle switching functionality.<\/p>\n\n\n\n

\"AWS<\/figure>\n\n\n\n

There are significantly more graceful ways to use A\/B testing and feature flags, and some very good open-source and commercial offerings are available. The brief example above is provided for easy illustration.<\/p>\n\n\n\n

Rolling<\/h4>\n\n\n\n

Rolling deployments resemble canary deployments in that the system gradually exposes the new version of the application to production traffic. The key difference is that rolling deployments proceed through each instance of the application, whereas canary deployments are more staged; the canary strategy reaches a certain point and then switches all over, whereas rolling continues to trundle on at the same pace.<\/p>\n\n\n\n

One disadvantage of rolling deployments is that, because it replaces instances of the application as it goes rather than incrementally shifting traffic, it can be slower to roll back changes and get back to full capacity. In comparison, canary deployments maintain two versions and shift traffic between them, removing the old version when the overall deployment is successful.<\/p>\n\n\n\n

AWS tools<\/h3>\n\n\n\n

Various tools within AWS are available depending on how a workload is deployed. Let\u2019s explore in more detail three ways in which AWS can help.<\/p>\n\n\n\n

API Gateway<\/h4>\n\n\n\n

Serverless \u2013 my favourite! API Gateway<\/a> supports two of the deployment strategies we\u2019ve looked at.<\/p>\n\n\n\n

When you’re ready to release a new version of an API, the system creates a deployment. This deployment exists as an immutable representation of the new configuration you’re about to release. An API Gateway stage points to a deployment (or deployments).<\/p>\n\n\n\n

With API Gateway, a stage can switch all traffic to the new deployment, implementing a form of the blue\/green deployment strategy. Unlike a blue\/green deployment using a service like Amazon EC2, where the system creates and terminates instances, the old deployment in API Gateway doesn\u2019t go anywhere. Because of this, you can very easily roll back if you find any bugs in the new version, even weeks later.<\/p>\n\n\n\n

Alternatively, you can set up a stage as a \u2018canary deployment\u2019. As we\u2019ve learned, the system sends some traffic to the new deployment and some to the old. When we’re confident that the new release is error-free, the system directs all traffic to the new deployment.<\/p>\n\n\n\n

CodeDeploy<\/h4>\n\n\n\n

AWS CodeDeploy<\/a>\u00a0supports releasing to EC2 instances, Lambda functions, or ECS services. The platform you\u2019re releasing will determine which deployment strategies are available to you.<\/p>\n\n\n\n

EC2 instances<\/h5>\n\n\n\n

Deploying to EC2 instances supports the in-place deployment strategy and blue\/green strategy.<\/p>\n\n\n\n

For in-place deployments, the new application can be deployed to the instance\/s all at once, one half at a time, or one instance at a time. The fewer instances you deploy to at once, the greater the chance you have to catch errors, but the slower the release is.<\/p>\n\n\n\n

For blue\/green deployments, CodeDeploy will provision new instances in the green environment. Traffic can be shifted to this environment at once or one half at a time.<\/p>\n\n\n\n

Lambda functions<\/h5>\n\n\n\n

Lambda functions do not support in-place deployments. The supported deployment strategy is blue\/green, and then traffic can be shifted using three different methods.<\/p>\n\n\n\n

When CodeDeploy deploys a new version of a Lambda function, it can shift traffic all at once. If this is too risky, then canary deployments are also supported. For example, CodeDeploy has a predefined configuration for shifting 10% of traffic and then shifting the remaining 90% 10 minutes later. If you need more confidence around your new function version handling increasing amounts of load, linear strategies are possible. For example, shift 10% of the traffic every 2 minutes. Linear is very similar to rolling; however, rolling is typically more applicable when you\u2019ve got a finite number of instances to deploy to\u2014for example, 10 EC2 instances behind a load balancer in an auto-scaling group.<\/p>\n\n\n\n

ECS services<\/h5>\n\n\n\n

In the context of CodeDeploy, the functionality it supports when your workload runs as an Amazon ECS service is exactly the same as that for Lambda functions. Everything\u2019s under the umbrella of blue\/green here.<\/p>\n\n\n\n

CodeDeploy can shift all traffic to the green version at once or follow the canary or linear strategy of introducing traffic to the new application release in multiple stages.<\/p>\n\n\n\n

Application Load Balancer<\/h4>\n\n\n\n

Application Load Balancer (ALB)<\/a> is a tool that supports implementing deployment strategies rather than a service that will orchestrate the process for you. With CodeDeploy, you can define a strategy (e.g. CodeDeployDefault.ECSLinear10PercentEvery3Minutes), whereas with ALB you would need to implement the logic yourself.<\/p>\n\n\n\n

The core ALB functionality that enables different deployment strategies is weighted target groups. This is an extension of the normal target group functionality. To set the scene, target groups attach to an ALB listener rule and define where the system should send requests when rules match. For example, someone could set up a listener on port 443 with a rule that dictates it should forward any requests with a path matching the pattern \/api\/*<\/code>. A target group containing EC2 instances would attach to this rule to handle all API requests.<\/p>\n\n\n\n

Weighted target groups allow you to specify the percentage of traffic that should be directed to each target group. With this functionality, a number of strategies are possible. Once the new target group has been attached, you could opt to shift 100% in one go. You could follow the canary strategy and shift 10% before shifting the remaining 90% after a set time period, or you could implement a linear traffic shift with 10% of traffic shifting each minute.<\/p>\n\n\n\n

The biggest advantage of implementing this all through an ALB is that it\u2019s agnostic to the service it\u2019s routing traffic to. It doesn\u2019t care if you\u2019re running a strange operating system on your EC2 instances that isn\u2019t supported by CodeDeploy. The downside is that you\u2019re responsible for implementing these strategies yourself; there are no predefined helpers, and it\u2019s up to your continuous deployment pipelines to include scripts to shift the traffic while ensuring the new deployment is healthy.<\/p>\n\n\n\n

AWS Well-Architected Framework Deployment Overview<\/h3>\n\n\n\n

Modern DevOps and the use of CI\/CD pipelines form a large part of the Operational Excellence pillar within the AWS Well-Architected Framework. If you\u2019ve read this and would like assistance improving the quality and velocity of releasing into AWS,\u00a0contact our experts. <\/a><\/strong><\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

AWS Well-Architected Framework Deployment Any workload running on AWS has a release strategy. Even if it’s less than perfect, involves many manual steps, and includes areas where problems can creep in, it’s still a strategy. This article aims to help you appreciate why a good AWS Well-Architected Framework Deployment strategy \u2013 one that ensures controlled […]<\/p>\n","protected":false},"featured_media":513163,"template":"","categories":[996,985],"tags":[],"industry":[],"class_list":["post-593803","expert-view","type-expert-view","status-publish","has-post-thumbnail","hentry","category-aws-en-nl","category-cloud-native-architecture-en-nl"],"acf":[],"cards":"\n\t

\n\n\t\t
\"AWS<\/a><\/figure>\n\n\t\t\n\t\t
\n\t

Expert View<\/p>\n\n\t\t\n\t\t

AWS Well-Architected: Best Practices for Application Deployment<\/a><\/h3><\/div>\n\t\t\n\t<\/div>\n\n","yoast_head":"\nAWS Well-Architected: Best Practices for Application Deployment | Devoteam<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"AWS Well-Architected: Best Practices for Application Deployment\" \/>\n<meta property=\"og:description\" content=\"AWS Well-Architected Framework Deployment Any workload running on AWS has a release strategy. Even if it’s less than perfect, involves many manual steps, and includes areas where problems can creep in, it’s still a strategy. This article aims to help you appreciate why a good AWS Well-Architected Framework Deployment strategy \u2013 one that ensures controlled […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/\" \/>\n<meta property=\"og:site_name\" content=\"Devoteam\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"12 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/\",\"url\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/\",\"name\":\"AWS Well-Architected: Best Practices for Application Deployment | Devoteam\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/09\\\/cloud-background.jpg\",\"datePublished\":\"2025-04-28T08:00:00+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/#breadcrumb\"},\"inLanguage\":\"en-NL\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-NL\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/#primaryimage\",\"url\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/09\\\/cloud-background.jpg\",\"contentUrl\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/09\\\/cloud-background.jpg\",\"width\":2560,\"height\":1708},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/aws-well-architected-application-deployment-best-practices\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Expert View\",\"item\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/expert-view\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"AWS Well-Architected: Best Practices for Application Deployment\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/#website\",\"url\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/\",\"name\":\"Devoteam\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/devoteam.info\\\/en-nl\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-NL\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"AWS Well-Architected: Best Practices for Application Deployment | Devoteam","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/","og_locale":"en_US","og_type":"article","og_title":"AWS Well-Architected: Best Practices for Application Deployment","og_description":"AWS Well-Architected Framework Deployment Any workload running on AWS has a release strategy. Even if it’s less than perfect, involves many manual steps, and includes areas where problems can creep in, it’s still a strategy. This article aims to help you appreciate why a good AWS Well-Architected Framework Deployment strategy \u2013 one that ensures controlled […]","og_url":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/","og_site_name":"Devoteam","twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/","url":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/","name":"AWS Well-Architected: Best Practices for Application Deployment | Devoteam","isPartOf":{"@id":"https:\/\/devoteam.info\/en-nl\/#website"},"primaryImageOfPage":{"@id":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/#primaryimage"},"image":{"@id":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/#primaryimage"},"thumbnailUrl":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background.jpg","datePublished":"2025-04-28T08:00:00+00:00","breadcrumb":{"@id":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/#breadcrumb"},"inLanguage":"en-NL","potentialAction":[{"@type":"ReadAction","target":["https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/"]}]},{"@type":"ImageObject","inLanguage":"en-NL","@id":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/#primaryimage","url":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background.jpg","contentUrl":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background.jpg","width":2560,"height":1708},{"@type":"BreadcrumbList","@id":"https:\/\/devoteam.info\/en-nl\/expert-view\/aws-well-architected-application-deployment-best-practices\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/devoteam.info\/en-nl\/"},{"@type":"ListItem","position":2,"name":"Expert View","item":"https:\/\/devoteam.info\/en-nl\/expert-view\/"},{"@type":"ListItem","position":3,"name":"AWS Well-Architected: Best Practices for Application Deployment"}]},{"@type":"WebSite","@id":"https:\/\/devoteam.info\/en-nl\/#website","url":"https:\/\/devoteam.info\/en-nl\/","name":"Devoteam","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/devoteam.info\/en-nl\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-NL"}]}},"uagb_featured_image_src":{"full":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background.jpg",2560,1708,false],"thumbnail":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background-150x150.jpg",150,150,true],"medium":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background-300x200.jpg",300,200,true],"medium_large":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background-768x512.jpg",768,512,true],"large":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background-1024x683.jpg",1024,683,true],"1536x1536":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background-1536x1025.jpg",1536,1025,true],"2048x2048":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/cloud-background-2048x1366.jpg",2048,1366,true]},"uagb_author_info":{"display_name":"lea.mitteaux","author_link":"https:\/\/devoteam.info\/en-nl\/author\/"},"uagb_comment_info":0,"uagb_excerpt":"AWS Well-Architected Framework Deployment Any workload running on AWS has a release strategy. Even if it’s less than perfect, involves many manual steps, and includes areas where problems can creep in, it’s still a strategy. This article aims to help you appreciate why a good AWS Well-Architected Framework Deployment strategy \u2013 one that ensures controlled…","_links":{"self":[{"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/expert-view\/593803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/expert-view"}],"about":[{"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/types\/expert-view"}],"version-history":[{"count":0,"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/expert-view\/593803\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/media\/513163"}],"wp:attachment":[{"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/media?parent=593803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/categories?post=593803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/tags?post=593803"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/devoteam.info\/en-nl\/wp-json\/wp\/v2\/industry?post=593803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}