Cloud computing offers higher reliability and lower up-front IT costs than traditional computing environments and is a great way to dynamically scale both resources and capabilities. For further efficiency and consistency, cloud computing tasks can also be automated with tools such as Ansible. In this thesis, we will analyze and compare the abilities of Ansible with the three leading cloud platforms, i.e. Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP). To evaluate this, we cover three different areas of automation with cloud platforms. These areas are performance, user complexity, and missing network functionalities. The performance was evaluated through experiments that revealed a big gap between the platforms, where AWS was the clear winner in all scenarios. Microsoft Azure was slightly faster than GCP when a low number of virtual machines were created but GCP scaled better than Azure when more virtual machines were created. The user complexity was evaluated on the setup process and the creation of playbooks where Azure was the clear winner in both areas. AWS and GCP had similar setup processes, but AWS takes second place through its superior documentation for the creation of playbooks. All three platforms had missing network functionalities, but the majority of the missing functionalities were not relevant as they were not related to deployment which is the main usage of an automation tool like Ansible. However, some deployment functions were missing, for example, the firewall function for AWS was missing in Ansible.

Serverless is a fascinating trend in modern software development which consists of pay-as-you-go, autoscaling services. Promised reduction in operational and development costs attracts not only startups but also enterprise clients despite that serverless is a relatively fresh field where new patterns and services continue to emerge. Serverless started as independent services which solve specific problems (highly scalable storage and computing), and now it's become a paradigm shift how systems are built. This thesis addressed questions when and how to start with serverless by reviewing available literature, conducting interviews with IT professionals, analyzing available tools, identifying limitations of serverless architecture and providing checklist when serverless is applicable. The focus was on AWS serverless stack, but main findings are generic and hold for all serverless providers serverless delivers what it promises, however, the devil is in the detail. Providers are continuously working to resolve limitations or building new services as solutions in order to make serverless the next phase of cloud evolution. / Serverless är en fascinerande trend inom nutida mjukvaruutveckling som består av pay-as-you-go, autoscaling-tjänster. Löftet om reducerade kostnader för drift och utveckling attraherar såväl startupföretag som storföretag, trots att serverless är ett relativt nytt område där nya inriktningar och tjänster fortsätter att uppkomma. Serverless började som en oberoende tjänst som löste specifika problem (högt skalbar lagring och databehandling), och har nu blivit ett paradigmskifte för hur system byggs. Denna uppsats sökte svar på frågor om när och hur man ska börja med serverless genom att granska tillgängliga publikationer, genomföra intervjuer med IT-experter, analysera tillgängliga verktyg och identifiera begränsningarna i serverless-arkitekturen. Fokus ligger på AWS serverless stack, men de huvudsakliga slutsatserna är generiska och gäller för alla serverless-leverantörer – serverless håller vad den lovar, men djävulen bor i detaljerna. Tjänsteleverantörerna jobbar oavbrutet med att lösa begränsningarna eller skapa nya tjänster och lösningar som ska göra serverless till nästa fas i molnevolutionen.

