GENI Laboratory Exercises Development for aCloud Computing Course

Prasad Calyam, Sripriya Seetharam, Ronny Bazan AntequeraUniversity of Missouri-Columbia

{calyamp, ssn68, rcb553}@missouri.edu

Abstract—Cloud computing education involves integration ofcomputing theories and information technologies in new andinteresting ways. It can enable students to architect scalable-infrastructures and develop web-service based applications uti-lizing distributed systems. In this paper, we describe our efforts,experiences and findings in the development of laboratory ex-ercises that utilize GENI infrastructure in a cloud computingcourse offered at University of Missouri in Fall 2013. Threesets of laboratory exercises were developed and administered for30 undergraduate/graduate students to help them gain skills incomputer and network virtualization, and also to prepare themfor distributed system programming projects. We found thatthe GENI infrastructure provides unique capabilities for studenttraining, and combining it with lab exercises that use publicclouds such as Amazon Web Services can provide an overallrich set of hands-on learning opportunities.

I. INTRODUCTION

Cloud computing in a short period of time has already trans-formed how we build and utilize compute and network infras-tructures. The compute and network resources are becomingcommon utilities such as electricity and water, and are fos-tering new market ecosystems that provide cost effective andhigh-quality service choices to both residential and businessconsumers [1]. The classic computing ‘Buy and Own’ modelwith long procurement cycles is being replaced by ‘Subscribeand Use’ models with pay-as-you-go pricing in public cloudssuch as Amazon Web Services (AWS) [2]. Public clouds allowon-demand user access to abundant resources in an elasticmanner, and enterprises no longer need to rely on expensiveguesswork in procurement of hardware/software to meet peakuser needs. Consequently, new training and job opportunitieshave emerged, and cloud computing education is becoming ahighly attractive component of curriculum for students seekingindustry jobs or challenging PhD research topics.

To augment traditional Computer Science/Engineering cur-riculum and keep it relevant for students interested in cloudcomputing, integration of computing theories and informationtechnologies needs to be taught in new and interesting ways.Particularly, “hands-on experimentation” for deep understand-ing of the concepts relating to scholarly advances in computerand network virtualization needs to be included in the curricu-lum. The ultimate learning objective being that students needto be able to architect scalable-infrastructures and developweb-service based applications utilizing distributed systems.

In this paper, we describe our efforts, experiences andfindings in the development and administration of laboratoryexercises that utilize public cloud infrastructures in a cloudcomputing course offered at University of Missouri in Fall2013 (Course). Fig. 1 summarizes the range of topics coveredin the Course with the aid of material from textbook portionsof [1], [3], and [4]. We utilized the AWS ‘Education UsageCredits’ as well as resources from the NSF-supported Global

Virtualization

Performance

Service Level

Agreements

Resource Monitoring

Pricing/Billing

Provisioning On-Demand Risk/Trust

Management

Energy Efficiency

Security/

Privacy Legal & Regulatory

Data Centers

Standards and Tools

Scalability

App

Marketplaces

Reliability

Adapted from Hwang, Fox, Dongarra [1]

Fig. 1: Cloud Computing Challenges covered in the Course

Environment for Network Innovations (GENI) Future Internetinfrastructure [5] in the Course laboratory exercises. The focusof this paper is to highlight how GENI provided an excellentplatform to develop and administer hands-on laboratory ex-ercises for students in the Course on cloud computing topicssuch as: distributed system resource discovery and manage-ment [1], federated identity and access management [6], appli-cation/system/network performance measurement and adapta-tion [10], and software-defined networking with OpenFlow [7].

The remainder of the paper is organized as follows: Sec-tion II presents the Course details. Section III describes ourGENI laboratory exercises development and administrationmethodology. Section IV presents distributed system program-ming projects that the students were able to work upon dueto skills gained from completing the laboratory exercises.Section V lists our salient findings and discusses how GENIwas helpful in the Course, and where we faced difficulties inusing GENI. Section VI concludes the paper.

II. COURSE DESCRIPTION

