AWS：結(jié)構(gòu)完善？現(xiàn)代云應(yīng)用程序的體系結(jié)構(gòu)評論

在應(yīng)用程序開發(fā)和后續(xù)操作的上下文中，時(shí)不時(shí)地會(huì)出現(xiàn)一個(gè)問題：“我實(shí)際上是否正確地做到了這一點(diǎn)”？可以使用體系結(jié)構(gòu)審查來確定是否遵循最佳實(shí)踐以及體系結(jié)構(gòu)中是否存在任何風(fēng)險(xiǎn)。

AWS架構(gòu)完善的框架支持云架構(gòu)師為其應(yīng)用程序開發(fā)安全，高性能，故障安全和高效的基礎(chǔ)架構(gòu)。本文說明了如何在實(shí)踐中實(shí)現(xiàn)“結(jié)構(gòu)完善的框架”中的概念。使用行業(yè)的軼事和最佳實(shí)踐，作者還將解決來自德國中型公司的IT經(jīng)理的關(guān)注。

事實(shí)證明，架構(gòu)評估是識(shí)別薄弱環(huán)節(jié)的有效工具。我們理解“架構(gòu)”一詞是指軟件和基礎(chǔ)架構(gòu)的結(jié)合。通過有針對性的問題，可以發(fā)現(xiàn)可能危害項(xiàng)目成功的風(fēng)險(xiǎn)。我們還可以確定是否已應(yīng)用行業(yè)最佳實(shí)踐，質(zhì)量和合規(guī)性標(biāo)準(zhǔn)得到滿足，并獲得了項(xiàng)目狀態(tài)的真實(shí)概況。

根據(jù)項(xiàng)目的規(guī)模，體系結(jié)構(gòu)可能非常龐大和復(fù)雜。多個(gè)團(tuán)隊(duì)參與其中，將多個(gè)服務(wù)的架構(gòu)整合在一起，這并不少見。在這樣的環(huán)境中，通過體系結(jié)構(gòu)評估檢查項(xiàng)目的預(yù)定義質(zhì)量，技術(shù)和功能目標(biāo)就顯得尤為重要。為此可能有不同的評估方法。

一種可能的方法是架構(gòu)權(quán)衡分析方法（ATAM[1]），該方法于2000年在卡耐格梅隆大學(xué)提出。這種方法主要用于分析軟件體系結(jié)構(gòu)，是基于在每個(gè)主要項(xiàng)目中都會(huì)進(jìn)行權(quán)衡的知識(shí)。此方法的目的是了解與系統(tǒng)質(zhì)量要求有關(guān)的體系結(jié)構(gòu)決策的后果。

但是，形式化的體系結(jié)構(gòu)評估也受到批評，認(rèn)為部分評估不適用于實(shí)際項(xiàng)目。特別是，當(dāng)項(xiàng)目具有不斷變化的技術(shù)或業(yè)務(wù)需求，由小型團(tuán)隊(duì)進(jìn)行監(jiān)督并因此依賴于某些折衷方案（例如，缺乏內(nèi)部文檔，架構(gòu)圖等）時(shí)，很難通過正式的架構(gòu)評估來檢查架構(gòu)方法。Neil B.Harrison和Paris Avgeriou在2012年提出了“基于模式的架構(gòu)審查（PBAR）[2]”提案，以解決這些問題。）?；谲浖_發(fā)中已知的設(shè)計(jì)模式，Harrison和Avgeriou在PBAR中嘗試使用模式和質(zhì)量特征之間的關(guān)系，以實(shí)現(xiàn)“輕便，簡單但集中的”架構(gòu)評估形式。

傳統(tǒng)上，許多組織與架構(gòu)團(tuán)隊(duì)合作，而架構(gòu)團(tuán)隊(duì)通常位于產(chǎn)品和/或功能團(tuán)隊(duì)的上游。通常由跨學(xué)科專家組成的架構(gòu)團(tuán)隊(duì)通常使用TOGAF或Zachman Framework[3]?，F(xiàn)代的軟件開發(fā)方法通過責(zé)任和能力的下放來保證優(yōu)勢。但是，各個(gè)團(tuán)隊(duì)之間決策權(quán)的分配也會(huì)帶來風(fēng)險(xiǎn)。必須確保團(tuán)隊(duì)符合內(nèi)部標(biāo)準(zhǔn)，并在最好的情況下超過內(nèi)部標(biāo)準(zhǔn)。