Creating visualizations for Internet of Things (IoT) data can be a challenge due to the uncertain and voluminous nature of this type of data. Many different tools have been made to visualize voluminous data. One such tool is Amazon Web Service (AWS) Quicksight. Quicksight is marketed as a scalable system for big data. For IoT developers, the visualization task is only a smaller subtask, which is often not the focus for the developer. Therefore it is in the developer’s best interest to use an easy tool for visualizing their data. To study if Quicksight is a viable tool for developers of IoT systems a user study was executed. Both the perceived usability and measured understanding when using the system were studied. This was done by using the System Usability Scale (SUS) for the perceived usability. For measured understanding some questions regarding trends and errors were asked and a statistical classification was made. The study showed a tendency for the users to rely too much on the visual structure Autograph as well as their difficulty to extract information from aggregated visualizations. In addition it was cumbersome to connect data between different datasets. / Att skapa visualiseringar för IoT data kan vara utmanande på Internet of Things (IoTs) oförutsägbara och voluminösa natur. Det finns många olika verktyg för att visualisera data. Ett sådant verktyg är Amazon Web Service (AWS) Quicksight. Quicksight marknadsförs som ett skalbart system för big data. För IoT utvecklare är dock visualisering oftast en mindre deluppgift som inte ligger i fokus. Därför är det viktigt för utvecklare att använda ett lättanvänt verktyg för att visualisera data. För att undersöka ifall Quicksight är ett bra alternativ som verktyg för utvecklare av IoT system så utfördes en användarstudie. Både den uppfattade och uppmätt förståelsen av systemet studerades. System Usability Scale (SUS) användes för att mäta den uppfattade användbarheten. För att mäta den uppmätta förståelsen ställdes frågor om trender och fel i data som sedan delades in i statistisk klassificering. Studien visade att användare tenderar att förlita sig för mycket på den visuella strukturen Autograph samt att dem hade svårigheter att utvinna information från aggregerad visualisering. Därtill ansåg användarna att det var besvärligt att koppla samman flera dataset i en visualisering.

Idag används vanligtvis lösenord som autentiseringsmetod i moderna applikationer. Men allt fler företag och applikationer övergår från denna metod och i stället använda krypterade nycklar och certifikat för att öka säkerheten. Dessutom har telefoner och datorer utvecklats som har hårdvarusäkerhetsmoduler för att lagra och skydda sådan information. Projektet utgick på att bekanta sig med olika kryptografiska standarder i en modern webbläsare, med fokus på WebAuthn. Därefter utvecklades och designades en Proof Of Concept-applikation i Amazon webservice som använde sig av WebAuthn för autentisering. Tilläggsfunktioner som möjliggör återanvändning av den privata nyckeln som genereras av WebAuthn implementerades och testades. Dessa tillägg inkluderar pseudo-random function (PRF) och large blob. Resultatet blev en fungerande webbapplikation i Amazon webservice som använder sig av WebAuthn-standarden där en användare har möjlighet att registrera samt autentisera sig med hjälp av biometriska metoder i stället för lösenord. Implementationen av tillägg för återanvändning av privata nycklar visade sig vare en utmaning. Tekniska svårigheter med webbläsare, protokoll och autentiseringsenheter, samt det faktum att WebAuthn-standarden är relativt ny, påverkade implementationen av tilläggen. Det kan vara värt att notera att med tiden kommer fler webbläsare och autentiseringsenheter troligtvis stödja dessa funktioner, vilket kan möjliggöra återanvändning av privata nycklar. Avslutningsvis visade projektet att det är möjligt att skapa en webbapplikation i Amazon webservice som använder sig av WebAuthN-standarden och möjliggör autentisering med biometriska metoder. Trots de tekniska utmaningarna med pseudo-random function (PRF) och large blob, är det en lovande riktning för framtida implementeringar när standarden mognar och stöd för tilläggsfunktionerna förbättras. / Today, passwords are commonly used as an authentication method in modern applications. However, more and more companies and applications are moving away from this method and instead using encrypted keys and certificates to increase security. Additionally, phones and computers have been developed that have hardware security modules to store and protect such information. The project was based on getting to know different cryptographic standards in a modern browser, with a focus on WebAuthn. Next, a Proof-of-Concept application was developed and designed in AWS that used WebAuthn for authentication. Additional features that allow reuse of the private key generated by WebAuthn were implemented and tested. These extensions include pseudo-random function (PRF) and large blob. The result was a functioning web application in AWS that uses the WebAuthn standard where a user can register and authenticate themselves using biometric methods instead of passwords. The implementation of private key reuse extensions proved to be a challenge. Technical difficulties with browsers, protocols, and authenticators, as well as the fact that the WebAuthnstandard is relatively new, affected the implementation of the extensions. It may be worth noting that over time, more browsers, and authentication devices will likely support these features, which may allow private key reuse. In conclusion, the project showed that it is possible to create a web application in AWS that uses the WebAuthn-standard and enables authentication with biometric methods. Despite the technical challenges with pseudo-random function (PRF) and large blob, it is a promising direction for future implementations as the standard matures and support for the extension functions improves.