The delivery of a successful cloud computing course withina semester time-frame requires the students to have back-ground knowledge of concepts in areas such as: object-orientedprogramming, operating systems, computer networks, andcyber-security. Given that the Course was open to undergrad-uate students also, the curriculum had to be designed to coversome essential concepts in the pre-requisite areas. A total of30 students (23 Graduate, 7 Undergraduate) registered for theCourse (even though it was the first-time offering) to completeall of the course work; 5 additional students worked on the labsand attended select lectures as ‘visitors’. The main textbookfor the course was by Hwang, Fox and Dongarra [1], and 2additional reference books suggested to the students were [3]and [4] along with several relevant online resources.

The learning objectives of the Course were as follows:• Be competent with principles and architectures that inte-

grate computing theories and information technologies• Be competent with distributed system models, computer

virtualization concepts, network virtualization concepts• Be competent with the design, programming and appli-

cation of distributed and cloud computing systems• Be familiar with cyber-security and service-oriented con-

cepts relating to use/design of cloud computing systems• Be familiar with App customization of cyberinfrastruc-

ture resources, and related cloud computing standards,best-practices through hands-on experience

The first set of the Course topics provided an ‘Overview’of distributed system models and enabling technologies. Thiswas followed by a set of detailed lectures on ‘Virtualiza-tion’ concepts such as: virtual machines and virtualizationof clusters, networks and data centers. The sub-topics inthis portion included: levels of virtualization implementation;structures/tools and mechanisms for resource management.

The third portion ‘Architecture’ covered concepts of cloudplatform architecture with security over virtualized data cen-ters. The sub-topics in this portion included: public, privateand hybrid clouds ecosystem; public clouds and service offer-ings (i.e., Infrastructure-as-a-Service, Platform-as-a-Service,Software-as-a-Service, Desktop-as-a-Service); inter-cloud re-source management; cloud security and trust management.

The fourth portion ‘Web Services’ covered concepts ofservice-oriented architectures for distributed computing. Thesub-topics in this portion included: web services and message-oriented middleware; resource discovery, registries, metadata,publish-subscribe.

The last portion ‘Applications’ covered concepts of cloudprogramming and software environments. The sub-topics inthis portion included: cloud application requirements and con-straints; MapReduce, Hadoop library, Pig Latin; programmingsupport, approaches on real cloud platforms.

III. GENI LABS DEVELOPMENT METHODOLOGY

We developed three AWS-based lab exercises (see AppendixA for details), and three GENI-based lab exercises to helpstudents develop technical background and skills for workingwith distributed system and related software environments.In the AWS case, each student was provided with a $100education usage credit, whereas in the GENI case, each studentwas asked to join Calyam UMissouri Fall2013 Project in therecently developed GENI portal [8]. The AWS and GENIlabs were developed to be complementary to each other, andprovided the students an opportunity to study the similarities,differences and best-practices in multiple public cloud servicesettings.

Detailed step-by-step instructions were provided to thestudents through lab manuals. At the end of each lab exercise,students were asked to apply their hands-on learning andsubmit answers to questions meant to reinforce, and in somecases enhance the lab steps. Further, students also had tosubmit screenshots from the GENI-Portal and other tool userinterfaces that indicated they had successfully completed allof the lab exercise steps.

In the following sub-sections, we describe the GENI labexercises (Lab-1, Lab-2 and Lab-3) in greater detail.

GENI  Terminology   GENI  Architecture  

GENI  Account  Crea7on  

GENI  Environment  

Setup    

GENI  "Hello  World"  

Fig. 2: GENI Lab-1 Steps Sequence

Fig. 3: Typical GENI Experiment Workflow

A. Lab-1: GENI Account Setup and Services Overview

The Fig. 2 shows the Lab-1 steps that can be summarized asfollows: “Setup your GENI account, and use it to reserve anexperiment environment a.k.a. ‘slice’ that features 2 computenodes communicating over a Layer-2 connection. Run a ‘HelloGENI’ experiment with GUI (Flack) and Command-line(Omni) tools in your reserved slice by automatic installationand execution of software to perform basic connectivity andbandwidth measurement tests between the nodes.” The GENItutorial paper [5] and the GENI wikis on architecture andterminology served as helpful reading materials to guide thestudents through the intermediate lab steps (e.g., SSH key-pairgeneration). The step-by-step instructions in the lab manualfollowed the sequence of activities annotated in Fig. 3. Thestudents who used Microsoft Windows operating system werealso provided instructions to install VMware Player softwarethat allowed a light-weight Linux virtual machine to be usedto configure and run the Omni tool.

