stanford-oval/wikipedia huggingface dataset:
토이토부르크 숲 전투
뒷수습

대패 소식을 들은 황제 아우구스투스는 충격을 받아 벽에 머리를 찧으면서 “퀸틸리우스 바루스, 내 군단들을 돌려내라(라틴어: Quintili Vare, legiones redde 퀸틸리 바레, 레기오네스 레데[*])!”고 소리질렀다고 한다. 이는 수에토니우스의 《십이황제사》에 기록되어 있다.
이후 로마 군단 단대호에서 17과 19는 영구결번이 되었다. 제18군단은 네로 때 재소집되었지만 베스파시아누스 때 결국 해산되었다. 다른 전쟁들에서 참패를 겪은 군단들이 재건된 것에 비하면 상당히 이례적인 조치였다. 이렇게 제명 처리가 된 또다른 군단으로는 데이오타루스 제22군단이 있다. 제22군단은 기원후 132년-136년 유대 속주에서 일어난 바르 코크바의 난 때 대패를 당한 뒤 폐지되었다.
토이토부르크 숲 전투는 40여년 전 내전기 이후 서유럽에서 연전연승 팽창을 거듭하던 로마의 정복전쟁 시대를 느닷없이 종결시켰다. 아우구스투스의 양자로 입적된 티베리우스가 전쟁을 대비했고, 아우구스투스 제2군단, 승리의 발레리아 제20군단, 쌍둥이 제13군단이 라인 강 서안으로 보내져 소멸된 17-19군단의 빈자리를 메웠다.
아르미니우스는 바루스의 머리를 잘라 심하게 훼손시킨 뒤 로마에게 마르코만니 왕으로 인정받은 마로보두스에게 보내면서 반로마 동맹을 제안했다. 마로보두스는 아르미니우스의 제안을 거절하고 바루스의 머리를 로마로 보내 장례를 치르게 했다. 이후 마로보두스는 로마와 아르미니우스가 싸우는 동안 중립을 지키며 관망했다. 로마가 물러간 이후 기원후 17년부터 아르미니우스와 마로보두스가 맞붙어 싸웠다. 패배한 마로보두스는 기원후 19년 이탈리아로 도망갔다가 로마에 의해 연금에 처해졌다. 아르미니우스도 기원후 21년 암살당했다.
로마의 보복

비록 토이토부르크의 살육의 충격은 엄청났지만, 로마는 곧바로 게르마니아 수복을 준비하기 시작했다. 아우구스투스가 죽고 양자 티베리우스가 제위를 계승한 직후인 기원후 14년, 티베리우스의 조카 게르마니쿠스가 대규모 공격을 감행했다. 게르마니쿠스는 마르시족을 기습했다. 이 기습에 자극받은 브루크테리족, 투반티족, 우시페티족이 겨울 본부로 귀환하는 게르마니쿠스를 습격했지만 심한 손실을 입고 패배했다.
이듬해에는 해군까지 동원하여 55,000-70,000 여명의 대군이 두 차례의 큰 전역과 여러 차례의 작은 전투를 치렀다. 기원후 15년 봄, 총독대리 카에키나 세베루스가 병력 25,000-30,000명을 이끌고 마르시족을 재차 침공해 큰 피해를 입혔다. 한편 게르마니쿠스의 부대는 타우누스 산에 요새를 축성하고 그곳을 거점으로 30,000-35,000명의 병력으로 카티족을 공격했다. 카티족은 강을 건너 도망쳐 숲 속으로 흩어졌다. 이후 게르마니쿠스는 카티족의 수도 마티움으로 진군하여 그곳을 완전히 불태웠다.
기원후 15년의 성공적인 산병전을 치르는 과정에서 로마군은 아르미니우스의 아내 투스넬다를 포로로 잡았다. 그 이후 문제의 참사가 일어났던 장소를 다시 찾게 되었다. 타키투스에 따르면 빛바랜 뼈들이 산더미처럼 쌓여 있었고 두개골들은 나무에 못박혀 있는 것을 발견했다고 한다. 게르마니쿠스의 로마군은 이 뼈들을 수습해 매장했다. 그리고 타키투스가 "긴 방죽길(라틴어: pontes longi 폰테스 롱기[*])"이라고 부른 어떤 장소(오늘날의 엠스 근교의 습한 저지대)에서 아르미니우스가 로마군을 공격했다. 처음에는 아르미니우스가 게르마니쿠스의 기마병들을 함정에 가두어 약간의 피해를 입혔다. 하지만 로마군 보병들이 궤주하지 않고 버티면서 전투가 내리 이틀동안 계속되었다. 양쪽 모두 결정적 승리를 거두지 못했고, 게르마니쿠스는 라인 강 서쪽으로 후퇴했다. 타키투스는 이 전투가 로마군의 승리였다고 기록했지만 근현대의 사학자들은 비겼다고 평가하고 있다.Wells 2003, 206쪽 괄호 없는 하버드 인용 error: 대상 없음: CITEREFWells2003 (help); Smith 1880, 259쪽 괄호 없는 하버드 인용 error: 대상 없음: CITEREFSmith1880 (help)
기원후 16년, 게르마니쿠스가 지휘하는 로마군은 다시 한번 게르마니아 내부로 진군했다. 이번에는 로마와 동맹한 게르만족들도 함께였다. 게르마니쿠스는 아르미니우스가 베저 강을 건너게 만들어 오늘날의 민덴 근교에서 게르만족 산병들에게 약간의 피해를 입혔다. 그리고 이디스타비소에서 아르미니우스와 회전을 벌였다.(베저 강 전투) 이 회전에서 게르마니쿠스의 로마 군단은 게르만족 동맹군에게 큰 피해를 입히면서 자신들은 비교적 적은 피해를 입었다. 이후 오늘날의 하노버 서쪽의 앙그리바리 방벽에서 최후 결전이 벌어졌다. 이번에도 로마군이 승리하여 게르만족들은 엘베강 동쪽까지 밀려났다. 라인 강과 엘베 강 사이의 게르만 부족들을 정복한 게르마니쿠스는 카이우스 실리우스에게 기마병 3,000기와 보병 30,000명의 혼성군을 이끌고 카티족을 공격, 그 영토에 분탕질을 치라고 명령했다. 한편 자기는 주력 병력을 이끌고 마르시족을 세 번째로 침공하여 별다른 저항도 받지 않고 마르시족의 땅을 초토화시켰다.
전략적 목표가 달성되었고 겨울이 다가왔기 때문에 게르마니쿠스는 육군을 겨울 주둔지로 후퇴시켰다. 한편 로마 해군은 북해의 폭풍을 맞아 약간의 피해를 입었다. 몇 차례 더 라인 강을 건너 공격을 하면서 토이토부르크 전투 때 잃었던 세 군단 중 두 군단의 아퀼라를 회수했다. 하나는 14년에 마르시족에게서 회수했고, 다른 하나는 제19군단의 아퀼라로 15년 루키우스 스테르티니우스가 브루크테리족에게서 회수했다. 티베리우스는 로마군에게 라인 강 동쪽으로의 후퇴를 명령했다. 게르마니쿠스는 로마로 소환되어 개선식을 치르고 다른 군단을 지휘하게 될 것임을 통보받았다.
기원후 14년-16년 게르마니쿠스와 세베루스의 게르마니아 정벌
14년
15년
16년
게르마니쿠스의 게르마니아 전역은 토이토부르크 숲 전투에 대한 보복전의 성격을 띠었다. 로마의 안정에 심대한 위협으로 여겨진 아르미니우스는 패배했고, 그의 게르만족 동맹은 분쇄되었다. 더 이상 라인 강 동쪽에서 작전을 벌여 보았자 비용만 들고 얻을 것이 없었기에 전역이 종료된 것이다. 타키투스는 티베리우스가 게르마니쿠스를 소환한 것이 게르마니쿠스가 얻을 영광을 시기했기 때문이라고 사뭇 악의적으로 쓰고 있다. 그는 더 나아가서 이듬해 여름에 한 번 더 전역을 벌였으면 라인 강과 엘베 강 사이의 땅이 로마의 직할령이 되었을 것이라고 성토한다.
세 번째 아퀼라는 기원후 41년 게르마니쿠스의 동생 클라우디우스가 제위에 있을 시절 카우키족에게서 회수되었다.
타키투스의 기록에서 로마의 대게르만 전쟁의 마지막 단계가 기록되어 있다. 기원후 50년경 한 무리의 카티족이 로마 속주인 상게르마니아를 침공했다. 상게르마니아는 라인 강 동안이지만 로마가 지배권을 여전히 유지하고 있었던 것으로 보인다. 카티족이 약탈을 시작하자 로마 사령관 푸블리우스 폼포니우스 세쿤두스의 군단병들과 반기오네스족과 네메테스족에서 징병된 보조군들이 카티족을 협공하여 패퇴시켰다. 카티족에게 붙잡힌 로마인 포로들이 풀려났는데, 그 중에는 바루스의 군단에 소속되어 토이토부르크 숲에서 싸웠다가 거의 40년간 포로생활을 한 이도 있었다.
역사적 영향

