{"id":593877,"date":"2025-04-28T10:00:00","date_gmt":"2025-04-28T08:00:00","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/aws-well-architected-anticipating-failure\/"},"modified":"2025-05-16T11:04:30","modified_gmt":"2025-05-16T09:04:30","slug":"aws-well-architected-anticipating-failure","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/","title":{"rendered":"AWS Well-Architected: Anticipating Failure"},"content":{"rendered":"\n

This post focuses on the \u2018Anticipate failure\u2019<\/strong>\u00a0design principle, which is contained in the Operational Excellence pillar of the AWS Well-Architected Framework.<\/span> <\/p>\n\n

It will explore Murphy\u2019s law in the context of AWS, discussing various topics ranging from simple auto-healing and scaling of an EC2 instance to full multi-region disaster recovery. Two scenarios will be posed: an SMB SaaS application and a business-critical enterprise application. Decreasing tolerance to failure comes with different recommendations and strategies.<\/p>\n\n

It\u2019s important to note that not every application needs complex multi-region deployments, but architecting with global resilience in mind is something that most would benefit from. Whilst it may not be needed now, it encourages best practices and removes obstacles to future growth.<\/p>\n\n

AWS Well-Architected Failure: Background<\/h2>\n\n

Before we discuss the scenarios mentioned, let\u2019s review some background to ensure we\u2019re all on the same page.<\/p>\n\n

Types of redundancy<\/h3>\n\n

There are two types of redundancy to discuss here: inter-regional and intra-regional. Let\u2019s start with intra-regional.<\/p>\n\n

\"\"<\/p>\n\n

Example architectures using intra-region and inter-region redundancy. Source: Ubertas Consulting.<\/p>\n\n

Intra-regional<\/h4>\n\n

Intra-regional redundancy refers to an application being only as resilient as a single AWS region. In real terms, this setup offers significantly more redundancy than a single on-premises data centre because an AWS region comprises multiple data centres, also known as Availability Zones (AZs). AZs are built so that the failure of one or more data centres within a region won’t disrupt the entire region’s service. You can deploy an application cross-AZ (i.e., into multiple data centres) to protect it against single points of failure.<\/p>\n\n

For most applications built on AWS, it\u2019s recommended to employ this type of redundancy. The chances of an entire region becoming unhealthy are very slim and acceptable to many organisations. Many AWS services will automatically give you redundancy across all AZs in a region. For example, Amazon S3 will store your data across multiple AZs at no additional cost, without you having to specify which AZs to store your objects in.<\/p>\n\n

Inter-regional<\/h4>\n\n

Inter-regional redundancy means you deploy the application across multiple regions. Typically, organisations utilise this type of redundancy for mission-critical applications where even the remote possibility of an entire AWS region becoming unhealthy is unacceptable. Deploying across multiple regions brings benefits and opportunities, but also brings additional complexities. A handful of AWS services do integrate nicely across multiple regions. Still, there are some things to consider, such as replication lag within the context of database services.<\/p>\n\n

AWS Well-Architected Failure: Disaster recovery strategies<\/h3>\n\n

When you want to increase an application’s resilience, you can use a number of architectural strategies. You can apply all of these strategies both inter- and intra-region. However, typically, disaster recovery (DR) tends towards inter-region (i.e. a different region to the application). We\u2019ll review them in increasing cost and decreasing return to operation (RTO) and recovery point objective (RPO) times.<\/p>\n\n

\"AWS<\/p>\n\n

Disaster recovery (DR) strategies. Source: AWS.<\/p>\n\n

Backup and restore<\/h4>\n\n

This is the closest to your \u201ctraditional\u201d DR strategy. Remember the old 3-2-1 backup strategy? Three copies of data, two on different storage types and one on-site. Your teams can back up data to a location separate from the application’s deployment. In the disaster recovery location, you don’t provision or configure any infrastructure, and the disaster recovery process involves setting up the infrastructure and restoring the backups onto it.<\/p>\n\n

Pilot light<\/h4>\n\n

Compared to backup and restore, the pilot light strategy takes a step up by configuring some infrastructure without necessarily provisioning it. For instance, you might configure an ECS service but not run any application instances. This approach shortens the RTO by removing the need to deploy boilerplate configurations, and it keeps costs down because you don’t deploy infrastructure.<\/p>\n\n

Warm standby<\/h4>\n\n

With warm standby, you not only configure infrastructure like in the pilot light strategy, but you also provision a minimal amount of it. If an application’s production specification is 4 tasks running in an ECS service, the warm standby might have 1 task running. This strategy is the first that could functionally serve any traffic, just not at the scale of production.<\/p>\n\n

Active\/Active<\/h4>\n\n

This is the most expensive strategy, but comes with the shortest RTO and RPO timeframes. Unlike strategies like backup and restore, data replication is near-real-time. By taking warm standby a step further, you operate production-scale infrastructure engineered to handle full production traffic immediately. As you might expect, most organisations would recoil at the idea of doubling an application\u2019s infrastructure cost. You\u2019ll normally find this strategy reserved for the most mission-critical of applications.<\/p>\n\n

Scenario 1: An SMB SaaS application<\/h2>\n\n
\"AWS<\/figure>\n\n

The first of our scenarios is an SMB SaaS application. It\u2019s an application that allows people to upload photos of their expense receipts, add some information and share it with their manager for approval.<\/p>\n\n

This application is currently deployed to a large shared virtual private server (VPS). In terms of resiliency, this is about as bad as it gets. Because you deploy only one copy of the application, a server failure would require manual intervention to restore it, making SaaS application customers wait.It\u2019s not a mission-critical application, so it\u2019s not the end of the world, but it is less than ideal.<\/p>\n\n

Improving with AWS<\/h3>\n\n

So, how could this be improved with AWS? The most comparable piece of infrastructure to a shared VPS would be an EC2 instance. Let\u2019s run with that. Similarly to VPS\u2019, an EC2 instance won\u2019t give you resiliency on its own. An architecture with one large server rather than lots of small servers (horizontally scaled) needs to change to really improve this.<\/p>\n\n

To accomplish what we want to do, we need to bring in EC2 Auto Scaling. EC2 Auto Scaling lets you configure a minimum, maximum, and desired count of EC2 instances for launch. Scaling policies can automatically do this (for example, adding an instance when average CPU utilisation exceeds 75% for 5 minutes), or you can do it manually if you predict demand. Auto Scaling also supports replacing unhealthy instances when they have failed. By configuring these scaling groups to spread instances across multiple AZs, you reduce exposure to single AZ failure and increase resilience.<\/p>\n\n

Now, there are some things to keep in mind with this.<\/p>\n\n

Every time an instance is launched or replaced, it gets a new IP address. This means that DNS records end up out of date very quickly. You could do something clever with updating DNS zone records at various points of an EC2 instance lifecycle, but it\u2019s messy and adds more things to go wrong. The best way to architect this is to use an Application Load Balancer and Target Groups. This will allow you to expose one endpoint for the application (the load balancers), and then the target groups keep track of the healthy instances to direct traffic to.<\/p>\n\n

Something else to keep in mind is that your application servers themselves need to be stateless. This means that no data should be stored on the instance itself that you cannot afford to lose. If you have files generated by users, look to use Amazon S3. If you have a database then use Amazon RDS or Aurora. Decoupling stateful data from your application servers is key here.<\/p>\n\n

Scenario 2: A business-critical enterprise application<\/h2>\n\n
\"AWS<\/figure>\n\n

Let\u2019s imagine that we\u2019ve got an enterprise scale financial application that handles the processing of trades for customers in the UK. The application is currently deployed on-premises to a single data centre in London. At a high level, the architecture is quite simple. It is a Java application with a PostgreSQL database for relational data. Generated documents are stored on a file server.<\/p>\n\n

This application is mission-critical, and any extensive downtime risks fines from the regulator. As a result, it has been decided that the application will be migrated into AWS to ease the journey to increased resiliency.<\/p>\n\n

Migrating the application into a single AWS region (e.g London) could massively increase its resilience; however, some argue that deploying to only one region still leaves a higher risk of downtime than they can tolerate. For this reason, when they migrate the application, they will deploy it to London as the primary region and Ireland as the secondary. But what disaster recovery strategy should they use?<\/p>\n\n

We know that downtime is allowed, but not for long. This rules out backup and restore or pilot light strategies. The choice between warm standby and active\/active hinges on comparing infrastructure costs with potential fine costs. For the sake of this article, we’ll assume the fines are too large, thus necessitating active\/active.<\/p>\n\n

At its core, the architecture can look similar to that of the SMB SaaS application. An Auto Scaling Group orchestrates a set of EC2 instances, and an Application Load Balancer fronts them. Amazon Aurora can run the PostgreSQL database that currently runs on-premises, and Amazon S3 can provide scalable and durable storage.<\/p>\n\n

Making it multi-region<\/h3>\n\n

\"AWS<\/p>\n\n

AWS Regions across Europe. Source: AWS.<\/p>\n\n

If it was only running in one region we could leave the architecture at that. Auto Scaling groups would handle launching instances across multiple AZs, S3 is durable across all AZs by default, and Aurora could be configured with instances in multiple AZs.<\/p>\n\n

So, how do we make it multi-region and handle failovers? There are three key areas to make changes to.<\/p>\n\n

Replication of data in Amazon Aurora<\/h4>\n\n

First of all, you need to think about how to make the transactional data stored in Amazon Aurora (PostgreSQL) accessible from the secondary region. To do this, we\u2019ll use Aurora Global Databases. This setup works because multiple clusters deploy across multiple regions, but only the primary region can perform write operations. If the primary region fails, someone can make an API call to initiate the global database failover process. This makes the read-only cluster in the secondary region the primary. This is a similar methodology to read replicas; however, Aurora Global Databases provision entirely separate clusters, allowing you to failover without having to wait for the provisioning of new infrastructure.<\/p>\n\n

Provision infrastructure in another region and update DNS<\/h4>\n\n

Next up, the same infrastructure that\u2019s deployed in the primary region needs to be deployed into our secondary region. As we\u2019re aiming for an active\/active DR strategy, the capacity and sizing of the infrastructure should be the same. (If we were opting for warm standby then we\u2019d have the same infrastructure but scaled down.) Once deployed, we can update the Route53 DNS record to point at the Application Load Balancer in both regions, and use Route53 Health Checks to determine when to return the value for the secondary region.<\/p>\n\n

Replication of data in Amazon S3<\/h4>\n\n

Last of all, we\u2019ll set up bi-directional S3 cross-region replication between our primary region (London) and secondary region (Ireland). This ensures that data copies across in real time. You should configure the application deployed in the secondary region to write to the bucket in its own region. This, along with the bi-directional replication, will ensure that when the primary region returns to full health, it automatically replicates the data back, ready for switchover.<\/p>\n\n

Where do I go next?<\/h2>\n\n

If you\u2019re currently running applications on-premises and need greater resiliency, then you\u2019re looking for a migration into AWS with modernisation. Learn how to successfully migrate with AWS in this article.<\/a> The\u00a0Migration Acceleration Program (MAP)<\/a>\u00a0is a great way to make your investment go further by utilising AWS funding specifically for these scenarios. It\u2019s a straightforward way to get started on the journey to being more resilient to failure.<\/p>\n\n

If you\u2019re already in AWS and looking for an expert eye to help you identify where your architecture could be improved to make it more resilient, a\u00a0Well-Architected Framework Review<\/a>\u00a0sounds like the perfect exercise for you. These are cost-neutral and give you dedicated time with a Solutions Architect to talk through and review your infrastructure and then help get started with remediating their findings.<\/p>\n\n

Contact our experts<\/a><\/strong> and start your migration journey with AWS.<\/p>\n\n

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

This post focuses on the \u2018Anticipate failure\u2019\u00a0design principle, which is contained in the Operational Excellence pillar of the AWS Well-Architected Framework. It will explore Murphy\u2019s law in the context of AWS, discussing various topics ranging from simple auto-healing and scaling of an EC2 instance to full multi-region disaster recovery. Two scenarios will be posed: an […]<\/p>\n","protected":false},"featured_media":570630,"template":"","categories":[751,755],"tags":[],"industry":[],"class_list":["post-593877","expert-view","type-expert-view","status-publish","has-post-thumbnail","hentry","category-aws-uk","category-cloud-native-architecture"],"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: Anticipating Failure<\/a><\/h3><\/div>\n\t\t\n\t<\/div>\n\n","yoast_head":"\nAWS Well-Architected: Anticipating Failure | Devoteam<\/title>\n<meta name=\"description\" content=\"Learn how to anticipate failure with AWS Well-Architected Framework, implement robust recovery strategies, and build cloud applications.\" \/>\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\/uk\/expert-view\/aws-well-architected-anticipating-failure\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"AWS Well-Architected: Anticipating Failure\" \/>\n<meta property=\"og:description\" content=\"Learn how to anticipate failure with AWS Well-Architected Framework, implement robust recovery strategies, and build cloud applications.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/\" \/>\n<meta property=\"og:site_name\" content=\"Devoteam\" \/>\n<meta property=\"article:modified_time\" content=\"2025-05-16T09:04:30+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1080\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/\",\"url\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/\",\"name\":\"AWS Well-Architected: Anticipating Failure | Devoteam\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/09\\\/Amplify-cloud-landscape-05.jpg\",\"datePublished\":\"2025-04-28T08:00:00+00:00\",\"dateModified\":\"2025-05-16T09:04:30+00:00\",\"description\":\"Learn how to anticipate failure with AWS Well-Architected Framework, implement robust recovery strategies, and build cloud applications.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/#primaryimage\",\"url\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/09\\\/Amplify-cloud-landscape-05.jpg\",\"contentUrl\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/09\\\/Amplify-cloud-landscape-05.jpg\",\"width\":1920,\"height\":1080,\"caption\":\"AWS Well-\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/aws-well-architected-anticipating-failure\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Expert View\",\"item\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/expert-view\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"AWS Well-Architected: Anticipating Failure\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/#website\",\"url\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/\",\"name\":\"Devoteam\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"AWS Well-Architected: Anticipating Failure | Devoteam","description":"Learn how to anticipate failure with AWS Well-Architected Framework, implement robust recovery strategies, and build cloud applications.","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\/uk\/expert-view\/aws-well-architected-anticipating-failure\/","og_locale":"en_GB","og_type":"article","og_title":"AWS Well-Architected: Anticipating Failure","og_description":"Learn how to anticipate failure with AWS Well-Architected Framework, implement robust recovery strategies, and build cloud applications.","og_url":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/","og_site_name":"Devoteam","article_modified_time":"2025-05-16T09:04:30+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Estimated reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/","url":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/","name":"AWS Well-Architected: Anticipating Failure | Devoteam","isPartOf":{"@id":"https:\/\/devoteam.info\/uk\/#website"},"primaryImageOfPage":{"@id":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/#primaryimage"},"image":{"@id":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/#primaryimage"},"thumbnailUrl":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg","datePublished":"2025-04-28T08:00:00+00:00","dateModified":"2025-05-16T09:04:30+00:00","description":"Learn how to anticipate failure with AWS Well-Architected Framework, implement robust recovery strategies, and build cloud applications.","breadcrumb":{"@id":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/"]}]},{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/#primaryimage","url":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg","contentUrl":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg","width":1920,"height":1080,"caption":"AWS Well-"},{"@type":"BreadcrumbList","@id":"https:\/\/devoteam.info\/uk\/expert-view\/aws-well-architected-anticipating-failure\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/devoteam.info\/uk\/"},{"@type":"ListItem","position":2,"name":"Expert View","item":"https:\/\/devoteam.info\/uk\/expert-view\/"},{"@type":"ListItem","position":3,"name":"AWS Well-Architected: Anticipating Failure"}]},{"@type":"WebSite","@id":"https:\/\/devoteam.info\/uk\/#website","url":"https:\/\/devoteam.info\/uk\/","name":"Devoteam","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/devoteam.info\/uk\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"}]}},"uagb_featured_image_src":{"full":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg",1920,1080,false],"thumbnail":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05-150x150.jpg",150,150,true],"medium":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05-300x169.jpg",300,169,true],"medium_large":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05-768x432.jpg",768,432,true],"large":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05-1024x576.jpg",1024,576,true],"1536x1536":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05-1536x864.jpg",1536,864,true],"2048x2048":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/09\/Amplify-cloud-landscape-05.jpg",1920,1080,false]},"uagb_author_info":{"display_name":"lea.mitteaux","author_link":"https:\/\/devoteam.info\/uk\/author\/"},"uagb_comment_info":0,"uagb_excerpt":"This post focuses on the \u2018Anticipate failure\u2019\u00a0design principle, which is contained in the Operational Excellence pillar of the AWS Well-Architected Framework. It will explore Murphy\u2019s law in the context of AWS, discussing various topics ranging from simple auto-healing and scaling of an EC2 instance to full multi-region disaster recovery. Two scenarios will be posed: an…","_links":{"self":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/expert-view\/593877","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/expert-view"}],"about":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/types\/expert-view"}],"version-history":[{"count":0,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/expert-view\/593877\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/media\/570630"}],"wp:attachment":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/media?parent=593877"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/categories?post=593877"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/tags?post=593877"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/industry?post=593877"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}