As students joined the Calyam UMissouri Fall2013 Projectin the “GENI Portal” [8], notifications were sent to the Instruc-tor to add the students as members of the Project. Given thatthe GENI Portal was setup as a ‘service provider’ under theInternet2 InCommon [9] research-and-scholarship category,the students were able to use their University of Missouri(MU) PawPrint ID and password, and did not need separateaccount creation in GENI. Such a login process was helpfulto demonstrate principles of ‘federated identify and accessmanagement’ that were discussed in the Course portions inthe context of cloud security and trust management, as wellas inter-cloud resource management. Thus, the GENI Portalalso served as an educational tool for students to experiencehow MU’s Shibboleth [6] integration would allow access toMU and external technology resources in a seamless manner.

Install  OnTimeMeasure  

Configure  OnTimeMeasure  

Control            (start/stop)  

measurements  

Query  Measurements  

Add  Custom  Metric  

Fig. 4: GENI Lab-2 Steps Sequence

Fig. 5: GENI Instrumentation and Measurement ExperimentComponents

B. Lab-2: Instrumentation and Measurement of a GENI SliceThe Fig. 4 shows the Lab-2 steps that can be summarized

as follows: “Install and configure a distributed measurementWeb App viz., ‘OnTimeMeasure’ within a slice. Configura-tion involves ‘Node Beacons’ at measurement points, anda ‘Root Beacon’ that acts as a central intelligence module.Schedule active measurements from the Root Beacon andquery/visualize network health performance between two com-pute nodes that host Node Beacons. Performance data collec-tion comprises of network health metrics such as round tripdelay, loss, jitter and throughput.” The OnTimeMeasure-GENIpaper and project wiki/videos [10] served as helpful readingmaterials to guide the students through the intermediate labsteps (e.g., add custom metric of CPU usage of Node Beaconsto be monitored in the slice). The step-by-step instructions inthe lab manual helped the students to setup, configure andinteract with the various instrumentation and measurementcomponents annotated in Fig. 5, and thereby understand pro-grammability and extensibility concepts in cloud monitoring.Moreover, the OnTimeMeasure software in GENI served as anexemplar case study to understand how to develop applicationsthat use web services when relying on distributed on-demandresource discovery, orchestration and management.

Before the Course was offered, the OnTimeMeasure soft-ware was developed to run on raw PCs in the GENI infras-tructure. However, since there were more than 30 studentssimultaneously working on the lab exercise, each requiring atleast 3 PCs, the GENI Project Office suggested that we modifythe code base to work on virtual machines (that are relativelymore in number compared to raw PCs) in the GENI Racksthat were being actively deployed during the Course offeringperiod. The code modification was a substantial effort and wewere able to utilize virtual machines in GENI Racks for thestudents to complete the lab exercise successfully.

Mininet  Installa+on   Floodlight  OpenFlow  Controller  Installa+on  

QoS  Configura+on  in  Controller  Applica+on  

QoS  Experimenta+on  using  Iperf  Tool  

Fig. 6: SDN Lab-3 QoS Control Experiment Steps Sequence

Floodlight  OpenFlow    Controller  installa3on  

Load  Balancer    Configura3on  in  Controller  

Applica3on  

Load  Balancing    Experimenta3on  using  Ping  Tool  

Fig. 7: SDN Lab-3 Load Balancing Experiment Steps Se-quence

C. Lab-3: QoS Control and Load Balancing using OpenFlowThe Figs. 6 and 7 show the steps of the Lab-3 software-