로마인들이 남긴 기록은 15세기에 재발굴되었고, 토이토부르크 숲 전투는 로마의 북서유럽 팽창을 종료시킨 분수령적 사건으로 평가받았다. 이런 학설은 19세기에 널리 퍼졌고, 독일 국민주의의 골조 일부를 형성했다.
최근의 일부 학자들은 이런 기존의 해석에 의문을 제기하고 있다. 이들은 게르마니아의 다른 강들이 아닌 라인 강이 로마 제국의 실질적 국경이 된 것은 토이토부르크 숲 전투 때문이 아니고, 그저 라인 강이 기능적으로 가장 적절했기 때문이라고 해석한다. 군수 측면에서 보았을 때, 라인 강에 주둔한 육군은 론 강, 사오네 강, 모젤 강을 통해 지중해로부터 직접적 보급을 받을 수 있었다. 반면 엘베 강에 주둔할 경우 기나긴 내륙 수송을 하거나 위험한 대서양을 항해해야 했다. 또한 경제적으로도 라인 강은 갈리아 정복 때부터 이미 상당한 도시와 촌락들을 먹여살리고 있었다. 북게르마니아는 라인 강 일대에 비하면 미개척지나 다름없었고, 자기들이 먹고 살 식량도 부족했기에 로마가 조공물로 뜯어갈 재화가 없었다. 즉 라인 강은 그저 라인 강 너머의 지역들에 비해 로마 입장에서 지키기도 쉽고 군수적 경제적으로도 적절한 경계였기에 국경이 되었을 뿐이라는 것이다. 또한 아우구스투스 대에 로마의 팽창주의가 중단될 수 밖에 없었던 다른 현실적 이유들도 있었다. 로마는 정복한 속주가 자급자족할 능력이 있기를 원했는데, 그래야 세금을 바칠 수 있기 때문이다. 로마의 무역로에 이미 통합되어 있던 갈리아 지역과 비교하면 대게르마니아 지역 거의 대부분은 그럴 능력이 없었다. 가성비 면에서 따져 봤을 때, 더 이상의 영토를 정복해 봤자 재정 부담만 가중되는 한계에 다다른 것이다.
토이토부르크 숲 전투에 대한 통설이 형성된 19세기 독일에서는 “로마의 진군”이 멈추게 된 이유가 이 전투라고 해석했지만, 실제로는 로마는 토이토부르크 참사 이후로도 게르마니아 지역 깊숙히 여러 차례의 징벌전쟁을 수행했다. 그리고 로마는 야만 부족들이 외교적 말썽을 부리지 않게 만드는 것 이상의 정복이나 팽창을 할 의도도 없어진 상태였다. 기원후 235년의 막시미누스 트락스 황제의 하르초른 고지 전투를 보아도 이런 점은 잘 드러난다. 하르초른 고지는 오늘날의 니더작센주에 있으며, 라인 강도 아니고 베저강 동쪽에 위치한다. 로마는 마르코만니 전쟁 이후에는 심지어 오늘날의 체코, 슬로바키아, 바이에른, 오스트리아, 헝가리에 해당하는 마르코마니아와 사르마티아를 통제하고 있었다. 다만 콤모두스가 이 영토들을 유지하는 것은 재정 부담이 너무 심하다는 이유로 합병을 포기한 것일 뿐이다.
아르미니우스가 죽은 뒤 로마는 리메스 게르마니쿠스 너머 대게르마니아 지역을 간접 통치하려 시도했다. 아르미니우스의 조카 이탈리쿠스가 체루스키의 제후왕으로 임명되고, 쿼디족의 제후왕 반니우스가 마르코만니의 지배자로 인정되었다. 도미티아누스 황제 치세인 91년-92년에는 로마의 제후로 포섭된 게르만 연맹국가 루기가 오늘날의 폴란드 지역의 수에비와 싸울 때 로마군이 파견되어 루기를 돕기도 했다.
같이 보기

칸나이 전투
카레 전투
안개 낀 토이토부르크 숲
칼크리제 근교에서 게르만족이 바루스에게 최후 일격을 날릴 준비를 한 요새를 복원한 것.
토이토부르크 숲 전투 이후의 게르마니아 정치지형도. 분홍색이 아르미니우스가 이끄는 반로마 게르만족 동맹군이다. 녹색은 로마군이 직접 점유한 영역이고, 노란색은 로마의 속국들이다.
기원후 14년-16년 아르미니우스를 상대한 로마 사령관 게르마니쿠스.
클라우드 컴퓨팅

