Agents for Cloud Resource Allocation:

an Amazon EC2 Case Study

J. Octavio Gutierrez-Garcia and Kwang Mong Sim,

Gwangju Institute of Science and Technology,

Gwangju 500-712, Republic of Korea
joseogg@gmail.com and prof_sim_2002@yahoo.com

Abstract. Infrastructure-as-a-service consumers are presented with numerous

Cloud providers with a wide variety of resources. However, consumers are
faced with providers that may offer (even similar) resources at different hourly
cost rates, and also that no single provider may have matching resource
capabilities to fulfill a highly heterogeneous set of requirements. This work
proposes an agent-based approach endowed with the well-known contract net
protocol for allocating heterogeneous resources from multiple Cloud providers
while selecting the most economical resources. The contributions of this paper
are: (i) devising an agent-based architecture for resource allocation in multi-
Cloud environments, and (ii) implementing the agent-based Cloud resource
allocation mechanism in commercial Clouds using Amazon EC2 as a case study.
The Amazon EC2 case study shows that agents can autonomously select and
allocate heterogeneous resources from multiple Cloud providers while
dynamically sampling resources’ allocation cost for selecting the most
economical resources.

Keywords: agent-based Cloud computing; Cloud computing; multi-agent

systems; resource allocation.

1 Introduction

Infrastructure-as-a-service consumers are offered a wide diversity of Cloud resources

from multiple, distributed Cloud providers (e.g., Amazon EC2 [3], GoGrid [9], and
RackSpace [11]) supplied at different hourly cost rates. Moreover, similar Cloud
resources may be priced differently by each Cloud provider. Furthermore, Cloud
consumers may request heterogeneous sets of Cloud resources that may not be
available in a single Cloud provider. Thus, autonomously carrying out resource
allocation from multiple and self-interested Cloud providers while sampling hourly
cost rates associated to Cloud resources is necessary to provide efficient (i.e., with
low allocation costs) resource allocation services to consumers in a dynamic manner.
This stresses the need for the agent paradigm. Agents are autonomous problem
solvers that can act and collaborate flexibly and self-interestedly among each other.
In this paper, agents represent Cloud participants (consumers, providers, and
brokers), which use the contract net protocol (CNP) [13] to establish service contracts
with Cloud providers while sampling hourly cost rates. The CNP is used as the
foundation for an agent-based Cloud resource allocation mechanism to autonomously
allocate Cloud resources in multi-Cloud environments. Finally, an agent-based system
prototype was devised and implemented in which a case study using Amazon EC2 as
Cloud provider was carried out.
The significance and novelty of this paper is that, to the best of the authors’
knowledge, it is the earliest work in applying, developing, and deploying an agent-
based approach to allocate Cloud resources from multiple and commercial Cloud
providers (e.g., Amazon EC2) in an autonomous manner.
The contributions of this work are as follows. (i) Devising an agent-based Cloud
architecture for resource allocation in multi-Cloud environments (Section 2), and (ii)
implementing and deploying the agent-based resource allocation mechanism in
commercial Clouds using Amazon EC2 as a case study (Section 3). In addition,
Section 4 includes a related work comparison, and Section 5 presents conclusion and
future work.

2 An Agent-Based Cloud Resource Allocation Architecture

The components of the agent-based architecture that supports resource allocation in

multi-Cloud environments (Fig. 1) are as follows:

Fig. 1. Agent-based Cloud resource allocation architecture.

 1) A Cloud resource ontology (Fig. 2) is a formal specification of Cloud resources.
Cloud resources are defined by their functional and non-functional capabilities as well
as their location (URI address). Non-functional capabilities are (i) storage capacity,
(ii) memory, (iii) architecture type, and (iv) processing capacity. Functional
capabilities are (i) pre-installed operative system, and () pre-installed applications,
e.g., database servers.

Fig. 2. Cloud resource ontology.