defined networking (SDN) experiments that can be summa-rized as follows: “Install and configure Mininet [11] emulatorwith 2 traffic engineering experiment applications to under-stand how to program ‘flow spaces’ within networks to: (i)comply with enterprise network capacity provisioning policies(QoS Control), and (ii) balance the utilization of network re-sources (Load Balancing).” More specifically, Fig. 6 shows therequired steps to configure Mininet with virtual switches [12]and use an SDN controller application that involves QoSconfigurations to rate-limit the capacity on network-edge linksconnecting client/server nodes. The students were requiredto use an adapted Floodlight Controller [13] module [14]to configure their experiment and verify bandwidth capacityprovisioning at network-edges using the Iperf Tool. Further,Fig. 7 shows the required steps to use another SDN con-troller application that load balances network traffic betweenclient/server nodes to show scalable handling of traffic flows.The students were required to use another adapted FloodlightController module [15] to configure their experiment andverify balanced usage of network resources using the PingTool. The lab instructions also provided steps to debug theOpenFlow controller functionality using the Wireshark toolthat got installed with the Mininet setup; the students usedWireshark to know the Ethernet ports that have been used ineach switch and capture/analyze the OpenFlow traffic (e.g.,Protocol ‘Header’ and ‘Stats Request’ fields information)between the controller and the Mininet environment.

IV. DISTRIBUTED SYSTEM PROGRAMMING PROJECTS

After completing the six labs corresponding to AWS andGENI, each student was asked to become part of a final projectteam to accomplish the following objectives: (a) To developprogramming and performance evaluation skills for a “real”problem in a GENI/AWS testbed, and (b) To reinforce theunderstanding of major concepts in the course in an integratedmanner. Each team was further divided into 3 sub-teams: (i)Core Logic Team, (ii) Testbed Team, and (iii) User InterfaceTeam. The projects were mandatory for graduate students, andundergraduate student participation received extra credit. Eachproject involved distributed system programming using eitherC/C++ or Java, as well as GENI/AWS cloud-platform specifictools and applications. In order to cope with the domainknowledge required to execute, each project had a designated‘Domain Expert’ who was one of the graduate students whoseresearch area was closely related to the problem being solved.

The projects were executed by the students over a 4-weekperiod in the last portion of the Course. In the first week,each team was required to submit a 2-page project plan, andthere were intermediate reports of core logic plan, testbedplan and user interface development plan in the followingweeks. Each project had to use web-services, and show designtradeoffs in the solution implemented. Detailed discussion andfeedback were provided at each report submission through in-class “circle times” to ensure progress and guide the students.Given that the six labs of GENI/AWS accounted only for 10%of the Course grade, whereas the final project accounted for30% of the Course grade, the students realized that they hadto maximize the learning from the labs and apply them toeffectively solve “real” problems pertaining to cloud comput-ing. After completing the project work, each team submitteda project report, and gave a presentation as well as a ‘live’demo in the classroom before all the Course students.

Brief descriptions of the Course final projects are as follows:1) Platform-as-a-Service for a City-supported Cloud In-

frastructure:This project was based on requirements from a“ElderCare-as-a-Service” testbed being developed atMU on the InstaGENI Rack platform as part of anNSF US Ignite project (CNS-1346789). The projectinvolved concepts of Desktop-to-Cloud transformation,and a recommendation engine for on-demand cloud ser-vice composition coupled with real-time monitoring andadaptation of communication and storage alternatives.The ElderCare-as-a-Service project goal is to develop anovel interactive exercise coaching interface that willconnect a remote physical therapist at MU to seniorresidents at Kansas City through Google Fiber, GENIoverlays, sensor monitoring and high-definition video.

2) Software-defined Networking for Multi-tenancy:This project was based on requirements from a dual-campus “Science DMZ” [16] testbed setup between MUand The Ohio State University through the Internet2 In-novation Platform as part of each institution’s NSF CC-NIE projects (OCI-1246001, OCI-1245795, Cisco Re-search Award). The project involved concepts of multi-tenant network virtualization and RoCE-accelerated datatransfers. The Science DMZ project goal is to integrateadvanced technologies (e.g., 10-100 Gbps connectivity,perfSONAR, OpenFlow, RoCE) for friction-free accel-eration of data-intensive flows over wide-area networkoverlay paths in order to satisfy real-time user experi-ence demands in diverse researcher applications withinareas such as bioinformatics and brain imaging.

3) App Marketplace for Advanced Manufacturing:This project was based on requirements from a“Simulation-as-a-Service” App testbed being developedby MU in collaboration with a small-business viz., Total-Sim as part of a GENI Solicitation 4 shakedown experi-ment project (GPO-1937). The project involved conceptsof App workflow orchestration in cloud environments,and cloud service pricing models. The Simulation-as-a-Service App project goal is to enable small companiesand trainees to access very expensive high-end simu-lation capabilities, and collaboration tools in real-timeusing access to high-performance and public-privatecloud computing resources connected via low-latency,high-bandwidth networks.

