Kaigai Blog living abroad in my twenties

Getting Started with AWS Cloud

AWS

Getting Started with AWS Cloud

Simple Terms in AWS


Amazon Virtual Private Cloud (VPC):
Think of it as your own private network on the cloud. This is where you build your app, like the secure space for your Employee Directory app.

Amazon Elastic Compute Cloud (EC2):
This is your personal computer in the cloud. EC2 is where you host the code for your app, similar to how you would run a program on your computer.

Amazon Relational Database Service (RDS): This is your digital filing cabinet, where you can store, organize, and manage data. For your Employee Directory app, this is where the employee details would be stored.

Amazon Simple Storage Service (S3): Consider it as your unlimited digital storage box. This is where you can store any type of files like photos, documents, etc. For instance, you’d use S3 to store the photos of employees in your app.

Difference between RDS and S3

  • Data Structure: RDS is used for structured data, while S3 is used for unstructured data.
  • Data Operation: RDS is used when you need to operate on the data (search, sort, join, etc.), while S3 is used when you just need to store and retrieve the data.
  • Data Type: RDS is used for text-based data that fits in tables and rows, while S3 is often used for large files like images, videos, and backups.

Amazon CloudWatch: This is like your app’s health monitor. It keeps track of how your application is doing and sends alerts if something is wrong, ensuring everything is running smoothly.

Amazon Elastic Load Balancing: Think of this as a traffic controller. It helps distribute incoming app traffic across multiple EC2 instances, helping your app run smoothly even during peak traffic times.

Amazon EC2 Auto Scaling: This is your automatic staff manager. If your app gets busy, Auto Scaling adds more EC2 instances. If things slow down, it removes unnecessary instances, ensuring efficient use of resources.

Amazon Identity and Access Management (IAM): This is your app’s security guard. It helps manage who can access your app and what they can do in it.

What is Cloud?

The ‘Cloud’ refers to servers that are accessed over the Internet, and the software and databases that run on those servers. It’s called the ‘Cloud’ because the servers are located elsewhere, in a ‘cloud’ you can’t see or touch. This is in contrast to traditional computing where a company or individual would own and manage their own physical servers, and the applications would run on those machines.

Cloud computing is like renting a house instead of buying one. You can live in it, use the rooms, and get all the benefits, but the property doesn’t belong to you. Maintenance, improvements, and any issues are handled by the property owner (in this case, the cloud provider).

The cloud can provide vastly more computing power and storage than a personal computer or server because it harnesses the combined power of thousands of servers and their associated storage.

Six Benefits of Cloud Computing

1. Pay as you go: You only pay for what you use, just like utilities such as electricity. Instead of having to invest in expensive hardware and manage it yourself, you can use the resources provided by a cloud service and only pay for the resources you actually consume. This allows businesses to be much more flexible and cost-efficient.

2. Benefit from massive economies of scale: Cloud providers like AWS serve millions of customers, meaning they can bulk-buy hardware and pass those savings onto you. The more customers a cloud provider serves, the lower the cost per customer, allowing you to leverage their scale for your own benefit.

3. Stop guessing capacity: Before cloud computing, businesses had to estimate the maximum amount of resources they’d need to handle peak periods of activity, which often led to over-provisioning and under-utilization. With the cloud, you can easily scale your resources up and down as your needs change.

4. Increase speed and agility: In the past, deploying a new server or database could take weeks. But with the cloud, new resources can be provisioned in minutes. This allows businesses to be more agile and responsive to changes.

5. Stop spending money running and maintaining data centers: Instead of having to invest heavily in data centers and servers, and then spend a lot of time and money maintaining them, you can use the cloud. This allows you to focus on your core business instead of dealing with infrastructure issues.

6. Go global in minutes: With the cloud, you can easily deploy your application in data centers around the world, allowing you to serve your customers at high speed wherever they are. You don’t have to build and maintain your own global infrastructure.

Types of cloud computing

Infrastructure as a Service (IaaS)

This is like renting a house, where you have control over the interior of the house, but the landlord takes care of the walls, roof, and foundation. You’re responsible for your own furniture and utilities (like electricity and water), but you don’t have to worry about maintaining the actual building. In the tech world, this means you get to control your servers, storage, and networking, but you don’t have to worry about maintaining and updating the physical hardware — the cloud provider (like AWS or GoDaddy) takes care of that.