AWS開發(fā)和運(yùn)營數(shù)百萬用戶使用的云服務(wù)。在AWS，我們與分散的開發(fā)團(tuán)隊(duì)合作，我們希望每個(gè)團(tuán)隊(duì)都能創(chuàng)建架構(gòu)并根據(jù)最佳實(shí)踐進(jìn)行工作。為了減輕上述風(fēng)險(xiǎn)，我們借助數(shù)據(jù)定義了最佳實(shí)踐。但是，內(nèi)部開發(fā)團(tuán)隊(duì)只是經(jīng)驗(yàn)的一種來源。此外，我們與AWS Cloud Platform的用戶積極合作，收集小型初創(chuàng)公司對全球企業(yè)的反饋，并從中得出更多最佳實(shí)踐。多年以來，我們將這些最佳實(shí)踐形式化，并開發(fā)了構(gòu)成完善框架基礎(chǔ)的測試機(jī)制。該框架包含統(tǒng)一編譯的，行之有效的方法客戶和合作伙伴可借此評估體系結(jié)構(gòu)。AWS架構(gòu)完善的框架已經(jīng)存在超過8年，并且正在不斷開發(fā)中。版本8當(dāng)前可用。

AWS架構(gòu)完善的框架簡介

AWS架構(gòu)完善的框架通過問卷調(diào)查使這些最佳實(shí)踐切實(shí)可行。通過回答這些問題，可以探索架構(gòu)與云最佳實(shí)踐的協(xié)調(diào)程度。此外，該框架還提供了有關(guān)如何改善發(fā)現(xiàn)的漏洞的詳細(xì)說明。

AWS架構(gòu)完善的框架基于5個(gè)考慮不同方面的支柱。具體來說，這些是：卓越運(yùn)營，安全性，可靠性，性能效率和成本優(yōu)化。在下文中，我們將仔細(xì)研究各個(gè)支柱背后隱藏的內(nèi)容。

·卓越運(yùn)營支柱負(fù)責(zé)所提供系統(tǒng)的執(zhí)行和監(jiān)視。目的是為業(yè)務(wù)創(chuàng)造實(shí)際的附加值，并不斷優(yōu)化流程和程序。重要方面是變更的自動(dòng)化，有效地處理運(yùn)營中斷以及定義日常運(yùn)營管理標(biāo)準(zhǔn)。在此基礎(chǔ)上，本支柱考慮了有效組織團(tuán)隊(duì)的主題以及促進(jìn)創(chuàng)新的手段。

·安全支柱涉及信息和系統(tǒng)的保護(hù)。最重要的主題包括機(jī)密性和數(shù)據(jù)完整性，權(quán)限管理（包括個(gè)人授權(quán)的定義和管理），系統(tǒng)保護(hù)以及建立用于檢測安全事件的控件。

·可靠性支柱致力于確保工作負(fù)載在正確的時(shí)間正確，一致地執(zhí)行其預(yù)期的功能。彈性工作負(fù)載可從中斷中快速恢復(fù)，以滿足業(yè)務(wù)和客戶需求。這里的重要方面是分布式系統(tǒng)設(shè)計(jì)，恢復(fù)計(jì)劃和變更處理。

·性能和效率的支柱涉及IT和計(jì)算資源的有效利用。首要問題包括根據(jù)工作量選擇合適的資源，監(jiān)視性能以及制定明智的決策以隨著業(yè)務(wù)增長保持效率。

·成本優(yōu)化支柱致力于避免不必要的成本。成功的關(guān)鍵是創(chuàng)建成本可見性，定義預(yù)算并定期分析支出，并在此基礎(chǔ)上不斷優(yōu)化支出。

AWS架構(gòu)完善的框架基于通用設(shè)計(jì)原則，有助于實(shí)現(xiàn)云中應(yīng)用程序的良好設(shè)計(jì)。例如，一種這樣的原理就是開發(fā)數(shù)據(jù)驅(qū)動(dòng)的體系結(jié)構(gòu)。測量架構(gòu)決策的影響并基于此對架構(gòu)進(jìn)行基于事實(shí)的進(jìn)一步開發(fā)已成為可能。該體系結(jié)構(gòu)的每個(gè)新版本都提供了新的數(shù)據(jù)點(diǎn)，可以在這些數(shù)據(jù)點(diǎn)上建立持續(xù)的演進(jìn)。