4) Data Integrity Security Protection and Monitoring: Thisproject was based on requirements from a “DIPS-Mon:Data Integrity Protection through Security Monitoring”testbed being setup in GENI as part of a collabora-tion between MU’s Dept. of Computer Science andthe Reynolds Journalism Institute (Thomson ReutersAward). The project involved concepts of distributedtrust, and anomaly detection for just-in-time news feeds.The DIPS-Mon project goal is to investigate techniquesto protect data integrity in use cases such as: (a) “Data-in-Motion” - when obtaining just-in-time news feeds(e.g., RSS feeds) from affiliates, and (b) “Data-at-Rest”- when compiled news feeds reside within cloud infras-tructure for real-time premium subscriber user access.

V. SALIENT FINDINGS AND DISCUSSION

In this section, we list the salient findings from our GENIlab exercise development and administration efforts in ourCourse, and discuss how our experience could guide otherinstructors/teaching-assistants seeking to adopt GENI withintheir cloud computing and distributed systems courses.

A. Level of Support/Instructions Needed to Complete Labs:Students in the Course had to be given detailed step-by-

step instructions to be able to complete the GENI and AWSlabs. Even after providing detailed instructions, some studentsexpressed difficulty in a few situations. We noticed that formost of the Course students, using distributed system resourcesand GENI/AWS tools was a new experience. We setup aseparate discussion forum for each of the labs, and studentissues were addressed via the discussion forum. Since wediligently prepared the instruction manuals and had testedthe steps extensively, the number of issues on the discussionforum were relatively small in number and easily manageable.It helped to have the teaching assistant subscribe to thediscussion form so that any issues were notified and addressedpromptly, as and when they came up.

B. AWS and GENI Combination Benefits:The combination and dove-tailing of AWS labs (see Ap-

pendix A for details) followed by GENI labs provided a richset of hands-on learning opportunities. It was interesting tofind that there were many similarities in AWS and GENI in-frastructures, tools and best-practices, and each reinforced theconcepts in the other. There were separate teaching assistantsassigned for AWS and GENI labs, and their interactions werevery fruitful in solidifying/testing the lab steps, developing per-tinent assessment questions to be answered after completingthe respective lab steps, as well as in the learning experiencefor all of the Course stakeholders.

C. GENI Project Office Interactions:The teaching assistant training sessions, regular telecon-

ference calls during lab exercise development, and one ofthe teaching assistant’s summer camp experience - were allvery helpful in the design and administration of the GENIlabs. The GENI Project Office (GPO) team was very co-operative, helpful in reviewing/refining of the lab exercises,and in guiding us cope with the large scale of the studentsneeding the relevant resources in our first-time offering ofthe Course. We felt that the GPO co-ordination for timingthe assignment of the labs was very important, and the GPO

provided several aggregate manager names that we could useto divide and assign the resources needed by the students. Forcompleting each lab, we provided 2 weeks time and manystudents chose to work on the lab exercise steps closer to thedeadline. This however did not cause any unexpected loadbottleneck issues that affected any student’s productivity.

D. GENI Wiki Documentation:A lot of helpful and useful documentation is available

on the GENI Wiki. It was thus, easy to point students torelevant educational materials in our lab instruction manuals.The GENI Portal was really a great tool, which made itvery easy to mange the students account setup within theCalyam UMissouri Fall2013 Project, as well as with theirslice management. The instructor and teaching assistant hadaccess to the student slices within the GENI Portal, and thismade it easy for tracking progress of students and for debug-ging any issues. Moreover, the GENI wiki helped fill manygaps in the textbooks used in the Course. For example, thetextbooks do not cover network virtualization and software-defined networking concepts. Through review of the variousGENI tutorials and the Lab-3 exercise, students were able tolearn about programmability of networks with OpenFlow andprinciples of software-defined networking as well as networkfunction virtualization.

E. Open Challenges in the Course use of GENI:Due to the scale of the students registered, and the Course

