Amazon Terminology

Terminology

The following terms defined by Amazon Web Services are used in this help file and defined here for your convenience:

·    Amazon Machine Image (AMI): Amazon Machine Images are machine images stored within Amazon’s infrastructure. An AMI contains the operating system and other software such as ScaleOut StateServer. A pre-packaged AMI that is configured with ScaleOut StateServer is available in the AWS Marketplace.

·    Instance: An instance represents a single running copy of an Amazon Machine Image (AMI).

·    Region: Amazon EC2 allows you to run EC2 instances in multiple geographic locations called regions. When deploying your ScaleOut StateServer instances, it is highly recommended that you select a region with the closest geographical proximity to the majority of your WAN traffic, if applicable.

·    Availability Zone: Every AWS region comprises two or more isolated units of failure within the Amazon Web Services environment called availability zones. A failure in one availability zone is unlikely to propagate to other availability zones within the same region. Resources within the same availability zone will experience lower average network latency than resources that cross availability zones.

·    Key Pair: A key pair is a public-key, private-key encryption system used by Linux-based instances for authentication when logging in to the systems via SSH. A key pair consists of a public key and a private key, and the matching key must be provided to authenticate against a running EC2 instance. An instance may have only one key pair defined at launch, and it may not be changed after launch. An instance without a key pair defined at launch will not be able to grant authentication for advanced administration via remote SSH login.

·    Private IP: A private IP address belongs to a single instance and is only routable from within the instance's associated EC2 Region. Data transfer fees do not apply to data transferred using private IP addresses. When operating within the same EC2 region, use of the private IP Address is preferred to avoid data transfer fees.

·    Public IP: A public IP address belongs to a single instance and is routable from within the EC2 environment, including from other EC2 regions, and from external, Internet locations.

·    Elastic IP (EIP): An Elastic IP (EIP) is a fixed (static) public IP address allocated through EC2 and assigned to a running virtual machine instance. Elastic IPs exist independently of virtual machine instances and may be attached to only a single instance at a time, but they may be reassigned to a different instances with complete transparency to end users. If an Elastic IP is associated with an instance, it invalidates and overrides the original public IP.

·    Security Group: A security group is a named set of allowed inbound network connection rules for EC2 instances. Each security group consists of a list of protocols, ports, and source IP address ranges. A security group can apply to multiple instances, and an instance can be a member of multiple security groups. Security groups may only be assigned to an instance when the instance is being launched. Changes to a security group’s allowed inbound network connections apply to all instances assigned to that Security Group. By default, the SOSS management tools create a new security group for each deployed SOSS store.

·    Placement Group: A cluster placement group is a logical entity that enables creating a cluster of instances with special characteristics, such as high speed networking. Using a placement group, a cluster of instances can have low latency, 10 gigabit Ethernet bandwidth connectivity between instances in the cluster.

Why an EC2 Instance Isn’t a Server

At Re:Invent, the AWS conference in Vegas last November, Amazon’s CTO, Werner Vogels, made an interesting observation during his keynote address: “An EC2 instance is not a server—it’s a building block.” This sounded suspiciously like a tagline a car manufacturer might use to convince me that their car “isn’t just another car.” But something about Vogels’ statement stuck with me. I had used EC2 since the public beta and he succinctly stated something that I knew to be true but didn’t understand why. It took a few months before I put the pieces together and could articulate what EC2 is and what it is not.

From all outward appearances, and even functionally-speaking, an EC2 instance behaves as a virtualized server: A person can SSH (or Remote Desktop) into it and install nearly any application. In fact, from my experience, this is how >95% of developers are using AWS. However, this is a very myopic view of the platform. Most of the complaints levied against AWS (unreliable, costly, difficult to use) are by those who are trying to use EC2 as if it were a traditional server located in a datacenter.

To truly understand AWS, we have to examine Amazon’s DNA. In 2002-2003, a few years prior to the introduction of EC2, Bezos boldly committed the entire organization to embracing service-oriented architecture. SOA is not unlike object-oriented programming (OOP): each function is discretely contained into an isolated building block and these pieces connect together via an agreed-upon interface. In software design, for example, this would allow a programmer to use a third-party library without needing to understand how the innards work. SOA applies the same principles at the organizational level. Bezos mandated that all business units compartmentalize their operations and only communicate through well-defined (and documented) interfaces such as SOAP/RESTful APIs.

For an organization of Amazon’s size, this change was a big deal. The company had grown very rapidly over the previous decade which led to the web of interconnectedness seen in all large companies: purchasing and fulfillment might share the same database server without either knowing who’s ultimately responsible for it, IT operations might have undocumented root access to payroll records, etc. Amazon.com’s organic growth had left it full of the equivalent of legacy “spaghetti code.” Bezos’ decision to refactor the core of operations required a tremendous amount of planning and effort but ultimately lead to much more scalable and manageable organization. As a result of the SOA initiative, in 2006, a small team in South Africa released a service that allowed computing resources to be provisioned on-demand using an API: Amazon Elastic Compute Cloud (EC2) was born. Along with S3, it was the first product of the newly introduced Amazon Web Services unit (since spun off into a separate business).

Amazon Web Services is the world’s most ambitious—and successful—result of service-oriented architecture.  This philosophy drives product innovation and flows down to its intended usage. When competitors like Rackspace argue “persistence” as a competitive advantage, they’re missing the entire point of AWS. EC2 is the antithesis of buying a server, lovingly configuring it into a unique work of art, and then making sure it doesn’t break until it’s depreciated off the books. Instead, EC2 instances are intended to be treated as disposable building blocks that provide dynamic compute resources to a larger application. This application will span multiple EC2 instances (autoscaling groups) and likely use other AWS products such as DynamoDB, S3, etc. The pieces are then glued together using Simple Queue Service (SQS), Simple Notification Service (SNS), and CloudWatch. When a single EC2 instance is misbehaving, it ought to be automatically killed and replaced, not fixed. When an application needs more resources, it should know how to provision them itself rather than needing an engineer to be paged in the middle of the night.

Interconnecting loosely-coupled components is how a systems architect properly designs for AWS. Trying to build something on EC2 without SOA in mind is about as productive (and fun) as playing with a single Lego brick.