2) A Cloud directory is a listing of Cloud participants either brokers or service

providers and their capabilities. The capability of brokers is stated as providing
resource allocation services to Cloud consumers. The capabilities of service providers
are defined by the Cloud resource types they offer. The Cloud directory is handled by
a system agent (see Section 3 for details) to which (i) service provider agents and
broker agents register their services, and (ii) consumer agents and broker agents
contact to request for broker and service provider agents’ addresses, respectively.
3) Consumer agents (CAs) act on behalf of Cloud consumers and are in charge of
submitting resource allocation requests composed of a set of Cloud requirements. To
do this, CAs adopt the initiator (manager) role of the CNP consisting of (i) sending a
call-for-proposals (resource allocation request) to q broker agents (contractors). Then,
from the p (p ≤ q) broker agents’ proposals, CAs select the best (e.g., cheapest)
proposal and send an accept message to the broker agent with the winning bid, and
reject messages to the remaining broker agents.
4) Broker agents (BAs) provide Cloud resource allocation services to CAs. To do
this, BAs adopt the participant (contractor) role of the CNP consisting of (i) receiving
resource allocation requests (call-for-proposals) from CAs, and (ii) replying with
proposals based on the current hourly cost rates associated to the Cloud resources. If a
BA is selected, the BA allocates the Cloud resources from service providers listed in
the Cloud directory with matching resource capabilities. To do this, BAs adopt the
initiator role of the CNP with service provider agents as participants. BAs’ call-for-
proposals are composed of single Cloud requirements. In doing so, CAs’ allocation
requests consisting of multiple Cloud requirements are handled by BAs as
independent and parallel resource allocations from the best (cheapest) service
providers for each Cloud requirement.
5) Service provider agents (SPAs) offer and supply Cloud resources to BAs by
adopting the participant role of the CNP with BAs as initiators. SPAs’ proposals
consist of allocation costs based on the Cloud resource types. In addition, SPAs
handle Cloud resource provisioning by requesting (de)allocations of Cloud resources
to resource agents.
 6) Resource agents (RAs) (de)allocate and monitor Cloud resources by using
specific vendor APIs (usually web services), e.g., Amazon AWS APIs [1]. RAs are
described by the Cloud resource type they can allocate. RAs’ functions are: (i)
receiving allocation requests from SPAs, (ii) creating private/public keys to access
Cloud resources, (iii) extracting and decrypting passwords to access Cloud resources,
(iv) extracting public IP addresses from recently allocated Cloud resources, and (v)
forwarding Cloud resources’ access information to SPAs.

Fig. 3. Cloud resource allocation interaction protocol.

An agent-based Cloud resource allocation scenario (Fig. 3) is as follows. A CA

retrieves BAs’ addresses from the Cloud directory, and then the CA sends a call-for-
proposals (consisting of a set of p Cloud consumer requirements) to a set of BAs. The
BAs reply with proposals containing the overall allocation cost. Afterwards, the CA
sends an accept-proposal message to the selected BA and reject-proposal messages to
the remaining BAs. Subsequently, the selected BA adopts p CNP executions with
SPAs (listed in the Cloud directory) as participants in a parallel manner, i.e., the
selected BA adopts a CNP execution for each Cloud resource requested by the CA.
The SPAs (selected by the BA) send allocation requests to appropriate RAs (i.e., RAs
matching the Cloud consumer requirements). Finally, the RAs extract the public IP
addresses and passwords from the recently allocated Cloud resources, and forward the
results to their SPAs that forward the information to the BA, which hand over the
information to the CA.

3 Agent-Based Cloud Resource Allocation in Amazon EC2

A case study using Amazon EC2 was carried out for which an agent-based system
prototype was implemented using (i) the java agent development framework (JADE)
[6], (ii) Bouncy Castle Crypto APIs [7] (for encrypting and decrypting Cloud
resources’ passwords), and (iii) Amazon SDK for Java [5].