비슷한 이름의 크라우드 컴퓨팅에 관해서는 해당 문서를 참고하십시오.
클라우드 컴퓨팅(영어: cloud computing)은 사용자의 직접적인 활발한 관리 없이 특히, 데이터 스토리지(클라우드 스토리지)와 컴퓨팅 파워와 같은 컴퓨터 시스템 리소스를 필요시 바로 제공(on-demand availability)하는 것을 말한다. 일반적으로는 인터넷 기반 컴퓨팅의 일종으로 정보를 자신의 컴퓨터가 아닌 클라우드에 연결된 다른 컴퓨터로 처리하는 기술을 의미한다. 공유 컴퓨터 처리 자원과 데이터를 컴퓨터와 다른 장치들에 요청 시 제공해준다. 구성 가능한 컴퓨팅 자원(예: 컴퓨터 네트워크, 데이터 베이스, 서버, 스토리지, 애플리케이션, 서비스, 인텔리전스)에 대해 어디서나 접근할 수 있는, 주문형 접근(on-demand availability of computer system resources)을 가능케하는 모델이며 최소한의 관리 노력으로 빠르게 예비 및 릴리스를 가능케 한다. 클라우드 컴퓨팅과 스토리지 솔루션들은 사용자와 기업들에게 개인 소유나 타사 데이터 센터의 데이터를 저장, 가공하는 다양한 기능을 제공하며 도시를 거쳐 전 세계로까지 위치해 있을 수 있다. 클라우드 컴퓨팅은 전기망을 통한 전력망과 비슷한 일관성 및 규모의 경제를 달성하기 위해 자원의 공유에 의존한다.
지지자들은 클라우드 컴퓨팅을 통해 기업들이 선행 투자 인프라스트럭처 비용(예: 서버 구매)을 없앨 수 있다고 주장한다. 그뿐 아니라, 단체들이 컴퓨터 인프라스트럭처에 시간과 비용을 들이는 대신 핵심 사업에 집중할 수 있게 한다. 또, 클라우드 컴퓨팅을 통해 기업들이 자신들의 응용 프로그램의 기동 및 실행 속도를 더 빠르게 할 수 있게 하여 취급 용이성을 개선시키고 유지보수를 줄여줄 수 있게 도와주며 정보기술(IT) 팀들이 유동적이고 예측 불가능한 사업 수요를 충족시키기 위해 자원을 더 빠르게 조절할 수 있게 한다. 클라우드 제공자들은 일반적으로 종량제(pay as you go) 모델을 사용한다. 관리자들이 클라우드 가격 모델에 적응하지 않을 경우 예상 밖으로 높은 비용을 지불할 수 있다.
2009년에 고용량 네트워크, 저비용 컴퓨터 및 스토리지 장치를 이용할 수 있게 되었을 뿐 아니라 하드웨어 가상화, 서비스 지향 아키텍처, 자율 및 유틸리티 컴퓨팅이 널리 채택됨에 따라 클라우드 컴퓨팅의 성장으로 이어졌다. 기업들은 컴퓨팅의 수요가 증가함에 따라 규모를 키울 수 있고, 수요가 줄어들면 규모를 낮출 수 있다. 2013년, 클라우드 컴퓨팅은 높은 컴퓨팅 파워, 값싼 서비스 비용, 고성능, 확장성, 접근성, 이용성의 이점으로 인해 매우 수요가 높은 서비스나 유틸리티가 되었다. 일부 클라우드 업체들은 매년 50%의 성장률을 경험하고 있으나, 초기 단계이기 때문에 클라우드 컴퓨팅 서비스를 더 신뢰할만하고 사용자 친화적으로 만들어야 할 필요가 있다.
역사 > 용어의 기원

"클라우드 컴퓨팅"이라는 용어의 개념은 분명하지 않다. "클라우드"라는 낱말은 일반적으로 과학에서 구름처럼 먼 거리에서 시각적으로 보이는 물건들의 커다란 집합체를 기술하기 위해 사용되며 주어진 문맥에서 세세한 부분이 더 이상 관찰되지 않는 물건들의 집합을 기술한다. 또 다른 설명으로는, 네트워크 도식들을 그려낸 오래된 프로그램들이 서버 아이콘을 원으로 둘러쌌으며 네트워크 도식 안의 서버 클러스터가 여러 겹치는 원들을 가지면서 클라우드(구름)와 닮게 되었다는 것이다. 위의 용례와 비슷하게 클라우드라는 낱말은 인터넷의 비유로서 사용되었으며 구름과 같은 표준화된 모양은 전화 도식망을 나타내기 위해 사용되었다. 나중에 컴퓨터 네트워크 다이어그램에 인터넷을 기술하기 위해 사용되었다. 클라우드 심볼은 이미 1977년의 오리지널 ARPANET 및 1981년의 CSNET의 컴퓨팅 장비망을 표현하기 위해 사용되었으며 둘 다 인터넷의 선구자이다.
클라우드(cloud)라는 용어는 분산 컴퓨팅을 위한 플랫폼을 가리키는 데 사용되고 있다.
현대적 의미의 "클라우드 컴퓨팅"에 대한 참조는 컴팩 내부 문서의 초기 언급과 함께 1996년에 등장하였다.
이 용어가 대중화된 것은 아마존닷컴이 일래스틱 컴퓨트 클라우드를 선보였던 2006년으로 거슬러 올라간다.
역사 > 1970년대

1960년대 동안 시분할의 초기 개념이 RJE(원격 작업 입력)를 통해 대중화되었다. 이 용어는 IBM과 DEC와 같은 대형 업체들과 대부분 연계된다. 완전한 시분할 솔루션들은 1970년대 초에 멀틱스(GE 하드웨어), 케임브리지 CTSS와 최초 유닉스 포트(DEC 하드웨어)와 같은 플랫폼에서 이용이 가능하게 되었다. 그러나 사용자들이 IBM 메인프레임에서 작업을 오퍼레이터에 제출, 수행하는 "데이터 센터" 모델은 압도적으로 우월하였다.
역사 > 1990년대

1990년대에 주로 전용 P2P 데이터 회로를 제공했던 통신 회사들이 필적할만한 서비스 품질에 낮은 가격대로 가상 사설망(VPN) 서비스들을 제공하기 시작했다. 구름 모양의 기호를 사용하여 제공자가 책임져야 하는 것과 사용자가 책임져야 하는 경계점을 표시하기 시작했다. 클라우드 컴퓨팅은 이 경계를 확장하여 모든 서버뿐 아니라 네트워크 인프라스트럭처까지 적용하였다.  컴퓨터들이 더 확산되면서 과학자들과 기술자들은 시분할을 통해 대형 컴퓨팅 파워를 더 많은 사용자들에게 이용하는 방법을 탐구하였다. 그들은 CPU의 우선 순위를 변경하고 최종 사용자의 효율성을 증가시킬 목적으로 인프라스트럭처, 플랫폼, 응용 프로그램들을 최적화하기 위한 알고리즘을 실험하였다.
역사 > 2000년대

2000년 이후로 클라우드 컴퓨팅은 실체를 드러내기 시작했다. 2008년 초, 유럽연합 집행위원회의 투자를 받는 프로젝트 RESERVOIR에서 개량된 NASA의 오픈네뷸라(OpenNebula)는 폐쇄형 클라우드와 혼합형 클라우드를 배치시키고 클라우드들을 연합시키는 최초의 오픈 소스 소프트웨어가 되었다. 같은 해에 유럽연합 집행위원회의 투자를 받는 프로젝트 IRMOS의 프레임워크에서 클라우드 기반 인프라스트럭처에 서비스 품질 보증을 제공하는 노력이 집중되면서 실시간 클라우드 환경이 탄생하였다.
 2008년 중순에 가트너는 클라우드 컴퓨팅이 IT 서비스를 사용하고 판매하는 IT 서비스 소비자들 간의 관계를 형성할 수 있을 것으로 내다보았으며 단체들이 회사 소유 하드웨어 및 소프트웨어 자산을 사용량에 따라 요금을 지불하는 서비스 기반 모델로 옮겨가고 있으며 이로써 일부 분야들의 IT 제품의 성장은 두드러지고 다른 분야들에서는 상당한 감소가 있을 것으로 관찰하였다.