Platform as a Service (PaaS)

This is more like renting a fully furnished apartment. Not only is the building maintained for you, but so are the utilities and furniture. You just move in and start living. In tech terms, this means you’re given a platform with everything you need to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app. You can focus solely on writing the code for your app.

Software as a Service (SaaS)

This is like using a public library. You don’t own the books, you don’t maintain the building, you just show up and use what’s available. In the tech world, this means you’re given access to an application over the internet. You don’t have to worry about how the application is maintained or how the underlying infrastructure is managed, you just log in and use the software — like when you use Google Docs or Dropbox.

Each type of cloud computing service provides different levels of control, flexibility, and management, allowing you to pick the type that best suits your needs. Whether you need the raw building blocks of IaaS, the ready-to-use environment of PaaS, or the simplicity of SaaS, there’s a cloud service for you.

Understanding AWS Redundancy and Global Infrastructure

In the realm of cloud computing, building robust and reliable systems often involves implementing a concept known as redundancy. A helpful metaphor to understand this concept is the act of constructing two sandcastles on a beach. If one sandcastle is located near the shore and gets swept away by a wave, having an identical sandcastle farther from the water ensures you still have a sandcastle to enjoy.

Translating this to a cloud computing scenario such as AWS, imagine your server in a data center as the first sandcastle. If an unexpected event destroys that data center, it’s akin to a wave washing away your sandcastle. But if you’ve been prudent enough to establish an identical server in a different data center, just like the second sandcastle, your application can persist, unhampered by the loss of the first server.

This illustration of redundancy is fundamental to building robust IT systems. The idea is to spread your application across multiple servers in various data centers within an Availability Zone, or even across multiple Availability Zones within a region. This way, even if one server or data center goes down, your application remains accessible to users.

When considering the cost aspect of redundancy, it’s true that maintaining multiple servers might initially seem more expensive than just one. However, consider it a form of insurance policy for your digital assets. While there might be an upfront cost, it provides protection against the risk of your application becoming inaccessible, which could be significantly more costly, especially for businesses.

AWS also offers options to manage and optimize these costs. By using services like reserved or spot instances, you can strike a balance between cost-effectiveness and system reliability. In essence, the slightly higher upfront expenditure ensures that your application remains available to users, even in the face of unexpected incidents. Just like having that second sandcastle ensures you can keep enjoying your day at the beach, no matter what the waves bring.

Availability Zone (AZ)

Imagine you have a very precious family photo album that you want to keep safe. You decide to keep it in a safety deposit box at a local bank. But what happens if the bank building was destroyed in a fire or flood? You’d lose your precious photos, right? To avoid this, AWS (or in our case, the bank) builds multiple bank buildings (data centers) in the same area. So if one bank catches fire, your photos are still safe in the other bank. This cluster of banks or data centers is called an Availability Zone.

Q. What happens when a disaster strikes the data centers?

Let’s extend our photo album example. Now, what if a large-scale disaster like a hurricane or earthquake hits the whole town and all the banks in your Availability Zone are destroyed? To safeguard against this, AWS has another layer of protection. They build similar clusters of banks in different cities (or even countries). So even if one whole town is destroyed, your photos are still safe in another town or city. This is the idea of having multiple Availability Zones or clusters of data centers.

Region

A cluster of AZs (like clusters of banks in different cities) is known as a Region. Just like we have different regions on a map, AWS has different regions around the world, and you can choose which region to store your photos in based on your needs.

Redundant High-Speed and Low Latency Links

Different IP Addresses:
Each server in different data centers or AZs has different IP addresses. Your application will have a public-facing IP address or a URL that users interact with. Behind the scenes, this address is managed by a service like a load balancer, which is responsible for directing traffic to various servers.

Load Balancer:
The load balancer can distribute the traffic across multiple servers located in different data centers or AZs. This way, if one server (or even a whole data center) goes down, the load balancer can redirect the traffic to the servers that are still up and running. This happens seamlessly, so the users of your application might not even notice that there’s been an issue.