3.1 Amazon EC2 Cloud Ontology

The Cloud resource ontology (Fig. 2) was provided with Cloud resource definitions
based on (i) Amazon instance types and (ii) Amazon machine images (AMIs), for a
total of 58 different Cloud resource definitions that resulted from the valid
combinations (i.e., not all the AMIs can be run on a given instance type) between
instance types and AMIs (Table 1).

Table 1. Amazon instance types and Amazon machine images.

Amazon instance types Amazon machine images

(i) t1.micro, (ii) m1.small,
(iii) m1.large, (iv)
m1.xlarge, (v) m2.xlarge,
(vi) m2.2xlarge, (vii)
m2.4xlarge, (viii)
c1.medium, (ix) c1.xlarge,
(x) cc1.4xlarge, and (xi)
cg1.4xlarge.
(i) Basic 32-bit Amazon Linux, (ii) Basic 64-bit Amazon
Linux, (iii) Red Hat Enterprise Linux 6.1 32 bit, (iv) Red
Hat Enterprise Linux 6.1 64 bit, (v) SUSE Linux Enterprise
Server 11 64-bit, (vi) SUSE Linux Enterprise Server 11 32-
bit, (vii) Microsoft Windows Server 2008 Base, (viii)
Microsoft Windows Server 2008 R2 Base, (ix) Microsoft
Windows Server 2008 R2 with SQL Server Express and IIS,
(x) Microsoft Windows Server 2008 R2 with SQL Server
Standard, (xi) Cluster Instances Amazon Linux, and (xii)
Cluster Instances HVM SUSE Linux Enterprise 11.

3.2 Cloud Participants and Distributed Cloud Environment

The agents involved in the case study were 1 RA, 5 BAs, 5 SPAs, and 2500 RAs.
Each agent, either CAs, BAs, or SPAs was deployed on a different JADE agent
container (see Fig. 1 and Fig. 4), i.e., an instance of a JADE runtime environment. In
addition, since RAs do not interact among themselves, all the RAs were deployed on
a single container (Container-1 in Fig. 4). In doing so, SPAs had to contact RAs
located at a remote location, and an unnecessary large number of containers was
avoided in the system prototype. The Cloud resource type of the RAs was randomly
selected from the available 58 Cloud resource types (Table 1). Moreover, all the RAs
were randomly assigned to the SPAs to simulate a scenario with highly heterogeneous
Cloud providers.

Fig. 4. JADE sniffer agent showing an agent-based Cloud resource allocation scenario.

All the agent containers must be and were registered in a main JADE container that
manages and supports the agent-based platform by (i) handling asynchronous
message passing communication through Java RMI and IIOP, (ii) starting and killing
agents, and (iii) providing services such as: a directory facilitator agent (Cloud
directory), a sniffer agent, a remote management agent, etc., see [6] for details of
JADE.
Fig. 5. AWS management console – Key pairs option.

Fig. 6. AWS management console – My instances option.

As shown in Fig. 4, agent-based platform CloudMAS had: (i) 1 Main-Container

including a remote monitoring agent (RMA@CloudMAS), an agent management
system (ams@CloudMAS), a directory facilitator (df@CloudMAS), i.e., a Cloud
directory, and a sniffer agent (for illustrative purposes); and (ii) 12 basic containers
(from Container-1 to Container-12). Container-1 included all the RAs. The SPAs and
BAs were included in agent containers ranging from Container-2 to Container-11,
one agent for each container. Finally, the CA was included in Container-12. Since all
the agent containers were deployed on the same host, each container was provided
with a different network port to simulate a fully distributed environment.

3.3 Cloud Resource Allocation Scenario

The CA was provided with a Cloud resource allocation request composed of 6 Cloud
resources: 4 m1.small instances with an AMI ami-8c1fece5 (Basic 32-bit Amazon
Linux AMI 2011.02.1 Beta) and 2 m1.large instances with an AMI ami-8e1fece7
(Basic 64-bit Amazon Linux AMI 2011.02.1 Beta).
Fig. 7. Console output for agent-based resource allocations using Amazon SDK.