基于一般設(shè)計(jì)原則，為每個(gè)支柱導(dǎo)出了特定原則?，F(xiàn)在可以使用適當(dāng)?shù)膯栴}來測量要測試的體系結(jié)構(gòu)的實(shí)施程度，然后可以從中得出審查結(jié)果。

進(jìn)行結(jié)構(gòu)完善的框架審查的最有效方法是什么？

要進(jìn)行成功的審查，首先必須確保每個(gè)人都在談?wù)撏患隆Ｕб豢?，這似乎是微不足道的，但實(shí)際上，對于一個(gè)看似明確的評論主題，人們有很多不同的看法。例如，電子商務(wù)堆棧下的評論的一個(gè)參與者可能僅理解提供在線商店的應(yīng)用程序，而其他參與者還包括運(yùn)行時(shí)環(huán)境，例如容器運(yùn)行時(shí)。還有一些人還將在術(shù)語“電子商務(wù)堆棧”下添加庫存系統(tǒng)。兩種觀點(diǎn)都沒有錯(cuò)，但是在審查開始時(shí)就建立通用觀點(diǎn)極為重要。為此，您可以共同定義要考慮的工作負(fù)載。

在我們同意要分析的工作負(fù)載之后，另一個(gè)重要步驟是就工作負(fù)載的通用版本達(dá)成一致。開發(fā)人員可能會(huì)在工作負(fù)載的當(dāng)前狀態(tài)下考慮其最后的代碼更改，而從操作的角度來看，這種更改尚未實(shí)現(xiàn)。反過來，架構(gòu)師可以考慮已經(jīng)設(shè)計(jì)但尚未實(shí)現(xiàn)為當(dāng)前狀態(tài)的改進(jìn)。在這里，將當(dāng)前的生產(chǎn)系統(tǒng)定義為審查的基礎(chǔ)非常有用。

我們已經(jīng)看到，不同的參與者帶來了不同的工作負(fù)載視圖。除了達(dá)成共識(shí)之外，我們還必須讓適當(dāng)?shù)膮⑴c者參與審查，他們可以共同涵蓋《結(jié)構(gòu)完善的框架審查》的各個(gè)方面。顯然，由結(jié)構(gòu)完善的框架的五個(gè)支柱定義的主題范圍非常廣泛。根據(jù)公司的組織，涉及的人員和專業(yè)部門的數(shù)量可能會(huì)很大。在一個(gè)具有功能結(jié)構(gòu)的組織中，必須將來自各個(gè)部門的參與者聚集在一起，以便可以將開發(fā)，運(yùn)營和安全性等各個(gè)方面都包括在內(nèi)。在基于敏捷和獨(dú)立團(tuán)隊(duì)的組織中，涵蓋了工作負(fù)載的各個(gè)方面，在大多數(shù)情況下，邀請團(tuán)隊(duì)進(jìn)行審核就足夠了。無論公司的組織結(jié)構(gòu)如何，重要的是不要忘記業(yè)務(wù)方面。IT系統(tǒng)并不是為自己而建立和運(yùn)行的，而是為客戶服務(wù)并創(chuàng)造附加值的。因此，這些也是重要的方面，應(yīng)在結(jié)構(gòu)完善的框架審查中予以考慮。因此，重要的是，參與評審的人員也應(yīng)滿足這一要求。在敏捷團(tuán)隊(duì)中，與您一起代表客戶觀點(diǎn)的產(chǎn)品所有者就足夠了。不要忘記業(yè)務(wù)方面。IT系統(tǒng)并不是為自己而建立和運(yùn)行的，而是為客戶服務(wù)并創(chuàng)造附加值的。因此，這些也是重要的方面，應(yīng)在結(jié)構(gòu)完善的框架審查中予以考慮。因此，重要的是，參與評審的人員也應(yīng)滿足這一要求。在敏捷團(tuán)隊(duì)中，與您一起代表客戶觀點(diǎn)的產(chǎn)品所有者就足夠了。不要忘記業(yè)務(wù)方面。IT系統(tǒng)并不是為自己而建立和運(yùn)行的，而是為客戶服務(wù)并創(chuàng)造附加值的。因此，這些也是重要的方面，應(yīng)在結(jié)構(gòu)完善的框架審查中予以考慮。因此，重要的是，參與評審的人員也應(yīng)滿足這一要求。在敏捷團(tuán)隊(duì)中，與您一起代表客戶觀點(diǎn)的產(chǎn)品所有者就足夠了。