Our internet makes data storage and sharing more convenient. An increasing amount of privacy data is being stored on different application platforms, so the security of these data has become a public concern. The European Council General Data Protection Regulation (GDPR) put forward clear requirements for application platforms to give back end- users data control, and the regulations came into force in May 2018. However, there is still a lack of low- cost, easy- to-manage user data control framework in the application platform, especially for startups. To address the problem, I apply Amazon Cognito to provide user account management and monitor. Therefore, I store the user information (e.g., username, email) registered on the web application in Cognito to achieve user authentication. I also associate the web application with Amazon Web Services (AWS) Application Programming Interface (API) Gateway to implement the data control operations on the web application to the AWS DynamoDB database. The final result proves that the framework can successfully implement data control operations on the end- user data under the requirements of GDPR. Meanwhile, all data operation results can be displayed in real- time on the web application and can be used in the corresponding AWS service to monitor. / Vårt internet gör datalagring och delning bekvämare. En ökande mängd känslig användardata lagras på olika applikationsplattformar, så säkerheten för dessa data har blivit en allmän angelägenhet. Europeiska rådets GDPR presenterade tydliga krav på att applikationsplattformar ska returnera slutanvändarnas datakontroller och de förordningar som trädde i kraft i maj 2018. Det saknas dock fortfarande ett billigt, lättanvänt hanteringsramverk för användarna samt datakontroll i applikationsplattformen, särskilt för startups. För att lösa problemet använder jag Amazon Cognito för att hantera och övervaka användarkonton. Därför lagrar jag användarinformationen (t.ex. användarnamn, epost) som är registrerad i webbapplikationen i Cognito för att uppnå användarautentisering. Jag associerar också webbapplikationen med AWS API Gateway för att implementera datakontrollåtgärderna på webbapplikationen till AWS DynamoDB- databasen. Det slutliga resultatet visar att ramverket framgångsrikt kan implementera datahanteringsoperationer på slutanvändardata i enlighet med kraven i GDPR. Under tiden kan alla datadriftresultat visas i realtid i webbapplikationen och kan därmed användas i motsvarande AWS- tjänst för att monitorera.

Arbetet bygger på förbättring av befintlig arkitektur för en tjänst som beräknar koldioxidutsläpp för molntjänster. Nuvarande arkitektur bygger på att samla ihop och klumpa stora mängder data i form av användarrapporter. Därefter körs frågor mot det data för att få ut relevant information. Detta kan ta väldigt lång tid. För att försöka påskynda denna process görs en undersökning om man kan minska tiden som går åt att köra frågor mot data om datamängden blir mindre. Detta uppnås genom att filtrera bort oönskad data ur mängden innan man kör frågor mot det. Vidare undersöks om den nya arkitekturen kan möjliggöra för enklare implementation av nya funktioner till tjänsten. Metoden för undersökningen var att bygga en alternativ arkitektur med hjälp av AWS och dess tjänster. Resultaten visar på att även om mängden data som skannas är nästan oförändrat så minskas körtiden avsevärt när den totala storleken på datamängden minskar. Vidare bidrar den nya arkitekturen till enklare implementation av nya tjänster än tidigare. / The current architecture the stakeholders are using consists of collecting large amounts of data. After the data is collected it is queried for relevant information. This query process can take a long time. This report looks at if it is possible to reduce this time by reducing the data size. This is done by filtering the data before doing queries towards it. Furthermore this report will investigate if the new architecture can make it easier to implement new functionality. To investigate these questions a new architecture will be built using AWS. The results show that even though scanning nearly the same amount of data, with the total data size reduced one can drastically reduce the query times. Furthermore this new architecture makes it easier to implement new functionality.