2006년 8월 아마존은 일래스틱 컴퓨트 클라우드를 선보였다. 마이크로소프트 애저는 "애저"(Azure)라는 이름으로 2008년 10월 발표되었고 2010년 2월 1일 "윈도우 애저"(Windows Azure)라는 이름으로 출시되었으며 2014년 3월 25일 마이크로소프트 애저로 이름이 변경되었다. 일시적으로 애저는 TOP500 슈퍼컴퓨터 목록에 등재되었다가 제거되었다. 2010년 7월 랙스페이스 호스팅과 NASA는 공동으로 오픈 소스 클라우드 소프트웨어 이니셔티브에 착수하였는데, 그 이름이 오픈스택이다. 오픈스택 프로젝트는 여러 단체들이 표준 하드웨어에서 구동되는 클라우드 컴퓨팅 서비스들의 제공을 돕기 위해 고안되었다. 초기 코드는 NASA의 네뷸라 플랫폼 및 랙스페이스 클라우드 파일 플랫폼에서 기인한다. 2011년 3월 1일 IBM은 스마터 플래닛을 지원하기 위해 IBM 스마트클라우드 프레임워크를 발표하였다. 스마트 컴퓨팅 파운데이션의 여러 구성 요소들 가운데 클라우드 컴퓨팅은 지극히 중요한 부분이다. 2012년 6월 7일 오라클은 오라클 클라우드를 발표하였다. 오라클 클라우드의 여러 측면들이 현재 개발 중이지만, 이 클라우드는 사용자들에게 응용 프로그램(SaaS), 플랫폼(PaaS), 인프라스트럭처(IaaS) 계층을 포함하여 통합된 IT 솔루션 집합에 최초로 접근할 수 있도록 태세를 갖추고 있다.
개념

클라우드 컴퓨팅의 개념은 1965년 미국의 컴퓨터 학자인 존 매카시가 "컴퓨팅 환경은 공공 시설을 쓰는 것과도 같을 것"이라는 개념을 제시한데에서 유래하였다. 1993년부터는 이미 클라우드라는 용어가 거대한 규모의 ATM을 지칭하는 데 쓰였다. General Magic라는 회사는 1995년 3월부터 AT&T와 다른 여러 통신사들과 제휴를 맺고 클라우드 컴퓨팅 서비스를 최초로 시작했다. 하지만 이 시기는 소비자 중심의 웹 기반이 형성되기 전의 일이었기 때문에 클라우드 컴퓨팅 사업은 당연히 실패했다. 그러나 10년이 지난 2005년에서야 클라우드 컴퓨팅이라는 단어가 널리 퍼지기 시작했다. 하지만 2005년 당시 클라우드 컴퓨팅의 대부분의 내용들은 SaaS에 집중되어 있었다. 2007년까지는 SaaS에 집중되어 있었지만 2008년부터는 더 이상 SaaS에만 집중되어 있지 않으며, IaaS, PaaS로 그 영역을 넓혀가게 되었다.
개념 > 비슷한 개념

클라우드 컴퓨팅은 기존 기술들과 패러다임들의 발전 및 채택의 결과물이다. 클라우드 컴퓨팅의 목표는 사용자들이 각각의 기술에 대한 전문 지식이나 심도 있는 지식 없이도 이러한 기술들을 이용할 수 있도록 하는 것이다. 클라우드는 비용 절감을 목적으로 하며, IT 방해물들에 의해 지연되는 일 없이 핵심 사업에 집중할 수 있도록 도움을 준다.  클라우드 컴퓨팅의 주된 기술은 가상화이다. 가상화 소프트웨어는 물리적인 컴퓨팅 장치를 하나 이상의 가상 장치로 분리시키는 것으로, 컴퓨팅 작업들을 수행하기 위해 각 장치들을 쉽게 사용, 관리할 수 있다. 여러 독립적인 컴퓨팅 장치들의 규모 제어가 가능한 시스템을 만드는데 필수적인 운영 체제 수준 가상화와 함께 유휴 컴퓨팅 리소스들을 더 효율적으로 할당, 사용할 수 있다. 가상화는 IT 운영 속도를 높이는데 필요한 민첩성을 제공하며 인프라스트럭처 활용을 증가시킴으로써 비용을 줄여준다. 자율 컴퓨팅은 프로세스를 자동화하며, 이를 통해 사용자는 리소스 온 디맨드를 준비할 수 있다. 사용자가 수반되는 일을 최소화함으로써 자동화는 프로세스의 속도를 높이며 노동 비용을 낮추고 사람의 실수 가능성을 줄여준다. 사용자들은 어려운 비즈니스 문제들을 일상적으로 마주친다. 클라우드 컴퓨팅은 서비스 지향 아키텍처(SOA)의 개념을 채택하고 있으며 사용자가 이러한 문제들을 여러 서비스들로 분리시켜 이들을 하나의 솔루션으로 제공하기 위해 통합할 수 있도록 도움을 줄 수 있다. 클라우드 컴퓨팅은 모든 리소스들을 서비스로 제공하며 잘 정립된 표준과 SOA 분야에서 얻은 관행을 이용함으로써 표준화된 방법으로 클라우드 서비스에 대한 전역적이면서도 쉬운 접근을 할 수 있게 한다.
클라우드 컴퓨팅은 또한 유틸리티 컴퓨팅의 개념을 활용하여, 사용 중인 서비스들의 메트릭을 제공한다. 이러한 메트릭들은 공개형 클라우드 종량제 모델의 핵심에 위치해 있다. 또한, 측정된 장치들은 자율 컴퓨팅의 피드백 루프(feedback loop)의 필수적인 부분이며, 이를 통해 요청을 받으면 서비스들이 규모를 바꿀 수 있고 자동 재해 복구를 수행할 수 있게 한다. 클라우드 컴퓨팅은 일종의 그리드 컴퓨팅인데, QoS(서비스 품질), 신뢰성 문제로 인해 전개되었다. 클라우드 컴퓨팅은 데이터/연산 집약의 병렬 애플리케이션들을 빌드하기 위한 도구들과 기술들을 전통적인 병렬 컴퓨팅 기술 대비 훨씬 더 합당한 가격에 제공한다.
클라우드 컴퓨팅은 다음과 같은 특징을 공유한다:
클라이언트 서버 모델 - 클라이언트-서버 컴퓨팅은 크게는 서비스 제공자(서버)와 서비스 요청자(클라이언트)를 구별하는 모든 분산 애플리케이션을 가리킨다.
컴퓨터 뷰로(Computer bureau) - 특히 1960년대부터 1980년대까지 컴퓨터 서비스를 제공한 서비스 뷰로
그리드 컴퓨팅 - 분산 및 병렬 컴퓨팅의 한 형태. 슈퍼 및 가상 컴퓨터는 매우 큰 작업을 수행한다는 개념에서 네트워크화된 소결합(loose coupled)된 컴퓨터들의 클러스터로 이루어진다.
포그 컴퓨팅 - 클라이언트나 네트워크 라우터 등의 주변 종단 장치에 더 가까운, 데이터, 연산, 스토리지, 애플리케이션 서비스를 제공하는 분산 컴퓨팅 패러다임이다. 또, 포그 컴퓨팅은 처리를 위해 데이터를 원격 지점으로 보내는 대신 스마트 장치와 최종 사용자 클라이언트 사이드의 네트워크 레벨에서 데이터를 관리한다.
듀 컴퓨팅 - 기존의 컴퓨팅 계층에서 듀 컴퓨팅(dew computing)은 클라우드와 포그 컴퓨팅 패러다임의 하단에 위치한다.
메인프레임 컴퓨터 - 인구조사와 같은 일반적으로 대량 데이터 처리 및 소비자 통계, 치안/기밀 정보 서비스, 전사적 자원 관리, 금융 트랜잭션 처리와 같은 중대한 애플리케이션들을 위해 대형 단체들이 주로 사용하는 강력한 컴퓨터.
유틸리티 컴퓨팅 - 전기와 같은 전통적인 공과금과 비슷한 측정 방식으로 연산 및 스토리지와 같은 연산 자원의 묶음.
P2P - 중앙 조정이 필요 없는 분산 아키텍처이다. 자원의 공급자와 소비자가 둘 다 참여자이다. (전통적인 클라이언트-서버 모델과 달리)
그린 컴퓨팅
클라우드 샌드박스 - 프로그램, 코드, 또는 파일이 환경 내의 응용 프로그램에 영향을 주지 않고 실행할 수 있는, 분리된 컴퓨터 환경
특징

