I am asked frequently about the ins and outs of Amazon Web Services by C-levels, directors and managers. They are not looking for nitty gritty nuances of scripting with all the API of the Elastic Compute Cloudthey are only interested in the general overview of how the'cloud' functions.
When explaining AWS for the first time to supervisors (or anyone, for that matter) it is best to speak in theories rather than in concrete terms. I have also noticed it is beneficial to try to tangiblize the dialogue with recognizable terms. With terms such as"Elastic IP" gets quizical looks, but calling it a publicly available IP address helps individuals to acquire a better overall grasp of concepts before using the AWS conditions for things.

Hierarchical Organization


In a very high degree, you can think of EC2 as a global computing environment. Within EC2 are geographic areas which can be thought of as information centers. Inside of these data centers are computer clusters that in AWS parlance are called Availability Zones:
- EC2 (believe: cloud)
------ Regions (think: data centre )
------------- Availability Zones (think: pc cluster)

Within an Availability Zonewe have can make virtual machines from custom or predefined Amazon Machine Images, or AMIs. An AMI is considered as a snapshot of machine which you may load and run within the cloud at an Availability Zone. Every time you take an AMI and begin it, it's known as an instance of the AMI. You can take an AMI and begin it many times, every time creates a new case.
Instances are virtual machines which are running, and I truly mean they're virtual. If precautions are not taken, these digital machines can wink out of existence and also cause a lot of consternation. So you do not really want to think about an Instance as a tool that is robust and persistent. It's merely a component of computational tools.

Virtual Hard Drives


To help keep your data intact even if an Instance expires, you can use several different AWS services but one of the very common ones would be the Elastic Block Store, or EBS. Consider EBS as a Hard Disk. Consequently, in case you have an Instance that's running your site and you wish to be certain that the database remains healthy even if the Instance disappears, then you can use an EBS'hard disk'. In the vernacular of AWS, you've generated an EBS volume and mounted it on an case.
Other Virtual Storage
You can find other services you could have employed besides EBS for holding this fantastic database of yours. By way of example, the SimpleDB, or SDB, is a perfectly reasonable substitute and could be favored in certain situations. However, SDB is a specific support for basic database shipping, whereas EBS is a generalized storage alternative. There's also that the Relational Database Service, or RDS that provide robust database providers beyond SDB. The choice of service is frequently dependent upon the requirements of the solution.

Google Cloud


If we want to secure that information we have on our EBS volume, we aren't out of the woods yet because even hard drives can fail. We'll want to back up this into more stable storage. For this we can use the very simple Storage Solution, or S3 for short. It's possible to think of S3 as a readily available tape backup. Every one of those directories is referred to as a bucket from the S3 entire world. Because it's a good stable storage system, you will want to backup your EBS volume(s) into S3 periodically. And, when you've customized your Instance, you are going to 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 are able to pull them from your backup in S3 rather quickly and get up and running again.

Robust Security


Well, all this would be worthless if we didn't have great security to make sure that our solution has been murdered. Two concepts are employed in AWS for safety functions. The first is a pair of keys that allows you and your developers to access your systems. These are public/private key pairs and digital certificates required to securely log into the case. The second, called a security set, can be thought of as a firewall configuration. You make a security set that defines how outside entities - like web browsers, or distant backgrounds, or ftp, or email, etc. - can or cannot access your Instance.