As technology becomes increasingly embedded in our daily lives, the demand for computational power is on the rise. Sometimes, the necessary calculations can be performed within the device itself, but often, they need to be processed remotely. This is where the role of cloud providers comes into play, steadily growing to meet the demand. With a multitude of providers available, each offering their own unique blend of services, costs, availability, and functionality, choosing the right one can be daunting. Each provider has its own advantages and drawbacks, making them more suitable for specific use scenarios. Growing businesses might find it challenging to select the best cloud provider due to the wide range of offerings. Decisions revolve around factors such as costs, scalability, and performance implications. This study examines a case where a transition was made from the cloud provider Heroku to Amazon Web Services (AWS) and their respective offerings. The moved infrastructure included a database, back-end service, and front-end service, with the last two operating as Docker-compiled containers. To investigate the differences, minor modifications were made to the existing infrastructure to make it compatible with AWS. Due to the similarities between the two systems, we could perform tests in 7 categories such as ”Time to first byte” and ”Time to interactive”. The data was derived using the performance monitoring software Google lighthouse. Non-app-specific data, like service availability and costs, were collected directly from the providers. The findings suggest that performance differences between Heroku and AWS were marginal. The cost data indicates Heroku as a pricier option at present. Despite AWS being cheaper it provides more features and customisation, it also offers a more advantageous cost model for future company growth and system expansion. If there was more time available for the study it would also be of interest to see how other providers compared to the two examined in the study. / I takt med att tekniken blir alltmer inbäddad i våra dagliga liv, ökar efterfrågan på beräkningskraft. Ibland kan de nödvändiga beräkningarna utföras inom enheten själv, men ofta behöver de bearbetas på distans. Det är här som rollen av molnleverantörer kommer in i bilden, stadigt växande för att möta efterfrågan. Med en mängd olika leverantörer tillgängliga, var och en erbjuder sin egen unika blandning av tjänster, kostnader, tillgänglighet och funktionalitet, kan det vara svårt att välja rätt. Varje leverantör har sina egna fördelar och nackdelar, vilket gör dem mer lämpliga för specifika användningsscenarier. Växande företag kan finna det utmanande att välja den bästa molnleverantören på grund av det breda utbudet av tjänster. Besluten kretsar kring faktorer som kostnader, skalbarhet och prestandaimplikationer. Denna studie undersöker ett fall där en övergång gjordes från molnleverantören Heroku till Amazon Web Services (AWS) och deras respektive erbjudanden. Den flyttade infrastrukturen inkluderade en databas, bakänd-tjänst och framänd-tjänst, med de två sistnämnda som fungerar som Docker-kompilerade behållare. För att undersöka skillnaderna gjordes mindre ändringar i den befintliga infrastrukturen för att göra den kompatibel med AWS. På grund av likheterna mellan de två systemen kunde vi utföra tester i 7 kategorier, såsom ”Time to first byte” och ”Time to interactive”. Data erhölls med hjälp av prestandaövervakningsprogramvaran Google Lighthouse. Icke-applikationsspecifika data, som tjänstens tillgänglighet och kostnader, samlades direkt från leverantörerna. Resultaten tyder på att prestandaskillnaderna mellan Heroku och AWS var marginella. Kostnadsdata indikerar att Heroku är ett dyrare alternativ för närvarande. Trots att AWS är billigare och erbjuder fler funktioner och anpassningar, erbjuder det också en mer fördelaktig kostnadsmodell för framtida företagstillväxt och systemutvidgning. Om det fanns mer tid för studien skulle det också vara intressant att se hur andra leverantörer jämförde sig med de två som undersöktes i studien.