클라우드 컴퓨팅의 정의는 개인이 가진 단말기를 통해서는 주로 입/출력 작업만 이루어지고, 정보분석 및 처리, 저장, 관리, 유통 등의 작업은 클라우드라고 불리는 제3의 공간에서 이루어지는 컴퓨팅 시스템 형태라고 할 수 있다.
클라우드 컴퓨팅은 다음의 주요 특징들을 보여준다:
단체들을 위한 민첩성이 개선될 수 있는데, 클라우드 컴퓨팅은 기술 인프라스트럭처 자원들의 재보충, 추가, 확장에 대한 사용자의 유연성을 제고시킬 수 있다.
클라우드 제공자들은 비용 절감을 주장한다. 공개형-클라우드 배급 모델은 CAPEX(서버 구매 등)를 영업 비용으로 전환한다. 인프라스트럭처가 일반적으로 서드파티에 의해 제공되고 한 차례 정도 또는 드물게 수행되는 막대한 연산 작업을 위한 구매가 불필요해짐에 따라 시장 진입 장벽을 낮춘다. 유틸리티 컴퓨팅 기반의 가격 책정은 사용 기반 과금 옵션별로 세부적이다. 또한, 클라우드 컴퓨팅을 사용하는 프로젝트 구현에 조직 내부 IT 실력이 거의 필요하지 않다. e-FISCAL 프로젝트의 최신 저장소는 더 자세한 비용 관점을 조사하는 여러 문서들이 포함되어 있으며, 이들 중 대부분이 비용 절감은 지원되는 활동의 종류 및 조직 내에 이용할 수 있는 인프라스트럭처의 종류에 따라 달라진다고 결론을 내리고 있다.
장치 및 위치 독립성은 장치의 위치가 어디에 있는지, 무슨 장치(PC, 휴대전화)를 사용하는지에 관계 없이 사용자들이 웹 브라우저를 통해 시스템에 접근할 수 있게 한다. 인프라스트럭처가 부지 밖에 있고(보통 서드파티에 의해 제공됨) 인터넷을 통해 접근할 경우 사용자들은 어느 위치에 있어도 접속이 가능하다.
클라우드 컴퓨팅 애플리케이션의 유지보수는 더 쉽다. 각 사용자의 컴퓨터에 애플리케이션을 설치할 필요가 없고 다른 위치에서 접근이 가능하다. (다른 업무 장소, 여행 중 등)
멀티테넌시 는 많은 사용자들을 통해 자원과 비용을 공유할 수 있게 하며, 이에 따라 다음을 허용한다:
낮은 비용으로 여러 위치에서의 인프라스트럭처의 중앙 집중화 (부동산, 전기와 같은)
피크 부하 용량(peak-load capacity)의 증가 (사용자는 엔지니어가 필요 없으며 가능한 최고의 부하 수준을 충족하기 위해 리소스 및 장비에 대한 비용을 청구한다)
종종 10~20%만 활용하여 시스템의 활용 및 효율성 개선
서비스 제공자의 IT 전문가들은 성능을 감시하며 시스템 인터페이스로서 웹 서비스를 사용하여 소결합(loosely coupled)된 일정한 아키텍처들이 구성된다.
여러 사용자가 저장 및 이메일을 대기하지 않고 동일한 데이터를 동시에 작업할 수 있을 때 생산성이 향상될 수 있다. 필드가 일치할 때 정보를 다시 입력할 필요가 없으므로 시간을 절약할 수 있으며, 자신의 컴퓨터에 응용 소프트웨어 업그레이드를 설치할 필요 또한 없다.
여러 개의 과다한 사이트들을 이용할 때 신뢰성이 제고되며, 잘 설계된 클라우드 컴퓨팅을 사업 연속성, 재해 복구에 적합하도록 만들어준다.
거의 실시간에 가깝게 세밀하게 조정되는 셀프 서비스 기반의 동적(주문형) 자원 프로비저닝을 통한 확장성 및 탄력성. (참고로 VM 시작 시간은 VM의 종류, 위치, 운영 체제, 클라우드 제공자에 따라 다양함) 사용자는 피크 부하에 대해 특별한 조작을 할 필요가 없다. 사용률의 증가가 필요할 때 확장하고, 자원이 사용되지 않을 때 축소시키는 기능을 제공한다.
데이터 집중화, 강화된 보안 집중 자원들 등으로 인해 보안을 개선할 수 있지만, 민감한 특정 데이터에 대한 통제권을 손실할 우려 및 저장된 커널의 보안 취약이 있을 수 있다. 보안은 다른 전통적인 시스템만큼, 또는 그보다 더 낫기도 한데, 부분적인 이유로는 서비스 제공자들이 많은 고객들이 씨름할 수 없거나 해결을 위한 기술적인 기교가 부족한 보안 문제 해결에 자원들을 집중시킬 수 있기 때문이다. 그러나 데이터가 관련되지 않은 사용자들에 의해 공유되는 멀티테넌트 시스템뿐 아니라 수많은 장치를 통해 또는 더 넓은 지역을 통해 분산될 경우 보안의 복잡성이 크게 증가한다. 게다가 보안 감사 로그에 대한 사용자 접근이 어려울 수 있거나 아예 불가능할 수도 있다. 폐쇄형 클라우드 설치는 부분적으로는 인프라스트럭처의 통제권을 보유하고 싶으면서 정보 보안의 통제를 상실하기 싫어하는 사용자의 요구에 의해 동기가 부여된다.
특징 > 모식도

컴퓨터 네트워크 구성도에서 인터넷을 구름으로 표현한다. 이때 구름은 숨겨진 복잡한 인프라 구조를 의미한다. 사용자는 이러한 복잡한 인프라 구조를 알지 못해도 클라우드 컴퓨팅을 이용할 수 있다. 이용자들의 입장에서 제공자의 서비스들을 표현하는 네트워크 요소들은 마치 구름에 가려진 것처럼 눈에 보이지 않는다.
서비스 모델