能夠與參與者一起涵蓋“結(jié)構(gòu)完善的框架審查”中提到的所有領(lǐng)域是基本的，但限制參與者的數(shù)量同樣重要。在太大的小組中，重要的討論常常會(huì)進(jìn)行得太遠(yuǎn)，并且很難在合理的時(shí)間內(nèi)實(shí)施審核。如果參與者組由不同的專業(yè)部門組成，則通常只需在每個(gè)部門中包括一個(gè)替代人選即可。前提是他們可以在審查的背景下充分，充分地代表團(tuán)隊(duì)。開發(fā)和操作工作負(fù)載的關(guān)鍵角色必須在那里。此外，通常更容易找到較小的團(tuán)體的約會(huì)。這是兩個(gè)披薩規(guī)則適用的地方適用[4]。會(huì)議的團(tuán)隊(duì)和參與者的人數(shù)不應(yīng)超過對兩個(gè)比薩餅（美國比薩餅，即8至10人）感到滿意的程度。為了進(jìn)行有效的審查，這里通常少花錢。

審查會(huì)議中的討論是必要的，也很有價(jià)值。這種審查會(huì)議通常是將所有相關(guān)觀點(diǎn)匯集在一起的少數(shù)場合之一。我們要避免的是陷入無用的，可能太詳細(xì)的討論。這里需要積極的節(jié)制，以實(shí)現(xiàn)一個(gè)共同的目標(biāo)。這種審核可以由經(jīng)驗(yàn)豐富的人員（通常是建筑師）很好地進(jìn)行，他們不直接參與工作量，因此可以毫無偏見地領(lǐng)導(dǎo)審核。爭論和其他主題可以在以后的某個(gè)時(shí)間點(diǎn)記錄下來并進(jìn)行處理。如果無法就問題的共同答案達(dá)成共識(shí)，則也應(yīng)注意這一點(diǎn)。如果有分歧，無論當(dāng)前是否已實(shí)施某種方法，流程或最佳實(shí)踐，我們都應(yīng)記錄為未實(shí)施，然后再進(jìn)行檢查。在絕大多數(shù)情況下，分歧是一個(gè)很好的指示，表明至少?zèng)]有整體實(shí)現(xiàn)，因此存在優(yōu)化的潛力。在“結(jié)構(gòu)完善的框架審查”期間的討論經(jīng)常會(huì)發(fā)現(xiàn)信息空白。尤其是在審查更復(fù)雜的工作量時(shí)，在跨團(tuán)隊(duì)經(jīng)理的參與下，團(tuán)隊(duì)發(fā)現(xiàn)，例如，已經(jīng)定義了有關(guān)特定主題的準(zhǔn)則，但是這從未涉及到團(tuán)隊(duì)。在這種情況下，直接進(jìn)行內(nèi)部跟進(jìn)任命以彌合這些差距并不少見。

團(tuán)隊(duì)如何處理審查的想法？有什么問題嗎？

重要的是在實(shí)際審核之前定義審核的目的。動(dòng)機(jī)可能多種多樣。例如，負(fù)責(zé)工作量的團(tuán)隊(duì)可能想自己分析當(dāng)前工作量架構(gòu)存在哪些弱點(diǎn)。缺陷通?？梢钥焖俜治?。但是即使在這種情況下，也必須確保沒有任何涉案人員害怕承認(rèn)錯(cuò)誤，或者很容易為自己的工作辯護(hù)或使自己看起來更好。實(shí)現(xiàn)此目的的最簡單方法是事先澄清，審核結(jié)果僅保留在直接參與的人員中。

另一個(gè)動(dòng)機(jī)可能是記錄發(fā)現(xiàn)的弱點(diǎn)以及糾正這些弱點(diǎn)所需的工作，以便在此基礎(chǔ)上要求額外的資源，例如員工或時(shí)間。如果清楚地傳達(dá)了這一點(diǎn)，也可以取得良好的結(jié)果。