The CA submitted the allocation request to the 5 BAs by using the CNP. The
selected BA executed 6 CNP (one for each Cloud resource to be allocated) with the 5
SPAs in a parallel manner. Finally, the selected SPAs requested the Cloud resource
allocations to their RAs. Fig. 4 shows an extract of the messages exchanged among all
the agents to carry out the Cloud resource allocation request, which was fulfilled by
agent BA4 (a BA selected by consumer CA1). The messages received by agent BA4
(Fig. 4) came from the SPAs bidding for allocating a Cloud resource and/or providing
data to access the recently allocated Cloud resources, e.g., the messages exchanged
between agents SPA1 and BA4, see Fig. 4. In addition, as soon as allocation data
(public IP address and password to access a given Cloud resource) was received,
broker BA4 forwarded the data to consumer CA1, as shown in the bottom of Fig. 4.
The interleaving of messages received by agent BA4 from all the SPAs (see Fig. 4) is
the result of the parallel execution of CNPs for allocating Cloud resources.

3.4 Technical Aspects to Handle Cloud Resource Allocation in Amazon EC2

The RAs were provided with (i) Amazon EC2 API tools to handle Cloud resource
allocations, and (ii) Amazon AWS security credentials to access Amazon EC2. It
should be noted that although the RAs shared the same security credentials (i.e., all
the RAs accessed Amazon EC2 using the same Amazon AWS account), sharing the
credentials had no advantageous effects on the agent-based Cloud resource allocation
approach.
 When the RAs received the SPAs’ requests to allocate Cloud resources, the RAs
created new RSA key pairs to access Amazon EC2 (Fig. 5). The key pairs were
automatically named based on the identifiers of the RAs that allocated the Cloud
resources, e.g., newKeyRA2462 (see the left side of Fig. 5). Right afterwards, the RAs
proceeded to allocate the Cloud resources (Fig. 6) corresponding to the CA’s initial
allocation request (consisting of 6 Cloud resources, see Section 3.3).
The console output of the agent-based system (Fig. 7) corresponding to the CA’s
allocation request shows: (i) JADE initialization messages displaying agent
containers’ addresses and names, (ii) self-generated output messages derived from the
creation of key pairs by using Amazon SDK, and (iii) self-generated output messages
derived from the Amazon instance allocations by using Amazon SDK. In general, the
self-generated output messages contained the following information: timestamp, key
pair name, AWS access key, type of instance allocated, etc., see Fig. 7 for details.
Since Amazon instances take some time to be fully functional (i.e., to start) and the
delay time may vary due to the size of AMIs, number of instances to be allocated,
among other factors [2], the RAs were continuously checking (every 200 s) whether
Amazon instances were up and running by retrieving the console output of the
recently allocated instances as indication of the start of the instances. Once the RAs
detected an output in the instances’ console, the RAs proceeded to extract the public
IP addresses and passwords (only possible when the instances are up and running),
which were forwarded to their corresponding SPAs.

4 Related Work

Resource allocation mechanisms have been widely investigated (see [12]). However,
little attention has been directed to (i) Cloud resource allocation in multi-Cloud
environments, and (ii) to actual implementations of autonomous Cloud resource
allocation mechanisms. Whereas current Cloud management systems (see [8], [10],
and [14]) may allocate Cloud resources from different Clouds to execute consumers’
applications, no explicit consideration of autonomous Cloud resource selection based
on fees associated to Cloud resources has been made. In contrast, this present work
uses both the agent paradigm and the CNP to (i) sample Cloud resources’ hourly cost
rates, and (ii) allocate Cloud resources in multi-Cloud environments in an
autonomous and dynamic manner.
In addition, the proposed agent-based Cloud resource allocation mechanism is fully
distributed, in contrast to centralized allocation mechanisms (see [4]) that require a
central control entity (allocator) that commonly becomes a system bottleneck.