서비스 지향 아키텍처가 "모든 것을 서비스로"(everything as a service, EaaS, XaaS, aas)를 지지하지만 클라우드 컴퓨팅 제공자들은 각기 다른 모델에 따라 자신들의 서비스들을 제공하며, 이 모델의 세 가지 NIST 표준 모델은 서비스형 인프라스트럭처(IaaS), 서비스형 플랫폼(PaaS), 서비스형 소프트웨어(SaaS)가 있다. 이 모델들은 추상화를 증가시킨다. 이러한 연유로 이들은 종종 스택 내의 계층으로 묘사되지만(인프라스트럭처-, 플랫폼-, 서비스형 소프트웨어) 이들은 서로 관련될 필요는 없다. 이를테면 기반이 되는 PaaS나 IaaS 계층을 사용하지 않고 SaaS를 물리 머신(베어 메탈)에 구현할 수 있으며, 역으로 IaaS에서 프로그램을 실행하여 이것을 SaaS로 래핑(wrapping)하지 않고 직접 접근할 수 있다.
서비스 모델 > 서비스형 인프라스트럭처 (IaaS)

이 부분의 본문은 서비스형 인프라스트럭처입니다.
국제 인터넷 표준화 기구(IETF)에 따르면 가장 기본적인 클라우드 서비스 모델은 컴퓨팅 인프라스트럭처, 즉 가상 머신과 기타 자원들을 구독자에 대한 서비스로 제공하는 제공자들의 모델이다. IaaS는 물리적 컴퓨팅 자원, 위치, 데이터 파티셔닝, 확장, 보안, 백업과 같은 인프라스트럭처의 세세한 부분으로부터 사용자를 이끌어내는 온라인 서비스들을 가리킨다.
젠, 버추얼박스, 오라클 VM, KVM, VM웨어 ESX/ESXi, 하이퍼-V와 같은 하이퍼바이저는 게스트로 가상 머신을 실행한다. 클라우드 운영 체제 내의 하이퍼바이저 풀들은 많은 수의 가상 머신들 및 고객의 다양한 요구에 맞는 서비스의 확장/축소 기능을 지원할 수 있다. 리눅스 컨테이너들은 물리 하드웨어 상에서 직접 구동되는 단일 리눅스 커널의 격리된 파티션에서 실행된다. 리눅스 cgroups와 이름공간들은 컨테이너의 격리, 보안, 관리에 사용되는 기반 리눅스 커널 기술들이다. 컨테이너화는 가상화 보다 더 높은 성능을 제공하는데, 그 이유는 하이퍼바이저 부하가 없기 때문이다. 또, 컨테이너 용량은 컴퓨터 부하와 함께 동적으로 규모를 조절하므로 과도한 공급 문제를 해결하고 사용률 기반의 과금을 가능케 한다. IaaS 클라우드는 가상 머신 디스크 이미지 라이브러리, 로우(raw) 블록 스토리지, 파일 또는 오브젝트 스토리지, 방화벽, 로드 밸런서, IP 주소, 가상 근거리 통신망, 소프트웨어 번들과 같은 추가적인 자원들을 종종 제공한다.
IaaS 클라우드 제공자들은 요청이 오면 이러한 자원을 데이터 센터에 설치된 수많은 장비를 통해 제공해준다. 광역 연결의 경우 고객들은 인터넷이나 캐리어 클라우드(전용 가상 근거리 통신망) 중 하나를 사용할 수 있다. 응용 프로그램을 배치시키기 위해 클라우드 사용자들은 운영 체제 이미지와 자신들의 응용 소프트웨어를 클라우드 인프라스트럭처에 설치한다. 이 모델에서 클라우드 사용자는 운영 체제와 응용 소프트웨어의 패치 및 유지보수를 수행한다. 클라우드 제공자들은 일반적으로 IaaS 서비스를 유틸리티 컴퓨팅 기반으로 과금한다: 비용은 할당 및 소비된 자원의 양을 반영한다.
AWS에서 제공하는 EC2가 대표적인 예이다. 이는 단순히 서버 등의 자원을 제공해 주면서 사용자가 디바이스에 제약없이 데이터에 접근할 수 있도록 해준다.
서비스 모델 > 서비스형 플랫폼 (PaaS)

이 부분의 본문은 서비스형 플랫폼입니다.
PaaS 벤더들은 응용 프로그램 개발자들에게 개발 환경을 제공한다. 제공자는 일반적으로 개발을 위한 툴킷과 표준, 그리고 배포 및 지불을 위한 채널을 개발한다. PaaS 모델에서 클라우드 제공자들은 일반적으로 운영 체제, 프로그래밍 언어 실행 환경, 데이터베이스, 웹 서버를 포함한 컴퓨팅 플랫폼을 배급한다. 응용 프로그램 개발자들은 기반 하드웨어 및 소프트웨어 계층을 구매하고 관리하는 비용이나 복잡성 없이도 자신들의 소프트웨어 솔루션을 클라우드 플랫폼에서 개발, 실행할 수 있다. 마이크로소프트 애저, 구글 앱 엔진과 같은 일부 PaaS에서 기반이 되는 컴퓨터, 스토리지 자원은 응용 프로그램 수요에 맞추기 위해 자동으로 규모를 조정하며 이로써 클라우드 사용자는 자원을 수동으로 할당하지 않아도 된다. 후자는 또한 클라우드 환경에서 실시간으로 편의를 도모하는 것을 목적으로 하는 아키텍처에 의해 제안되고 있다. 훨씬 더 세세한 응용 프로그램 종류가 PaaS를 통해 제공될 수 있는데, 이를테면 bitcodin.com이나 media.io에서 제공하는 미디어 인코딩을 예로 들 수 있다.
일부 연동 및 데이터 관리 제공자들은 데이터 솔루션을 위한 배급 모델로서 PaaS의 특수한 애플리케이션들을 받아들였다. 그 예로 iPaaS(서비스형 연동 플랫폼: Integration Platform as a Service), dPaaS(서비스형 데이터 플랫폼: Data Platform as a Service)이 있다. iPaaS는 고객들이 연동 플로를 개발, 실행, 관리할 수 있게 한다. iPaaS 연동 모델에서 고객들은 하드웨어나 미들웨어를 설치하거나 관리하지 않고 통합에 대한 개발 및 배치를 추진할 수 있다. dPaaS는 완전 관리가 가능한 서비스로서 통합 및 데이터 관리 제품을 배급한다. dPaaS 모델에서 고객이 아닌 PaaS 제공자는 고객에게 맞추어진 데이터 애플리케이션들을 빌드함으로써 데이터 솔루션의 개발 및 실행을 관리한다. dPaaS 사용자들은 데이터 시각화 도구를 통해 데이터에 대한 투명성 및 통제권을 획득한다. PaaS의 소비자들은 네트워크, 서버, 운영 체제, 스토리지를 포함한 기반 클라우드 인프라스트럭처를 관리하거나 통제하지 않지만 배치된 응용 프로그램이라든지, 응용 프로그램 호스팅 환경을 위한 구성 설정을 제어할 수 있다.
최근의 전문화된 PaaS로 BaaS(서비스형 블록체인)이 있으며, 마이크로소프트 애저와 같은 일부 벤더들은 이미 자신들의 PaaS에 포함시켜 놓고 있다.
사용자(개발자)가 소프트웨어 개발을 할 수 있는 환경을 제공해 주는 PaaS의 예로, 구글의 APP 엔진, Heroku 등이 대표적인 예다.
서비스 모델 > 서비스형 소프트웨어 (SaaS)