當(dāng)從外部（例如，由管理層委托）進(jìn)行審核或甚至有動(dòng)機(jī)為外部審核提供數(shù)據(jù)點(diǎn)時(shí)，這是最困難的。盡管存在這種潛在的不舒服的情況，但是在創(chuàng)建一個(gè)可以公開解決問題的信任環(huán)境方面需要付出很多努力。這樣的審核的主持人必須更加嚴(yán)格地質(zhì)疑答案，以實(shí)現(xiàn)現(xiàn)實(shí)的審核結(jié)果的目標(biāo)。

一個(gè)重要方面是調(diào)整參與者的心態(tài)。檢測到的不可訪問性-即使與高風(fēng)險(xiǎn)（高風(fēng)險(xiǎn)項(xiàng)目）相關(guān)聯(lián)-不能記錄故障，但是可以進(jìn)行改進(jìn)。最好在審查中確定這一點(diǎn)，不僅是在發(fā)生風(fēng)險(xiǎn)并可能引起生產(chǎn)損失的時(shí)候。

如何使AWS Well-Architected Framework適應(yīng)我的工作負(fù)載？

AWS架構(gòu)完善的框架的目標(biāo)是提供可應(yīng)用于各種工作負(fù)載的一致原則和最佳實(shí)踐。至關(guān)重要的是，一方面，不能涵蓋特定工作負(fù)載的所有可能方面，另一方面，必須以特定工作負(fù)載所需的深度來處理所有方面。

為了獲得最佳結(jié)果，可以將不適用于正在檢查的工作負(fù)載的各個(gè)方面隱藏起來，這是有幫助的。但是，經(jīng)驗(yàn)表明，在大多數(shù)情況下，經(jīng)過仔細(xì)考慮，這些方法在工作負(fù)載的開發(fā)中將應(yīng)用或?qū)⒃谝院髴?yīng)用。然后有意義的是將這些方面留在審查中，并根據(jù)當(dāng)前狀態(tài)進(jìn)行回答。這確保了這些不會(huì)丟失，并且可以在適當(dāng)?shù)臅r(shí)間計(jì)劃和采取任何必要的措施。

現(xiàn)在，我們已經(jīng)確定可以調(diào)整評論的寬度，現(xiàn)在我們必須確保也可以修改評論的深度，以使其對我們的工作量有意義。這就是AWS結(jié)構(gòu)完善的框架透鏡發(fā)揮作用的地方。這些是AWS Well-Architected Framework的擴(kuò)展。提供各種行業(yè)和技術(shù)特定的鏡頭。例如，可以詳細(xì)檢查包含機(jī)器學(xué)習(xí)的工作負(fù)載的細(xì)節(jié)。

使用AWS架構(gòu)完善的框架可以實(shí)現(xiàn)什么結(jié)果？

AWS架構(gòu)完善的框架審閱的結(jié)果可能多種多樣，并以不同的方式使用。在極少數(shù)情況下，審核結(jié)果將是：一切都已完美實(shí)施，沒有進(jìn)一步的建議。但是即使這樣，由于您現(xiàn)在可以確定工作負(fù)載已合理地進(jìn)行了構(gòu)造，所以這樣的檢查非常有價(jià)值。

完善的框架審查報(bào)告大部分都揭示了許多已識(shí)別的風(fēng)險(xiǎn)以及具體的提議解決方案和建議。這是理想的起點(diǎn)，可以將這些任務(wù)包括在下一個(gè)版本的計(jì)劃中，并根據(jù)已識(shí)別的風(fēng)險(xiǎn)確定優(yōu)先級。架構(gòu)完善的框架審查的結(jié)果被轉(zhuǎn)化為敏捷方法的世界，它產(chǎn)生了許多用戶案例，這些案例已經(jīng)非常有資格轉(zhuǎn)移到待辦事項(xiàng)列表中進(jìn)行優(yōu)先級排序。形象地講，團(tuán)隊(duì)在審查后留下一張桌子，上面貼滿了帖子。

AWS架構(gòu)完善的框架的基本思想是超越一次性審核的用途。在這里定期進(jìn)行檢查是有意義的，這樣可以使完成結(jié)構(gòu)合理的工作負(fù)載的進(jìn)度可見，而發(fā)現(xiàn)的薄弱環(huán)節(jié)可以根據(jù)生成的建議根據(jù)優(yōu)先級進(jìn)行逐步處理。這避免了可能需要壓倒一切的事情，阻止了實(shí)際的實(shí)現(xiàn)。團(tuán)隊(duì)可以以結(jié)構(gòu)化的方式來解決這個(gè)問題。