being a first-time offering, the Lab-3 OpenFlow experimentscould only be executed using the Mininet environment. Ouroriginal plan was to have the students implement their Open-Flow controllers on the GENI infrastructure. Although, wediscussed with the GPO on several occasions and had astrategy/architecture figured out in order to allow students torun multiple OpenFlow controllers simultaneously, we werenot able to come up with an execution plan in time. In addition,we felt that students generally found it more easier to useAWS resources in their projects due to better documentation,consistent user experience with workflow tools, and also dueto the AWS toolkit plugin for Eclipse, which made it easier forstudents to deploy testbeds. We feel that our Course needs tohave a subsequent offering in an advanced concepts setting,where more time is available for students to conduct morein-depth experiments with the GENI infrastructure.

VI. CONCLUSION

In this paper, we described our efforts, experiences andfindings in the development and administration of laboratoryexercises that utilize GENI infrastructure in a cloud computingcourse offered at University of Missouri in Fall 2013 with30 graduate/undergraduate students. The unique capabilitiesoffered by GENI infrastructure for experimentation of ad-vanced concepts such as network virtualization and distributedsystems programming, as well as the excellent support ofthe GENI Project Office and the helpful GENI Wiki docu-mentation - made our course offering a successful one. Oneof the most interesting set of events during the course waswhen the students were seeing new GENI Racks comingonline, including the one at University of Missouri. Obviously,feedback from several students was that they enjoyed seeingsuch a cutting-edge infrastructure take shape in front of theireyes, and their tour of the data center to see their university’sGENI Rack was one of the most memorable experiences.

Amazon  Web  Services    

AWS  Architecture  

AWS  Account  Crea5on  

Add  AWS  Educa5on  Credit  

for    $100  

Launch  instance  

Add  a  Bill  

Alarm  

Fig. 8: AWS Lab-1 Steps Sequence

REFERENCES

[1] “Distributed and Cloud Computing” - by K. Hwang,J. Dongarra, and G. Fox; First Edition [ISBN:9780123858801].

[2] “Amazon Web Services (AWS)” - http://aws.amazon.com[3] “Programming Amazon EC2” - by J. Vliet and F. Pa-

ganelli, 2011; [ISBN: 1449393683].[4] “Cloud Computing: Principles and Paradigms” - by

R. Buyya, J. Broberg, A. Goscinski, 2011; [ISBN:9780470887998].