이 부분의 본문은 서비스형 소프트웨어입니다.
SaaS 모델에서 사용자들은 응용 소프트웨어와 데이터베이스에 대한 접근 권한을 가진다. 클라우드 제공자들은 응용 프로그램을 실행하는 인프라스트럭처와 플랫폼을 관리한다. SaaS는 "주문형 소프트웨어"(on-demand software)를 가리키기도 하며 가격 정책은 일반적으로 종량제(pay-per-use) 기반이거나 구독 비용 기반이다. SaaS 모델에서 클라우드 제공자들은 클라우드에 응용 소프트웨어를 설치, 운영하며 클라우드 사용자들은 클라우드 클라이언트의 소프트웨어를 접근한다. 클라우드 사용자들은 이러한 응용 프로그램들이 실행하는 클라우드 인프라스트럭처와 플랫폼을 관리하지 않는다. 이로 말미암아 클라우드 사용자 자신의 컴퓨터에 응용 프로그램을 설치하고 실행할 필요가 없으므로 유지보수와 지원이 단순하게 된다.
클라우드 응용 프로그램들은 확장성 관점에서 다른 응용 프로그램들과 차이가 있는데, 확장성은 변화하는 작업 수요를 충족하기 위해 런타임 중에 태스크들을 여러 개의 가상 머신으로 복제함으로써 수행할 수 있다. 로드 밸런서들은 가상 머신들의 집합을 통해 작업을 분산시킨다. 이 과정은 오직 하나의 단일 액세스 포인트를 바라보는 클라우드 사용자에게는 투명하게 보인다. 수많은 클라우드 사용자들을 수용하기 위해 클라우드 애플리케이션들은 멀티테넌트일 수 있으며, 즉 어떠한 머신이라도 하나 이상의 클라우드 사용자 조직에 서비스를 제공할 수 있다는 것을 뜻한다.
SaaS 애플리케이션의 가격 정책 모델은 사용자 당 월별, 연별 고정 수수료인 것이 보통이므로 특정 지점에서 사용자가 추가되거나 제거되면 가격은 조정될 수 있다. 지지자들은 SaaS가 하드웨어 및 소프트웨어 유지보수 및 지원을 클라우드 제공자에게 위탁함으로써 비즈니스에 드는 IT 운영 비용을 줄일 가능성을 제공한다고 주장한다. 즉, 다른 목표를 충족하기 위해 비즈니스가 하드웨어/소프트웨어 및 인력에 드는 IT 운용 비용을 재할당할 수 있게 한다. 게다가 중앙 관리되는 애플리케이션들을 통해 사용자가 새로운 소프트웨어를 설치하지 않고도 업데이트를 출시할 수 있다. SaaS의 단점은 사용자 데이터를 클라우드 제공자의 서버에 저장하는 점에서 비롯된다. 그 결과 데이터에 대해 인증되지 않은 접근이 있을 가능성이 있다. 이러한 이유로 사용자들은 인텔리전트 서드파티 키 관리 시스템을 채택하여 자신들의 데이터의 보안을 지원한다.
SaaS의 경우, 네이버에서 제공하는 네이버 클라우드, 드롭박스, 구글 문서 등을 예로 들 수 있다.
서비스 모델 > 서비스형 백엔드 (BaaS)

이 부분의 본문은 서비스형 백엔드입니다.
서비스 (m) 모델형 모바일 백엔드로도 불리는 서비스형 백엔드(backend as a service, BaaS)에서 웹 앱과 모바일 앱 개발자들은 자신들의 애플리케이션들을 자신의 애플리케이션과 커스텀 SDK에 노출되는 API를 갖춘 클라우드 컴퓨팅 서비스와 클라우드 스토리지를 연결하는 방법을 제공받는다. 서비스에는 사용자 관리, 푸시 알림, 소셜 네트워킹 서비스와의 연동 등을 포함한다. 이것은 클라우드 컴퓨팅에서 상대적으로 최근에 나온 모델이며, 대부분의 BaaS 스타트업 컴퍼니는 2011년 이후부터 모습을 드러내기 시작했지만 이러한 서비스들이 기업 소비자들에게 상당한 주류 견인력을 얻고 있는 추세이다.
서비스 모델 > 서버리스 컴퓨팅

이 부분의 본문은 서버리스 컴퓨팅입니다.
서버리스 컴퓨팅은 클라우드 컴퓨팅 코드 실행 모델의 하나로, 클라우드 제공자가 서비스 요청의 필요에 따라 가상 머신을 시작하고 중단하는 일을 온전히 관리하며 시간 당, 가상 머신 당 개념이 아닌 요청 충족에 필요한 자원의 추상적인 측정에 의해 과금된다. "서버리스 컴퓨팅"이라는 이름에도 불구하고 실제로 서버 없는 코드의 실행은 수반되지 않는다. 서버리스 컴퓨팅이라는 이름이 붙여진 이유는 시스템을 소유하는 사업체나 사람이 백엔드 코드를 실행하기 위해 서버나 가상 머신을 구매, 임대, 예비할 필요가 없기 때문이다.
클라우드 클라이언트

사용자들은 데스크톱 컴퓨터, 랩톱, 태블릿, 스마트폰 및 홈 오토메이션 가젯 등의 이더넷 장치와 같은 네트워크화된 클라이언트 장치들을 이용하여 클라우드 컴퓨팅에 접근한다. 클라우드 클라이언트라는 장치들 가운데 일부는 자신들의 응용 프로그램의 전부 또는 대부분을 위해 클라우드 컴퓨팅에 의존하는데 이것이 필수불가결이기 때문이다. 신 클라이언트와 브라우저 기반 크롬북이 그 예이다. 수많은 클라우드 애플리케이션들은 클라이언트에 특정 소프트웨어를 요구하지 않으며 그 대신 웹 브라우저를 사용하여 클라우드 애플리케이션과 상호 작용한다. Ajax와 HTML5를 사용하여 이 웹 사용자 인터페이스들은 네이티브 애플리케이션에 견주어 비슷하거나 훨씬 더 좋은 룩 앤드 필을 달성할 수 있다. 그러나 일부 클라우드 애플리케이션들은 이러한 애플리케이션들을 전문으로 하는 특정 클라이언트 소프트웨어를 지원한다. (예: 가상 데스크톱 클라이언트 및 대부분의 이메일 클라이언트) 일부 레거시 애플리케이션들(현재까지 신 클라이언트 컴퓨팅에 일반화된 일련의 비즈니스 애플리케이션)은 화면 공유 기술을 통해 배포된다.
배치 모델 > 폐쇄형 클라우드

폐쇄형 클라우드(private cloud, 프라이빗 클라우드)는 오직 하나의 단체를 위해서만 운영되는 클라우드 인프라스트럭처의 하나로, 내부적으로나 서드파티에 의해 관리를 받거나 내외부적으로 호스팅된다. 폐쇄형 클라우드 프로젝트를 떠맡을 경우 어느 정도 수준의 비즈니스 환경 가상화가 수반될 필요가 있으며 단체가 기존 자원에 대한 결정사항들을 재평가할 필요가 있다. 잘 마쳤을 때 비즈니스를 개선할 수 있지만 프로젝트의 모든 단계가 심각한 취약점 예방을 해야 하는 보안 문제를 일으킨다. 자체 운영 데이터 센터들은 일반적으로 자본 집약적이다. 공간, 하드웨어, 환경 제어의 할당이 필요한 중대한 물리적 발자취가 있다. 이러한 자산들은 주기적으로 갱신되어야 하며, 그 결과 추가적인 자본 비용이 소요된다. 사용자들이 여전히 이것들을 구매, 빌드, 관리해야 하므로 직접 챙겨야 하는 관리가 덜하다는 데에서부터 이점을 얻는 것이 아니기 때문에 비평을 받았다. (특히 클라우드 컴퓨팅을 매력적인 개념으로 만드는 환경 모델이 부족하여)
배치 모델 > 공개형 클라우드

