AWS Compute
AWS Compute
Introduction to Amazon Elastic Compute Cloud
Amazon Machine Image (AMI)
Think of an AMI as a snapshot or template of a computer system. It contains the information about the operating system, installed applications, and other configurations that you want to have on your virtual machine (the EC2 instance). For instance, if you want to create a server for your website, you might use an AMI that includes a pre-configured web server software like Apache or Nginx. For example, the AMI “Amazon Linux 2” could be chosen for launching the Employee Directory Application.
AWS Marketplace
The AWS Marketplace is like an online store where you can browse and select pre-configured AMIs made by AWS, third-party vendors, or the AWS community. Think of it as an app store but for server configurations. It provides you with a variety of options depending on your needs. For example, you could find an AMI that’s optimized for running a WordPress site, another one for data analysis with Python, and so on.
Custom AMIs
As the name suggests, these are AMIs that you build according to your own needs. You start with a basic AMI, modify it by adding your own software or configurations, and then save it as a new AMI. This custom AMI can be used to launch instances that already have your preferred setup, saving you time and ensuring consistency.
EC2 Instance Type
This refers to the blend of hardware capabilities available for an instance (virtual machine). AWS groups instance types according to use cases like compute-optimized, memory-optimized, storage-optimized, and others. For example, “G” instance types are optimized for graphics-intensive applications like 3D visualizations, while “M5” types are general-purpose ones suitable for balanced usage of resources, as used in the Employee Directory Application example.
EC2 Instance Size
Once you’ve chosen an instance type, you can also choose a size for it, which determines the hardware capacity (CPU, memory, storage) of your instance. Sizes range from “nano” (very small) to “many extra large” (very large), and everything in between. Think of it as choosing the size of the computer you want to rent: A “small” one will have less power but will be cheaper, while a “large” one will have more power but will be more expensive.
The beauty of EC2 is that it’s flexible and allows you to quickly adjust your resources according to your needs. You can spin up an EC2 instance to test a new idea, then terminate it when you’re done, only paying for what you use. If you find that your application needs more (or less) resources, you can easily resize your EC2 instance or even change its type. This kind of flexibility can be a game-changer for businesses, enabling faster innovation and cost optimization.
Step by Step of setting up an EC2 Instance
1. Select an Amazon Machine Image (AMI):
Your first step is to choose an AMI. You can think of an AMI as a blueprint for your virtual computer. It will have an operating system (like Linux or Windows), and it might also include certain applications or configurations that you want your computer to have. You can choose an AMI from a list that Amazon provides, use an AMI that someone else has created and shared (e.g., from the AWS Marketplace), or create your own custom AMI with exactly the setup you need.
2. Choose an Instance Type and Size:
Next, you’ll choose an EC2 instance type and size. The “type” refers to the mix of computing resources that your virtual computer will have, like CPU power and memory. Different types are optimized for different kinds of tasks — for example, some types are optimized for computing-intensive tasks, others for memory-intensive tasks, and so on. The “size” of the instance refers to the scale of these resources. For example, a “large” instance will have more CPU power and memory than a “small” instance. You choose the type and size that best suits the task you want your virtual computer to perform.
3. Configure and Launch Your Instance:
After you’ve chosen an AMI and an instance type and size, you can configure additional details, like how your instance will be networked or how much storage it will have. Once you’re happy with your configuration, you can launch your instance.
4. Connect to Your Instance:
Once your instance is running, you can connect to it much like you would connect to any other computer on a network. You can then use this virtual computer to run your applications, host a website, analyze data, or whatever else you need to do.
5. Stop, Start, or Terminate Your Instance:
You can stop your instance when you’re not using it, then start it again when you need it. This is a bit like turning off your computer at the end of the day and then turning it back on again in the morning. If you don’t need the instance anymore, you can terminate it, which is a bit like decommissioning a physical computer.
Amazon EC2 Instance Lifecycle
Think of an Amazon EC2 instance (which is essentially a virtual computer running in the cloud) like a toy car. When you’re not using it, you can leave it in the box (stopped state), and you only take it out to play with it when you need it (running state). And when you’re done playing, you can just put it back in the box, ready to be used again when you need it. This flexibility allows you to control costs because you only pay when the toy car is out of the box, i.e., when the EC2 instance is in the running state.
Different stages (states) in the EC2 instance life cycle
Launch:
This is like taking the toy car out of the box and getting it ready to play. First, the instance enters a ‘pending’ state, which is similar to setting up the toy car and its track. During this ‘pending’ state, AWS performs all actions needed to get the instance ready, such as copying the Amazon Machine Image (AMI) content to the root device and setting up the necessary networking components. This is the preparation phase where the toy car gets its wheels checked, its batteries installed, and the track is laid out for it to run on. Remember, at this stage, the billing has not started, it’s like the playtime hasn’t begun yet. Once everything is set up and the instance is ready to go, it moves to the ‘running’ state. This is when the toy car is all set on its track and ready for you to start playing with it.
Reboot:
This is similar to resetting your toy car when it gets stuck or isn’t functioning properly. Imagine, instead of dismantling and reassembling the car, you just turn it off and on again. When you reboot an EC2 instance, it’s different than stopping and then starting the instance. It’s like a quick system refresh without changing the fundamental setup or location of your toy car.
Rebooting an instance is akin (similar to) to rebooting an operating system. The instance continues to exist on the same host computer, much like the toy car remains on the same track. It maintains its public and private IP addresses, just as your toy car retains its colour and sticker decorations. Additionally, any data stored on its instance store (analogous to any accessories or modifications on your toy car) remain intact (complete and not damaged). The reboot typically completes in a few minutes, just like how it only takes a little time to get your toy car back on track and ready for more action.
Stop:
This is like putting your toy car back in the box, but the box might not be exactly the same when you take the car out again. The EC2 instance enters a “stopping” state as it’s being powered down, similar to when you stop playing with the toy car and prepare to store it. Then it enters a “stopped” state, much like the toy car sitting stationary in its box.
However, when you take the toy car out again, the box (or the environment) might have changed a bit. When you stop and start an EC2 instance, your instance may be relocated to a new underlying physical server. In the world of the toy car, this could be like moving your toy car to a different track layout or playing environment. Consequently, any data on the instance store (which can be compared to any temporary modifications or accessories on your toy car) that were on the previous host computer are lost.
When you restart the instance, it’s like taking your toy car out of the box again. The car maintains its inherent characteristics like the private IP address, but it might get a new public IP address, much like getting a new sticker or a temporary mark on the car. But, the toy car itself remains the same, ready to be played with again.
Stop-Hibernate:
This is like pausing your play with the toy car, leaving everything exactly as it is, so you can resume from the same point when you return. It’s as though you’ve put the toy car on pause, freezing everything in its current state. The instance enters a “stopping” state and then a “stopped” state. However, in contrast to a standard stop, when you use stop-hibernate, it saves the contents from the instance memory (RAM) to the Amazon EBS root volume – similar to keeping all the changes and modifications of your toy car intact, even the trail it was following or the race it was in.
So when you start it again, it doesn’t just come back to life; it resumes exactly from where you left off. This is particularly important for certain scenarios. For example, if your toy car was part of an elaborate racing scenario that included specific positions of other cars, track changes, and so forth, stop-hibernate allows you to maintain that setup instead of starting the race from the beginning. In a similar manner, an EC2 instance running a custom backend caching solution can benefit from stop-hibernate by preserving the database information in memory (RAM), eliminating the need for manual scripts to save this data before shutting down the server.
This action would allow you to manage usage and data transfer fees more efficiently because AWS doesn’t charge for these fees when your instance is stopped, whether regularly or through hibernation. However, storage charges for any Amazon EBS volumes still apply. Just like how you’d still need space to store your toy car and its accessories even when you’re not actively playing with it.
Terminate:
This is like throwing away your toy car because you don’t need it anymore. The instance enters a “shutting down” state and then a “terminated” state, and it cannot be restarted again. It’s important to note that any data stored on the instance will be lost unless it’s stored elsewhere (like an external database or storage service), much like losing any stickers or modifications you made to the toy car when you throw it away.
So in a nutshell, the Amazon EC2 instance lifecycle allows you to control when and how you use your instances. You only pay for the instances when they’re in a “running” state or in the process of hibernating, and you can stop, start, or terminate them as your needs change. This is particularly useful for applications that don’t need to run continuously, as you can stop the instances when they’re not needed (like evenings or weekends), and start them again when they are (like during work hours).
Instance Families
Instance families are different groups of Amazon EC2 instances optimized to fit different computing requirements. They are categorized based on the balance of resources they offer such as compute (CPU), memory, storage, and networking capacity. Here are five instance families with their descriptions and use cases.
General-Purpose:
This family provides a balanced mix of compute, memory, and networking resources. They are like your versatile (able to do many different things) toolbox, capable of handling a wide range of tasks. They can be used for various workloads such as managing web servers, running microservices, maintaining caching fleets, supporting distributed data stores, and providing development environments.
Compute Optimized:
These instances are like your high-performance sports cars, built for speed. They’re ideal for compute-intensive tasks that benefit from high-performance processors. Use cases include high-performance web servers, scientific modeling, batch processing, distributed analytics, high-performance computing (HPC), machine/deep learning, ad serving, and highly scalable multiplayer gaming.
Memory Optimized:
These instances are like large storage rooms, designed for tasks that process large amounts of data in memory. They’re perfect for memory-intensive applications like high-performance databases, distributed web-scale in-memory caches, mid-size in-memory databases, real-time big data analytics, and other enterprise applications.
Accelerated Computing:
These instances are like your specialized machinery. They use hardware accelerators, or co-processors, to carry out functions more efficiently than regular CPUs. They’re good for tasks that need graphics processing like 3D visualizations, graphics-intensive remote workstations, 3D rendering, application streaming, and video encoding.
Storage Optimized:
These instances are like your industrial-grade warehouses, designed for tasks requiring high, sequential read and write access to large data sets on local storage. Use them for NoSQL databases (like Cassandra, MongoDB, and Redis), in-memory databases, scale-out transactional databases, data warehousing, Elasticsearch, and analytics workloads.
Architect for high availability
Think of an “Availability Zone” as a power grid in a city. Each grid supplies power to different sections of the city, but they all work together to keep the city running smoothly. If one grid goes down, the others can step in and keep the city’s power on.
Similarly, in the world of cloud computing, your applications and services run on “instances” (like little online computers), and these instances live in different Availability Zones, like different power grids. These Zones are separate, isolated locations within an AWS region that are engineered to be highly reliable.
Now, let’s say you’re running a popular online game, and you have all your game servers (EC2 instances) in one Availability Zone. If something happens to that Zone—maybe a big storm hits or there’s a technical issue—your game goes down. All your players are disappointed, and you might even lose some of them forever.
But what if you spread your game servers across multiple Availability Zones instead? That’s like having power grids all over the city. If one goes down, the others are still there to keep the lights on. This is what we mean by “high availability.” Even if one instance fails, the others can continue to support your game, so your players might not even notice there was a problem.
Furthermore, instead of relying on just a few big servers, you can use many smaller ones. This way, if one server fails, it’s a much smaller piece of your overall capacity. Imagine if your game becomes extremely popular overnight – with a single big server, you might struggle to handle all the new players. But with many smaller servers, you can spread the load, and it’s easier to add more servers as you need them.
In summary, when architecting for high availability, spread your instances across multiple Availability Zones and use multiple smaller instances instead of a few larger ones. This approach can help keep your applications running smoothly, even if problems arise.
Recap
Use multiple smaller instances:
Distributing your workload across many smaller instances can improve reliability. If one instance fails, only a small portion of your capacity is lost, and the remaining instances can continue to handle the load. This can be much more manageable than having one larger instance fail and losing all capacity until it’s restored.
Distribute instances across different Availability Zones:
This practice can help to ensure your application remains available even if one entire Availability Zone experiences an issue. Each Availability Zone runs on its own physically distinct, independent infrastructure, and is designed to be highly reliable. By having instances in more than one Availability Zone, you can protect your applications from the failure of a single location.
Maintain backups:
Although not explicitly mentioned in the provided text, maintaining backups of your critical data across multiple Availability Zones is indeed a good practice for high availability. These could be database backups, snapshots of your EBS volumes, or copies of important files stored in Amazon S3, for example. If something goes wrong, these backups can be used to restore your application to a working state.
EC2 Pricing Options
Pay As You Go with On-Demand Instances
Imagine you’re at a playground, and you want to ride the swings. On-Demand Instances are like having a swing that you can hop on any time you want, but you have to pay every minute you’re on it. The moment you get off the swing, you stop paying. This is great for when you’re not sure how long you’ll want to swing, but if you’re planning to swing all day, it might get expensive. In such a case, a ‘season pass’ might be more cost-effective, similar to Reserved Instances.
Reserve Capacity with Reserved Instances (RIs)
Continuing with our playground analogy, Reserved Instances are like buying a ‘season pass’ for the swing. You pay upfront (either fully, partially, or not at all), and you get to use the swing any time you want for a year or three years, depending on your ‘season pass’. This gives you a discount compared to the ‘pay per minute’ model of the On-Demand instances. But remember, even if you don’t use the swing, you’re still paying for it because you’ve committed to the ‘season pass’.
Save on Costs with Spot Instances
Spot Instances are like bidding on the swing’s free time. The playground might have a swing that isn’t used often. You tell the playground that you’re willing to pay a certain price for every minute on this swing, and if nobody else is using it and your price is higher than what the playground set (the Spot price), you get to use the swing. The catch is, if someone else comes along and offers to pay more, or if the playground decides they need the swing, you’ll be given a 2-minute warning to get off.
This is why it’s best to use Spot Instances for things that can handle interruptions. For example, imagine you’re working on a large puzzle. It doesn’t matter if you have to stop and start again, because you can just pick up where you left off – this is an “inherently fault-tolerant workload”. This makes Spot Instances perfect for big tasks that can be stopped and started, like analyzing large amounts of data (big data), running a website (web servers), or creating and testing software (CI/CD).
Container Service on AWS
Containers
Think of a container like a small, self-contained apartment that has everything you need to live. It’s not just the space itself but also the furniture, appliances, and utilities – everything you need is bundled together. For software, a container includes not just the application, but also all of the dependencies and configurations it needs to run. This means you can move the container (or apartment) anywhere and expect it to work the same way. This is great because it allows developers to package up their application and run it reliably anywhere, be it on their laptop or in a cloud environment.
Amazon Elastic Container Service (ECS)
Amazon ECS is like a building superintendent for your apartment complex. It takes care of all the tasks that are necessary for managing your apartments (containers) at a large scale, like starting, stopping, and monitoring the apartments. You tell ECS what you want to do with your containers, and ECS carries out those tasks for you.
Amazon Elastic Kubernetes Service (EKS)
EKS is similar to ECS, but it uses a different set of tools and processes to manage your containers. It’s like having a different type of building superintendent. Some people might prefer ECS while others might prefer EKS, depending on their specific needs and preferences.
Orchestration Tools
Both ECS and EKS are examples of orchestration tools. If managing a container is like managing an apartment, orchestrating containers is like managing a whole city of apartments. It’s about coordinating all the tasks necessary to manage a large number of containers – starting them, stopping them, monitoring their health, and so on. Doing this manually would be very difficult, especially as the number of containers grows, so we use orchestration tools like ECS and EKS to help with this.
AWS Fargate
Fargate is like a full-service apartment complex where you don’t have to worry about any of the maintenance or management. You just live there. Similarly, with Fargate, you don’t have to manage the underlying servers (EC2 instances) where your containers are running. You just focus on your containers and Fargate takes care of the rest. It’s a “serverless” platform because you don’t have to worry about the servers – AWS manages them for you.
Choosing between AWS Fargate, ECS, EKS, or EC2
Choosing between AWS Fargate, ECS, EKS, or EC2 really depends more on your specific use case and the requirements of your application, rather than your level of expertise.
EC2 is the most flexible option, giving you complete control over your virtual servers. It is like renting your own computer in the cloud where you can do almost anything you want. You have to manage everything from the operating system to the applications and their dependencies. It’s a good choice if you need that level of control and customization, or if you have a legacy application that doesn’t fit well into a containerized model.
ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service) are AWS services for running containerized applications. You’re still using EC2 instances under the hood, but AWS is handling some of the management tasks for you. These services handle the orchestration of your containers, meaning they take care of distributing your application across multiple containers and replacing any containers that fail. If your application is designed to run in containers, ECS or EKS can make it easier to manage and scale your application.
ECS is a good choice if you prefer a simpler, AWS-integrated solution for running containers. It works directly with other AWS services and has a straightforward pricing model.
EKS is a good choice if you’re already using Kubernetes, or if you want the flexibility to run your application on multiple cloud providers or on-premises servers. Kubernetes is a popular open-source container orchestration system, and EKS is AWS’s managed Kubernetes service.
Fargate is a serverless compute engine for containers that works with both ECS and EKS. With Fargate, you don’t need to manage the underlying EC2 instances at all; you just define your containers and Fargate takes care of the rest. This can make your infrastructure even easier to manage, and it’s a great choice if you just want to focus on your application and not worry about the infrastructure. However, you do lose some of the flexibility and control that you get with EC2.
So, a newcomer might start with Fargate for its simplicity, but even experienced AWS users might choose Fargate if it suits their use case. Similarly, someone with experience could choose EC2 if they need the control it offers, or they could opt for ECS/EKS if they’re running a containerized application. The best choice really depends on the specific needs of your application.
Understanding Container Orchestration
Question
Answer
Yes, that’s a core part of what container orchestration tools like Amazon ECS (Elastic Container Service) or Amazon EKS (Elastic Kubernetes Service) do. They manage the lifecycle of containers and maintain high availability of your applications.
When you have an application running in a container, you typically want to have multiple copies (instances) of that container running across different machines (nodes) to ensure high availability. This way, if one node goes down, your application doesn’t go down with it because there are other copies of your container running on other nodes.
The process of managing these instances of containers across a fleet of nodes is not trivial. You need to keep track of which containers are running where, start new containers when demand increases, shut down containers when they are not needed, restart containers when they fail, and so on. This is where container orchestration tools come into play.
They automate the distribution and management of containers, handle the scaling and descaling of instances, manage networking between containers, and ensure that if a container fails, it is replaced, and the system remains operational. It’s like a conductor of an orchestra, making sure all parts are working together in harmony.
Therefore, by using these services, developers can focus on writing their applications and let the orchestration tools handle the complexities of running them at scale.
AWS Lambda
AWS Lambda is a service offered by Amazon Web Services that lets you run your code without provisioning or managing servers. It’s part of what’s called the “serverless” architecture. Instead of you having to worry about running a server 24/7, maintaining it, and scaling it, AWS Lambda takes care of all of that for you. You can think of AWS Lambda as a place where you can run your code whenever it’s needed, and then when it’s done, AWS Lambda shuts it down.
The piece of code you upload to AWS Lambda is called a Lambda function. This could be written in several supported languages like Python, Node.js, Java, C# and more. Once you create a Lambda function, it just sits there and waits to be activated, or “triggered”.
The interesting part is how these Lambda functions are triggered. There are a number of ways a Lambda function can be triggered – for example, someone could upload a file to an Amazon S3 bucket, which in turn triggers a Lambda function to process the file. Or, a user could make a request to an API Gateway, which then triggers a Lambda function to respond to that request. Other AWS services and even in-app activity from mobile devices can also trigger Lambda functions.
Once the Lambda function is triggered, the code runs in a managed environment – an environment you don’t have to worry too much about because it’s automatically scalable, highly available, and all of the maintenance is handled by AWS. AWS Lambda will create as many copies of your function as needed to meet the demand, each running in its own isolated environment.
What’s really nice about AWS Lambda is that you only pay for the compute time you consume. So, you’re not paying for a server to be up all the time, you’re only paying for the time your code is actually running, rounded up to the nearest 100 milliseconds.
A practical example of using AWS Lambda could be an image resizing service. Say you’re building an employee directory where employees can upload their photos. Instead of having a server running constantly, waiting for photos to be uploaded, you could create a Lambda function that gets triggered whenever a new photo is uploaded. This Lambda function could resize the photo to a uniform thumbnail size and save it back to an S3 bucket. This way, you’re only using resources (and paying for them) when there’s an actual photo to be processed.
Remember, AWS Lambda is not designed for long running processes. It’s more suited for quick, event-driven processing like the image resizing example I just gave. So, while you wouldn’t host something like a WordPress site on AWS Lambda, it’s great for quick tasks that respond to specific events, like handling a web request or processing a report.
New Words
caching fleets
In computer terms, “caching” refers to the process of storing data in a cache, which is a temporary storage area. This is done so that the data can be accessed more quickly the next time it’s needed. This is very much like how a squirrel might store nuts for the winter – instead of having to go out and find new nuts every day, it can simply go to its stash and grab what it needs, saving time and effort.
“Fleets”, in this context, refer to a group of resources working together to perform a task. You can think of a fleet like a fleet of ships or a fleet of taxis – each individual vehicle in the fleet has a job to do, and by working together, they can cover a lot more ground and perform tasks more efficiently.
So, a “caching fleet” is essentially a group of resources (like servers) that work together to store data temporarily so it can be retrieved quickly when needed. This approach can greatly speed up response times for users and reduce the load on your main database or server. For example, if you’re running a busy website, a caching fleet could store some of the most frequently accessed information so that it doesn’t have to be retrieved from the main database every time a user requests it, improving performance and user experience.
Containerized Applications
A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Imagine you’re packing a suitcase for a trip. In that suitcase, you put everything you need – clothes, toiletries, accessories, etc. Everything that’s necessary for your trip is packaged in that one suitcase. That’s what a container is like for an application.
Now, let’s talk about containerized applications.
A containerized application is an application that is designed to run inside a container. Why would you want to do this? Well, there are a few key reasons:
Consistency: By running an application in a container, you ensure it has everything it needs to run. This includes not just the application itself, but also any dependencies, libraries, or other requirements. This way, you know the application will run the same way regardless of where the container is deployed, be it your personal computer, a test environment, or a cloud server.
Efficiency and Speed: Containers are lightweight and start quickly. They share the host system’s OS kernel and do not require an OS per application, driving higher server efficiencies and reducing server and licensing costs.
Isolation: Each container runs in isolation from others. This means that it has its own filesystem, CPU, memory, process space, etc. If one container crashes or has a problem, it doesn’t affect the other containers.
Portability: You can build a container locally on your laptop, then deploy it to various different environments, knowing it’ll run the same way. This is great for building and testing applications.
Scalability: It’s easy to create, replicate, delete, or move containers across systems as needed. This makes scaling applications simpler and quicker.
Let’s say you’re building a website (a web application). This website needs a database, a backend (to process data and handle logic), and a frontend (what the user interacts with). These components could all be developed, tested, and deployed separately in their own containers. This is an example of a containerized application.
In summary, containerization is a way of packaging and running applications in a portable, scalable, and consistent manner.