[5] J. Duerig, R. Ricci, L. Stoller, et. al., “Getting Startedwith GENI: A User Tutorial”, Computer Communica-tions Review, Vol. 42, No. 1, 2012. (http://www.geni.net)

[6] R. Morgan, S. Cantor, et. al., “Federated Security: TheShibboleth Approach”, EDUCAUSE Quarterly, Vol. 27,No. 4, 2004.

[7] N. McKeown, T. Anderson, H. Balakrishnan, et. al.,“OpenFlow: Enabling Innovation in Campus Networks”,ACM SIGCOMM Computer Communication Review, Vol.38, No. 2, 2008.

[8] “GENI Portal” - http://portal.geni.net[9] “Internet2 InCommon” - https://incommon.org

[10] P. Calyam, M. Sridharan, Y. Xu, K. Zhu, A. Berry-man, R. Patali, A.Venkataraman, “Enabling PerformanceIntelligence for Application Adaptation in the FutureInternet”, Journal of Communications and Networks,2011. http://groups.geni.net/geni/wiki/OnTimeMeasure

[11] “Mininet Walkthrough” - http://mininet.org/walkthrough[12] “OpenvSwitch Virtual Switch” - http://openvswitch.org[13] “Floodlight Controller Project” -

http://www.projectfloodlight.org/floodlight[14] “SDN Controller Application for QoS Control” -

http://www.openflowhub.org/display/floodlightcontroller/How+to+implement+Quality+Of+Service+using+Floodlight

[15] “SDN Controller Application for Load Balancer” -http://www.openflowhub.org/display/floodlightcontroller/Load+Balancer

[16] “Science DMZ Network Design Model” -http://fasterdata.es.net/science-dmz

APPENDIX AAWS LABS

A. AWS Lab-1: AWS Account Setup and Services OverviewThe Fig. 8 shows the AWS Lab-1 steps that can be summa-

rized as follows: “Understand definitions of various AmazonWeb Services (AWS) and their use in cloud computing basedweb applications that are accessible over the Internet throughan AWS account”. The AWS documentation [2] and [3]Chapter 1 served as helpful reading materials to guide thestudents to get familiar with AWS concepts and services. Thestudents followed step-by-step instructions in the lab manualin order to understand pricing conditions and services docu-mentation related with‘AWS free usage tier’ i.e., conditions offree usage that involve free account availability, restrictions in

!!!!!!!!

Discover!Resources!

Configura1on!(Security!Group,!AMI,!EBS!Volume,!

Snapshot)!

!Connect!to!instance!withD!• Linux/Unix!• Windows!

Using!AWS!command!

line!

Installing!a!Web!

applica1on!CleanDup!resources!

AWS!commands!

!AWS!commands!

!

1! 2! 3! 4!

Fig. 9: AWS Lab-2 Steps Sequence

Fig. 10: AWS Lab-2 Steps Result

terms of instance types, pay-as-you-go service rates, operatingsystems that are under the free usage condition, and free usageaccumulation. They created their AWS account and creditedit with $100 funds granted per student for this course. Theyalso launched their first AWS EC2 (Elastic Compute Cloud)instance, and used AWS CloudWatch to add a Bill alarm formonitoring and managing their credit for the rest of the courseduration.

B. AWS Lab-2: AWS Resource Discovery and Instance Setup

The Fig. 9 shows the AWS Lab-2 steps that can be summa-rized as follows: “Use your AWS account for the discovery,reservation and access of virtual compute/storage infrastruc-ture instances; setup a platform along with web-applicationand related basic firewall configurations within your reservedinfrastructure resources”. Chapters 3 and 4 of [1], as well asChapters 1 and 2 of [3] served as helpful background readingmaterials to guide the students. The students followed step-by-step instructions in the lab manual in order to first launchthe instance created in Lab 1 within their AWS account anddiscover the multiple options to customize their infrastructure.In the second step, they used two different ways to connectto their instance through a local Linux/Unix or Windowscomputer. In the third step, they focused on the configurationof their ‘aws-cli’ (AWS command line interface) environmentso that they can test different aws-commands (e.g., to create asnapshot of their running instance volume) that we providedfor Steps 1 - 5, which accomplished the same actions theydid with the GUI management console of AWS. Next, in thefourth step, they configured a web application to show theirinstance-specific information (metadata) on their web browseras shown in the example illustrated in Fig. 10. Finally, theywere shown how to clean up resources used for this Lab.

S3    Simple  Storage  Service  

RDS  Rela2onal  Database  Service  

ELB  Elas2c  Load  Balancer  

AutoScaling    integrated  to  ELB  

Cloud  Watch  Alarms  and  Ac2ons  

Clean-­‐up  Resources  

Fig. 11: AWS Lab-3 Steps Sequence

Fig. 12: AWS Lab-3 Address Book Web-application that usesS3 and RDS services

C. AWS Lab-3: Platform/Application Provisioning and AutoScaling Adaptation

The Fig. 11 shows the AWS Lab-3 steps that can be sum-marized as follows: “Launch new instances through Imagestaken from your current instance state, include them to aload balancer configuration, and apply CloudWatch alarms forautomatically scaling up and scaling down using AutoScalingservice adaptations based on usage load demands”. Chapters3 to 6 of [3] served as helpful background reading materialsto guide the students. The students followed step-by-stepinstructions in the lab manual in order to learn about AWSservices that allow them to: store information in the cloud (S3),launch Relational Databases (RDS), and access them fromtheir instances. An address book web-application shown inFig. 12 built with PHP and MySQL technologies was providedto study performance impact due to usage load the resourcesi.e., demand of users. They experimented with concepts of loadbalancing by working with multiple instances (ELB), installingAutoScaling tools for scaling up and scaling down theirinfrastructure and integrated them to an ELB for efficient useof their resources. Their integration efforts involved creationof CloudWatch policies that would be triggered according tothe monitoring of usage load of the resources. Finally, theywere shown how to clean-up the configuration and instancescreated for this Lab.