공개형 클라우드(public cloud, 퍼블릭 클라우드)는 공개적 이용을 위해 열린 네트워크를 통해 렌더링되는 클라우드이다. 공개형 클라우드 서비스들은 무료일 수 있다. 기술적으로 공개형과 폐쇄형 클라우드 아키텍처 간 차이가 거의 없거나 아예 없을 수 있으나, 통신이 신뢰되지 않은 네트워크 상에서 영향을 받으면서 대중을 위해 서비스 제공자에 의해 이용 가능하게 된 서비스들마다 보안적으로 고려할 사항이 본질적으로 다를 수 있다. 일반적으로, 네이버클라우드플랫폼, 아마존 웹 서비스(AWS), 마이크로소프트, 구글과 같은 공개형 클라우드 서비스 제공자들은 자신들의 데이터 센터를 소유, 운영하고 있으며 접근은 일반적으로 인터넷을 통한다. AWS와 마이크로소프트는 각각 "AWS Direct Connect"와 "Azure ExpressRoute"라는 직접 연결 서비스들을 제공하며, 이러한 연결은 클라우드 제공자가 제공하는 피어링 포인트에 대한 폐쇄형 연결의 구매나 임대를 고객에게 요구한다.
배치 모델 > 혼합형 클라우드

혼합형 클라우드(hybrid cloud, 하이브리드 클라우드)는 뚜렷한 실체는 유지하지만 함께 묶여있는 둘 이상의 클라우드(폐쇄형, 커뮤니티, 또는 공개형)의 조합으로, 여러 개의 배치 모델들의 이점을 제공한다. 혼합형 클라우드는 병설(collocation), 매니지드 및 데디케이티드 서비스를 클라우드 자원과 연결하는 기능을 의미할 수도 있다. 가트너는 혼합형 클라우드를 다른 서비스 제공자들로부터 제공되는 폐쇄형, 공개형, 커뮤니티 클라우드 서비스들이 어느 정도 복합된 하나의 클라우드 컴퓨팅 서비스로 정의한다. 혼합형 클라우드 서비스는 격리 부분과 제공자 간 경계를 교차하므로 단순히 폐쇄형, 공개형, 커뮤니티 클라우드 서비스 중 하나의 분류에 집어넣을 수 없다. 다른 클라우드 서비스와의 애그리게이션, 연동, 커스터마이즈를 통해 클라우드 서비스의 용적의 확장을 허용한다
배치 모델 > 기타 > 커뮤니티 클라우드

커뮤니티 클라우드는 공통 관심사(보안, 법 준수, 관할권 등)를 가진 특정 커뮤니티의 여러 조직들 간에 인프라스트럭처를 공유하며, 내부적으로 또는 서드파티에 의해 관리되거나
내외부적으로 호스팅된다. 공개형 클라우드 보다 더 적은 (그러나 폐쇄형 클라우드 보다는 더 많은) 수의 사용자들에게 비용이 전가되므로 클라우드 컴퓨팅에 잠재적인 비용 절감 중 일부분만 실현된다.
배치 모델 > 기타 > 분산형 클라우드

클라우드 컴퓨팅 플랫폼은 각기 다른 위치의 분산된 집합의 머신들로부터 조합되어 하나의 네트워크나 허브 서비스로 연결된다. 두 종류의 분산형 클라우드로 구별이 가능하다: 퍼블릭 리소스 컴퓨팅, 볼런티어 클라우드.
퍼블릭 리소스 컴퓨팅(public-resource computing): 이 종류의 분산형 클라우드는 광활한 정의의 클라우드 컴퓨팅에서 비롯되는데, 그 이유는 이것이 클라우드 컴퓨팅 보다는 분산형 컴퓨팅에 더 유사점이 있기 때문이다. 그럼에도 불구하고 클라우드 컴퓨팅의 부분 집합으로 간주되며 BOINC과 Folding@Home과 같은 분산형 컴퓨팅 플랫폼과 같은 예를 일부 들 수 있다.
볼런티어 클라우드(volunteer cloud): 볼런티어 클라우드 컴퓨팅은 퍼블릭 리소스 컴퓨팅과 클라우드 컴퓨팅의 교차점의 특징을 지니며 여기에서 클라우드 컴퓨팅 인프라스트럭처는 볼런티어 리소스를 사용하여 만들어진다. 이러한 종류의 인프라스트럭처에는 수많은 도전에 직면하는데, 이것을 만드는데 사용되는 자원의 휘발성과 운영에 쓰이는 동적 환경 때문이다. P2P(peer-to-peer) 클라우드, 애드혹 클라우드라고도 부를 수 있다. 이러한 방향에 관심을 두고 진행 중인 것으로 Cloud@Home이 있으며, 기여에 대한 금전적 보상에 대한 비즈니스 모델을 제공하는 볼런티어 자원들을 사용하여 클라우드 컴퓨팅 인프라스트럭처를 구현하는 것이 목적이다.
배치 모델 > 기타 > 인터클라우드

이 부분의 본문은 인터클라우드입니다.
인터클라우드는 서로 연결된 글로벌 클라우드의 클라우드이며 기반이 되는 인터넷 네트워크의 네트워크에 대한 확장이다. 공개형 클라우드 서비스 제공자들 간의 직접적인 상호운용성에 초점을 맞추고 있으며, 이는 제공자들과 소비자들 간의 것 보다 더한 편이다. (마치 복합형 클라우드와 멀티클라우드의 사례와 같음)
배치 모델 > 기타 > 멀티클라우드

이 부분의 본문은 멀티클라우드입니다.
멀티클라우드는 단일 벤더에 대한 의존성을 줄이고 선택을 통한 유연성을 향상시키고 장애에 대한 불편을 줄이는 등을 하기 위해 하나의 이기종 아키텍처 안에서 여러 개의 클라우드 컴퓨팅 서비스의 이용을 뜻한다. 여러 개의 배치 모드(공개형, 폐쇄형, 레거시)가 아닌 여러 개의 클라우드 서비스를 가리킨다는 점에서 복합형 클라우드와는 차이가 있다.
아키텍처

클라우드 컴퓨팅 배포를 수반하는 소프트웨어 시스템의 시스템 아키텍처인 클라우드 아키텍처는 메시징 큐와 같은 소결합(loose coupling) 매커니즘 상에 서로 통신하는 보통 복수의 클라우드 구성 요소를 동반한다. 일래스틱 프로비전은 이러한 매커니즘들에 적용될 때 소결합이나 밀결합(tight coupling)을 사용하는 지능을 암시한다.
아키텍처 > 클라우드 엔지니어링

클라우드 엔지니어링은 클라우드 컴퓨팅에 대한 공학적 응용이다. 클라우드 컴퓨팅 시스템의 구상, 개발, 운영, 유지보수를 할 때 상용화, 표준화, 관리에 대해 표면적으로 걱정하는 부분들에 대한 체계적인 접근을 가져다준다. 시스템, 소프트웨어, 웹, 성능공학, 정보, 보안, 플랫폼, 위험, 품질 공학과 같은 다양한 분야의 기여를 아우르는 종합적인 방식이다.