5 Conclusion and Future Work

The contributions of this paper are as follows. (i) Devising the earliest (to the best of
the authors’ knowledge) agent-based Cloud architecture for resource allocation in
multi-Cloud environments, and (ii) implementing and deploying the agent-based
resource allocation mechanism in commercial Clouds using Amazon EC2 as a case
study.
In this work, autonomous agents equipped with the CNP to (i) dynamically sample
hourly cost rates and (ii) support cost-based Cloud resource allocation among self-
interested Cloud participants were used to deal with Cloud resource allocation in
multi-Cloud environments. By using the agent paradigm, Cloud consumers can
efficiently (i.e., with the lowest allocation costs) allocate heterogeneous sets of Cloud
resources from multiple, distributed Cloud providers in a dynamic and autonomous
manner as shown in the Amazon EC2 case study.
Since this work provides the foundations for a general-purpose agent-based multi-
Cloud platform by providing an infrastructure-as-a-service solution (allocated from
multiple Cloud providers) to Cloud consumers, future research directions include: (i)
adding agent capabilities to schedule and execute both workflows and bag-of-tasks
applications in multi-Cloud environments, and (ii) implementing access to more
commercial Cloud providers, such as: GoGrid [9] and RackSpace [11].

Acknowledgments. This work was supported by the Korea Research Foundation

Grant funded by the Korean Government (MEST) (KRF-2009-220-D00092) and the
DASAN International Faculty Fund (project code: 140316).

References

1. Amazon EC2 API Tools, http://aws.amazon.com/developertools/351

2. Amazon EC2 FAQs, http://aws.amazon.com/ec2/faqs
3. Amazon Elastic Compute Cloud (Amazon EC2), http://aws.amazon.com/ec2
4. Asmild, M., Paradi, J.C., Pastor, J.T.: Centralized Resource Allocation BCC Models, Omega
37(1), 40-49 (2009)
5. AWS SDK for Java – A Java Library for Amazon S3, Amazon EC2, and More,
http://aws.amazon.com/sdkforjava
6. Bellifemine, F., Poggi, A., Rimassa, G.: JADE - A FIPA-Compliant Agent Framework. In:
4th International Conference and Exhibition on the Practical Application of Intelligent
Agents and Multi-Agents, pp. 97-108 (1999)
7. Bouncy Castle Crypto APIs, http://www.bouncycastle.org
8. Buyya, R., Pandey, S., Vecchiola, C.: Cloudbus Toolkit for Market-Oriented Cloud
Computing. In: Jaatun, M.G., Zhao, G., Rong C. (eds.) CloudCom 2009, LNCS, vol. 5931,
pp. 24-44. Springer-Verlag, Berlin, Heidelberg (2009)
9. GoGrid, http://www.gogrid.com
10.Lee, K., Paton, N.W., Sakellariou, R., Deelman, E., Fernandes, A.A.A., Metha, G.: Adaptive
Workflow Processing and Execution in Pegasus. Concurr. Comput.: Pract. Exper. 21(16),
1965-1981 (2009)
11.RackSpace, http://www.rackspace.com
12.Sim, K.M.: A Survey of Bargaining Models for Grid Resource Allocation. SIGecom Exch.
5(5), 22-32 (2006)
13.Smith, R.G.: The Contract Net Protocol: High-Level Communication and Control in a
Distributed Problem Solver. IEEE Trans. Comput. 29(12), 1104-1113 (1980)
14.Yang, Y., Liu, K., Chen, J., Lignier, J., Jin, H.: Peer-to-peer Based Grid Workflow Runtime
Environment of SwinDeW-G. In: 3rd IEEE International Conference on e-Science and Grid
Computing, pp. 51-58. IEEE Computer Society, Washington (2007)