Redundant Links:
Now, for the load balancer to redirect traffic quickly and without significant delay, the connections between the data centers and AZs need to be high-speed and low-latency. That’s where the redundant links come in. They’re like the multiple highways in your analogy. Even if one link fails, the traffic can flow through the other links, ensuring your application remains accessible.

So, to summarize, the high-speed and low-latency links, along with services like load balancers, allow AWS to quickly reroute traffic in case of a server or data center failure, maintaining the availability and performance of your applications.

Deciding Which AWS Region to Use

  • Compliance: Does your photo album contain any personal or sensitive information that, due to laws, need to be stored in a specific country?
  • Latency: How quickly do you need to access your photos? If you need them immediately, you might want to store them in a region closer to you.
  • Price: Just as the cost of living differs from city to city, the cost of storing your data in AWS differs from region to region.
  • Service Availability: Not all AWS services are available in all regions, similar to how not all amenities are available in all cities.

AWS Global Infrastructure

Imagine a supermarket chain like Walmart. They have stores all over the world. In AWS terms, each store is like a data center, where your data and applications live. Some cities have multiple stores or data centers for convenience and redundancy; in AWS, we call this an Availability Zone. Now, imagine a country that has multiple cities with these stores; in AWS, this is called a Region. So, the AWS Global Infrastructure is like a global network of supermarket chains or Walmarts!

Global Edge Network, Edge Locations, and Regional Edge Caches

Now, let’s talk about a mini convenience store or a vending machine. These are smaller than the main stores and are spread even more widely. They stock popular items so that people can quickly grab what they need without having to travel all the way to the main store. In AWS, these mini-stores are called Edge Locations, and the items they stock are copies of your data or website. These copies are cached, meaning stored for quick access. AWS has a network of these Edge Locations around the world, known as the Global Edge Network.

Furthermore, some larger cities might have a bigger mini-store, which stocks more items – these are like the Regional Edge Caches. They are bigger than Edge Locations and serve a larger area.

Amazon CloudFront

Now, how do these mini-stores know which items to stock? Well, that’s where Amazon CloudFront comes in. CloudFront is like the delivery truck that refills the mini-stores or vending machines. It makes sure that the most popular and frequently accessed data from your website (like popular snacks in our analogy) is available at the Edge Locations closest to your users. This way, when a user accesses your website, the data they need is quickly available from the nearest mini-store, rather than them having to wait for it to be delivered from the main store far away. This reduces latency, or wait time, making your website faster for users all over the world.

Reserved or Spot instances

Reserved Instances

Let’s say there’s a popular movie that you know you want to watch at your local theater. To ensure you get a seat and probably save some money, you might choose to reserve a seat in advance for a specific date and time. This is essentially what Reserved Instances in AWS are like. With Reserved Instances, you commit to using a specific server or service in AWS for a set period (like one or three years) and in return, you get a substantial discount compared to the pay-as-you-go pricing model. It’s like getting a “bulk discount” for agreeing to use and pay for the resource for a longer time.

Spot Instances

Now, let’s imagine that the movie theater has some seats that haven’t been sold just before the movie starts. Instead of leaving those seats empty, the theater might decide to sell them at a huge discount to fill the room. However, if a customer who’s willing to pay full price comes in, they may ask you to leave. This is what Spot Instances are like. AWS’s Spot Instances are spare compute capacity that AWS isn’t currently using, which you can rent at a significantly lower price than normal. But, similar to the movie scenario, if another customer needs that capacity and is willing to pay the full price, AWS might terminate your spot instance. It’s a trade-off: you get a cheaper rate, but less stability.

In a nutshell, Reserved and Spot Instances are two different pricing models that AWS offers to help you optimize costs based on your needs and flexibility. If you can predict your needs well in advance and need a stable environment, Reserved Instances can save you money. If you’re flexible about when and how you use resources, Spot Instances can provide substantial savings.

Scope AWS Services

Think of AWS Services like different games at a carnival. Each game has its own rules and ways to play. Some games can be played anywhere at the carnival (Global), some are available only in specific areas (Region), and some are found in individual tents (Availability Zone or AZ).

