I am asked often about the ins and outs of Amazon Web Services by C-levels, directors and managers. They aren’t looking for nitty gritty nuances of scripting with the API of the Elastic Compute Cloud, they are just interested in the general overview of how the ‘cloud’ works.
When explaining AWS for the first time to managers (or anyone, for that matter) it is best to talk in concepts rather than in concrete terms. I’ve also noticed it is beneficial to try to tangiblize the discussion with familiar terms. Using terms like “Elastic IP” gets quizical looks, but calling it a publicly accessible IP address helps people to get a better overall grasp of concepts before using the AWS terms for things.
Hierarchical Organization
At a very high level, you can think of EC2 as a global computing environment. Within EC2 are geographical regions that can be thought of as data centers. Inside of these data centers are computer clusters that in AWS parlance are called Availability Zones:
– EC2 (think: cloud)
—— Regions (think: data center)
————- Availability Zones (think: computer cluster)
Virtual Machines
Inside of an Availability Zone, we have can create virtual machines from predefined or custom Amazon Machine Images, or AMIs. An AMI can be thought of as a snapshot of machine that you can load and run inside the cloud at an Availability Zone. Each time you take an AMI and start it, it is called an Instance of the AMI. You can take an AMI and start it several times, each time creates a new Instance.
Instances are virtual machines that are running, and I really mean they are virtual. If precautions are not taken, these virtual machines can wink out of existence and cause a great deal of consternation. So you don’t really want to think of an Instance as something that is robust and persistent. It is merely a unit of computational resources.
Virtual Hard Drives
To help keep your data intact even when an Instance dies, you can use several different AWS services but one of the more common ones is the Elastic Block Store, or EBS. Think of EBS as a hard drive. You can make an EBS from 1GB to 1TB and ‘install’ it on any of your virtual machine Instances. So, if you have an Instance that is running your website and you want to make sure the database stays healthy even if the Instance disappears, you can use an EBS ‘hard drive’. In the vernacular of AWS, you have created an EBS volume and mounted it on an Instance.
Other Virtual Storage
There are other services you could have used besides EBS for holding this imaginary database of yours. For example, the SimpleDB, or SDB, is a perfectly reasonable substitute and would be preferred in certain situations. However, SDB is a specific service for basic database delivery, whereas EBS is a generalized storage solution. There is also the Relational Database Service, or RDS that provide robust database services beyond SDB. The choice of service is often dependent upon the needs of the solution.
Virtual Backup
If we want to secure that data we now have on our EBS volume, we aren’t out of the woods yet because even hard drives can fail. We’ll want to back this up into more stable storage. For this we can use the Simple Storage Solution, or S3 for short. You can think of S3 as a readily available tape backup. It allows you to have up to 100 directories of data on your tape. Each of these directories is called a bucket in the S3 world. Because it is a good stable storage system, you will want to backup your EBS volume(s) to S3 periodically. And, if you have customized your Instance, you will want to save a new image of it in S3 also. This way, if your carefully customized Instance or EBS volume crashes for any reason, you can pull them out of your backup in S3 fairly quickly and get up and running again.
Robust Security
Well, all of this would be worthless if we didn’t have good security to make sure our solution was hacked. Two concepts are used in AWS for security purposes. The first is a set of keys that allows you and your developers to gain access to your systems. These are public/private key pairs and digital certificates necessary to securely log into the Instance. The second, called a security group, can be thought of as a firewall configuration. You create a security group that defines how outside entities – such as web browsers, or remote desktops, or ftp, or email, etc. – can or cannot access your Instance.
Virtual Router
To serve our website to the public, we will need to have a permanent public IP address that we can assign to our Instance. For this we use an Elastic IP, or EIP. It is ‘elastic’ because although it is a fixed public IP on the Internet, it can be assigned to any of our Instances on the inside of AWS. This is a big plus because if that Instance dies and we bring up a new Instance, we can move the EIP to this new Instance and minimize site interruptions.
Cloud Scalability
Our site is up and running on our Instance, our data is safely on an EBS volume, we have backups on S3, well securely given our engineers access, and we have our site publicly accessible. All is well up to the point that we discover increased traffic from elsewhere in the world. Apparently, our site is popular in a geographical region that is distant from the region in which we set up our system. For example, we might have set up our website in the US, but we are getting 50% of our hits from Europe. Performance of our site for our European visitors will not be as good as we would like. Fortunately, we can push our site out closer to these users by using the Content Delivery Network, or CDN.
In AWS, CDN services are delivered by CloudFront. This service takes your static content and replicates closer to where you have a high volume of users, thereby making the delivery of your site much faster.
Conclusion
I hope this helps anyone interested in AWS and needs just a manager’s overview of how it all works from a conceptual perspective. Please note that AWS is a constantly evolving system and new services and capabilities are added regularly.
Resources
To learn more about Amazon Web Services, visit these important links:
[ad_2]Source by George B. Stevens