Cloud computing is the concept of enabling access to computational resources from anywhere and from any device. Many companies are seeing the benefits of cloud computing and are migrating over to the cloud. However, migrating to the cloud raises customer-related security risks. To mitigate the risk of a data breaches companies need to learn how to defend against hackers and one of the tools that can increase knowledge surrounding cloud security is CloudGoat. CloudGoat gives the defender hands-on hacking experience by providing a handful of hacking challenges. The problem with CloudGoat is that the hacking challenges are all manually created. The hacking community is always evolving. Therefore, this report proposes GoatFarm, a tool to automatically assemble hacking challenges from predefined cloud resources. One of the scenarios presented in CloudGoat was picked as a starting point. The chosen hacking challenge was modified multiple times and when a hacking challenge with a achievable goal was created the modification was saved. Goatfarm managed to generate two new hacking challenges. The generated hacking challenges was manually verified by reaching the goal of the generated hacking challenge. Since the generated hacking challenges had an achievable goal, they can be used as a learning experience. However, this report only managed to generate two new hacking challenges. Further work could generate more hacking challenges to create a complete learning experience. The verification could also be more effective by using a tool to assess the generated hacking challenges automatically. / Molntjänster är ett koncept som möjliggör åtkomst till dataresurser från var som helst och från vilken enhet som helst. Många företag ser fördelarna med molntjänster och migrerar över till molnet. Att migrera till molnet innebär däremot kundrelaterade säkerhetsrisker. För att minska risken för dataintrång måste företag lära sig att försvara sig mot hackare och ett av verktygen som kan öka kunskapen kring molnsäkerhet är CloudGoat. CloudGoat ger försvararen en praktisk hackingupplevelse genom att tillhandahålla en handfull hackningsutmaningar. Problemet med CloudGoat är att alla hackningsutmaningar skapas manuellt. Hacking kunskapen utvecklas hela tiden. Därför föreslår denna rapport GoatFarm, ett verktyg för att automatiskt sammanställa hackningsutmaningar från fördefinierade molnresurser. Ett av scenarierna som presenteras i CloudGoat valdes som utgångspunkt. Den valda hackningsutmaningen modifierades flera gånger och när en hackningsutmaning med ett uppnåeligt mål skapades sparades modifieringen. Goatfarm lyckades generera två nya hackningsutmaningar. De genererade hackningsutmaningarna verifierades manuellt genom att nå målet med hackningsutmaningen. Eftersom de genererade hackningsutmaningarna har ett uppnåeligt mål kan de användas i lärande ändamål. Den här rapporten lyckades dock bara generera två nya hackningsutmaningar. Ytterligare arbete bör generera fler hackningsutmaningar för att skapa en komplett inlärningsupplevelse. Verifieringen kan också bli mer effektiv genom att använda ett verktyg för att automatiskt bedöma de genererade hackningsutmaningarna.

In this thesis, a new traction stress based method for characterizing shear strength is investigated by carrying out a series of shear strength tests. The AWS method for the calculation of shear strength shows significant discrepancies between longitudinal and transverse specimens. The main purpose of this new traction based definition for shear strength is to demonstrate that there exists a single shear strength value regardless of specimen geometry and loading conditions. With this new approach a better correlation between shear strength values for transverse and longitudinal specimens is achieved. Special issues occur with the multi-pass welds in regards to the failure angle. The AWS equation does not account to different failure angles of the specimens, it only assumes 45o failure angle in all the cases, but the new approach takes into account the different failure angles. Finally with this method a quantitative weld sizing can be achieved for fillet welds.

As the IoT has grown in popularity, modern Cloud Providers have begun offering IoT-specific features. These features could provide IoT developers with a lot of aid, but they are new and relatively unexplored. This study aims to explore these IoT-specific features in order to build a better foundation for developers looking to leverage them to improve their IoT systems or development process. To do this, a literature study combined with a case study was carried out. The literature study gives insight into the current research around IoT and IoT cloud providers, for example with common issues and possible applications. The case study provides a reference of how a simple proof-of-concept system can be developed using two of the available providers: AWS IoT and Azure IoT.