When you’re using an AWS service that operates on a Region level (the games that are available in specific areas of the carnival), you just need to decide which area (Region) you want to play in. AWS doesn’t ask you to choose a specific tent (AZ), because the service is available throughout the entire area. It’s like choosing to play a game that’s available throughout the whole carnival, you don’t have to worry about finding the right tent.

For these Region-scoped services, AWS automatically takes care of things like making sure your data is safe and available. This is like having carnival staff who ensure all games in the area are functioning properly and are ready for you to play at any time.

On the other hand, there are some services where AWS asks you to choose a specific tent (AZ). For these services, it’s like playing a game that is only available in one particular tent at the carnival. You have to find that tent and play the game there.

When you’re using these AZ-specific services, you often have to take on more responsibility. This could involve making sure your data is backed up and always available, similar to ensuring you have enough game tokens and that the game machine is working properly.

In short, whether a service is global, regional, or AZ-specific in AWS changes the rules of the game, and thus, how you interact with that service.

Maintain Resiliency

Imagine that you’re running a popular lemonade stand in your neighborhood. To keep your stand open and serving lemonade even when unexpected things happen, you need to make sure your lemonade stand is resilient and always available.

One way to do this is to set up your lemonade stand in two locations (like two different street corners in your neighborhood). This is similar to using AWS services that are available in multiple Availability Zones (AZs). If a big parade blocks off one street corner (like an AZ going down), you can still sell lemonade from the other street corner.

But setting up two lemonade stands can be a lot of work. You have to make sure both stands have enough lemons, sugar, cups, etc. It would be much easier if there was a big lemonade company that could manage all of this for you.

That’s like using AWS’s Region-scoped, managed services. These services are like a big lemonade company that operates across the entire neighborhood (Region). They take care of all the hard work, like making sure there’s always enough lemons and cups, and keeping the stands open, even if one street corner gets blocked off. This built-in availability and resiliency mean you can focus on serving lemonade instead of worrying about running the stand.

So, to keep your application (lemonade stand) always available, it’s best to use managed services that work across an entire Region. But if that’s not possible, make sure to replicate your workload across at least two AZs (set up lemonade stands on at least two street corners). This way, even if one AZ (street corner) fails, your application (lemonade stand) will still be up and running.

Interacting with AWS

Let’s imagine that you’ve got a magical box, and you can request any toy you want from it – a doll, a toy car, a teddy bear. This magical box represents Amazon Web Services (AWS) with all its vast array of services. Now, how do you interact with this box? How do you tell what toy you want?

When it comes to AWS, you interact with it via something called an Application Programming Interface (API). You can think of an API as a language that you and AWS use to communicate with each other. It’s how you tell AWS what you want to create, delete, or change.

So how do you speak this API language to AWS? You’ve got three main options: the AWS Management Console, the AWS Command Line Interface (CLI), and the AWS Software Development Kits (SDKs).

AWS Management Console

Think of this as walking up to your magical toy box, opening it, and choosing a toy directly. The AWS Management Console is a user-friendly, web-based interface that you can access from your browser. It’s designed to be intuitive – you point, click, and follow prompts. For example, if you want to create a virtual server (like a remote computer), you can do it just by clicking through a few screens and filling out some information.

AWS Command Line Interface (CLI)

This is like giving voice commands to your magical toy box. Instead of pointing and clicking, you type out commands on your computer terminal. This is useful when you want to automate tasks or create multiple resources quickly. For example, instead of clicking through multiple screens to create two virtual servers, you can write a command to create them both at once, reducing the chance of human errors.

There are two main ways you can use the CLI:
a. You can download it on your computer and use your computer’s terminal to run commands.
b. You can use AWS Cloud Shell, a browser-based shell that lets you access the CLI directly from the AWS Management Console.

AWS Software Development Kits (SDKs)

This is like using a magic wand to get toys from your box. With the SDKs, you can write code in your favorite programming language (like Python, Java, Node.js, and others) to interact with AWS. This can be very powerful, as it lets you integrate AWS directly into your applications. For example, if you have an app where you store employee photos and you want to use an AWS storage service to hold those photos, you can use the Python SDK to write code that interacts with that AWS service.