另一個(gè)應(yīng)用程序是將AWS Well-Architected Framework Reviews納入您自己的開發(fā)流程中。該框架可以為定義新開發(fā)的標(biāo)準(zhǔn)要求提供很好的啟發(fā)。實(shí)際上，建議在“完成的定義”中包括結(jié)構(gòu)完善的框架審查。此支架可用于確保新的開發(fā)盡早考慮結(jié)構(gòu)完善的框架的各個(gè)方面，并從一開始就將其納入設(shè)計(jì)和實(shí)施中。這樣可以避免在開發(fā)階段就已經(jīng)進(jìn)行了后續(xù)的錯(cuò)誤糾正。這將對服務(wù)團(tuán)隊(duì)的生產(chǎn)力產(chǎn)生重大影響。眾所周知，系統(tǒng)中的缺陷導(dǎo)致計(jì)劃外的工作，使我們無法進(jìn)行實(shí)際工作[5]。

我可以使用哪些工具進(jìn)行AWS架構(gòu)完善的框架審查？

另一個(gè)重要方面是工具的良好支持，這些工具使AWS Well-Architected Framework Review得以有效執(zhí)行。良好地訪問問題目錄非常重要，這樣團(tuán)隊(duì)可以一起舒適地回答問題。AWS控制臺(tái)中結(jié)構(gòu)良好的工具[6]可以用于此目的。在這里，團(tuán)隊(duì)可以定義要考慮的工作量并填寫調(diào)查表。該工具在回答問題和詳細(xì)說明方面提供了積極的支持。

對于發(fā)現(xiàn)的每個(gè)漏洞，都會(huì)顯示優(yōu)先級，并建議采取特定的補(bǔ)救措施，使團(tuán)隊(duì)可以更輕松地計(jì)劃和實(shí)施通往AWS架構(gòu)完善的工作負(fù)載的旅程?！皣L試勝于學(xué)習(xí)”的座右銘也適用于這些措施的實(shí)施。如果您有興趣，可以使用AWS Well-Architected Labs[7]，在實(shí)驗(yàn)室環(huán)境中嘗試重要的措施并更好地理解它們，然后再將其應(yīng)用于您自己的，可能很復(fù)雜的工作負(fù)載。

如前所述，有意義的是，不僅要分析給定的工作負(fù)載一次，而且要連續(xù)進(jìn)行分析。該工具支持服務(wù)團(tuán)隊(duì)創(chuàng)建和管理評論的多個(gè)版本。里程碑也可以直接在工具中定義。

借助AWS Identity and Access Management（IAM）服務(wù)[8]，可以定義和控制對審閱數(shù)據(jù)的訪問權(quán)限，以便根據(jù)需要保護(hù)此敏感數(shù)據(jù)。

通過提供的API接口[9]，AWS Well-Architected-Tool可以集成到其他系統(tǒng)中，例如B.可以集成集中的報(bào)告工具；識(shí)別出的風(fēng)險(xiǎn)也可以無縫地轉(zhuǎn)移到現(xiàn)有工具和流程環(huán)境中。

下一步是什么？

如果您將其實(shí)際應(yīng)用于現(xiàn)有工作負(fù)載，則可以很好地訪問AWS架構(gòu)良好的框架。通過這種方式，您不僅可以對工作量和AWS Well-Architected框架有更深入的了解，而且還可以對基礎(chǔ)設(shè)計(jì)原則有更深入的了解，從而可以構(gòu)成未來架構(gòu)決策的基礎(chǔ)。詳細(xì)的在線文檔[10]提供了對該框架的更深入了解。

祝您實(shí)施AWS架構(gòu)完善的工作負(fù)載取得成功！

資料來源

[1]ATAM-Method for Architecture Evaluation

[2]Pattern-Based Architecture Reviews

[3]TOGAF und Zachman Framework

[4]Two-Pizza-Regel

[5]The Phoenix Project:A Novel about IT,DevOps,and Helping Your Business Win,Gene Kim,IT Revolution Press;1.Edition(1.Februar 2018),ISBN-10:1942788290

[6]AWS Management Console

[7]AWS Well-Architected Labs

[8]AWS IAM

[9]AWS Well-Architected Tool-API Reference

[10]AWS Well-Architected Framework

原標(biāo)題：Well-Architected?Architekturreviews für moderne Cloudanwendungen