AWS Basics: What you need to know before you start using it

Amazon Web Services (AWS)Even if you have decided to use it, there are often cases where you feel that "there are too many terms and I can't grasp the overall picture" or "I don't know where to start," and you end up stopping before you can start learning or verifying it.

This article is aimed at first-time AWS users and will outline prerequisite knowledge, such as the system, structure, and concepts, rather than providing detailed instructions on operating procedures or how to use individual services. It will explain the bare minimum you need to know before starting to use AWS, including basic concepts such as accounts and regions, the roles of major services, and how to think about operations and fees.

The big picture you need to understand before you start using AWS

Amazon Web Services (AWS)When trying to understand AWS, the thing that often stumbles is not the individual services or how to operate them, but the basic understanding of what AWS provides. Here, we will organize the overall picture that you should understand before starting to learn AWS.

AWS is not a single service, but a family of services

AWS is not a single product or tool, but a set of cloud services that combines many different services, such as servers, storage, databases, networks, and security, each tailored to a specific purpose.

If you think of using AWS as just introducing one thing, it's hard to grasp the big picture. The basic idea behind AWS is that you select the features you need and use them in combination.

First of all, you need to understand that AWS is not a "one box that can do anything" but a "collection of components prepared for specific purposes."

The biggest difference with on-premise is the shift from "ownership" to "use"

An important aspect of understanding AWS is the difference between on-premises and on-premise systems, where the premise is that servers and network equipment are purchased, owned, and managed in-house.

With AWS, you don't own the infrastructure yourself; you use only what you need for as long as you need it. You're less concerned with physical equipment, and your perspective changes to "which functions you use and how much."

Why learning AWS in the wrong order can be confusing

AWS has a large number of services and a lot of technical terminology, so if you start operating or building it right away, it's easy to lose sight of the big picture. Even if you read the explanations of individual services first, there are cases where you don't understand "why you need it."

In particular, if you proceed without understanding common concepts such as accounts, regions, fees, and permissions, you will not be able to grasp the background to the settings and decisions you make. Even if you are able to follow the steps, you will not understand why you are doing it that way.

When learning about AWS, it is most efficient to first understand the overall structure and underlying concepts, and then move on to individual services.

Understand the basic structure of AWS

When you start using AWS, it's important to understand the basic structure that supports the whole rather than how to operate individual services. Here, we'll clarify the concepts of "accounts" and "locations (regions/AZs)," which can be difficult to understand at first.

What is an account?

First, create an Amazon Web Services account. This account is not just a login ID, but also a unit for managing usage fees, resources, and permissions.

All resources created on AWS, such as servers, storage, and networks, are tied to a specific account. Billing is also done on an account-by-account basis, which forms the basis for managing "who is using how much."

If you don't understand the concept of an account at first, you will be confused about permission management and cost management later. In AWS, it is best to think of an account as the starting point for use.

The concept of regions and AZs (availability zones)

With AWS, you choose the "location" where you want to use the service. This location is called a region, and multiple locations within a region are called AZs (Availability Zones).

Regions are divided into countries or regions, and AZs are independent data centers within the same region, allowing for a design that can distribute the impact of failures even within the same region.

The important thing is that you need to be aware of which region you want to create your AWS resources in. Unlike on-premises resources, you can use them without worrying about their physical location.

Why location affects design and cost

In AWS, the design, cost, and operational approach changes depending on where resources are located. For example, communication across regions may incur additional communication costs.

Using multiple AZs to increase availability makes the configuration more complex, but more resistant to failures. On the other hand, a simpler configuration makes it easier to reduce costs and operational load.

As you can see, choosing a location is directly linked to the design decision itself. Before you start using AWS, having a clear idea of ​​where to place it will make the decision smoother later on.

What does "service" mean in AWS?

The use of the word "service" can be confusing. Here, we will explain the positioning of services within AWS and organize the most representative services by purpose.

Positioning of services in AWS

A "service" in AWS refers to a unit that provides a specific function. Servers, storage, databases, networks, etc. are provided as independent services for each role.

It's important to note that with AWS, systems rarely consist of just one service. It's assumed that multiple services are combined to create a single system or environment. Therefore, rather than memorizing the names of services, it's important to understand what role each component plays.

H3: Understand the role of representative services by their uses.

You don't need to understand all of the various AWS services from the beginning. To get started, it's enough to understand the basic roles that are frequently used.

• Compute (e.g., EC2)

  • This service provides the processing power required to run applications. It is equivalent to an on-premise server and serves as the platform for running the OS and middleware.

• Storage (e.g. S3)

  • This is a service for storing files and data. It is used for a wide range of purposes, including backup, data storage, and content distribution.

• Database (e.g. RDS)

  • This service structures and manages data, reducing the operational burden of databases and allowing applications to use it.

• Network (VPC)

  • It is a system for creating a virtual network space on AWS. It designs how to connect servers and databases and how to connect to the outside world.

These are all parts that are not meant to be used individually, but rather in combination.

How do I operate it?

AWS services are operated from a management screen called the Management Console, which can be used in a web browser to create, configure, and check the status of each service.

Beginners will generally start by operating through this console. Operation is merely a means to an end, and it is important to understand which services you are using and for what purpose before using them.

The premise behind using AWS

When using AWS, it is important to understand the premise of how it works, rather than the name of the service or how to use it. Here, we will organize the concepts you should keep in mind when using AWS.

The concept of pay-as-you-go pricing (not pricing details but structure)

AWS uses a pay-as-you-go model where you are basically charged for only what you use, which is different from the idea of ​​"unlimited use for a fixed monthly fee."

It is important to understand the structure of what you use to incur charges. Costs accumulate depending on usage, such as the time the server is running, the amount of data stored, and the amount of communication.

You don't need to remember the exact unit prices, but it's important to keep in mind that costs will continue to be incurred if you continue to use the service.

The idea of ​​"making, using, and deleting" resources

With AWS, you create resources such as servers and storage as needed, use them, and delete them when they are no longer needed. Unlike on-premises, you are not expected to use the same equipment for an extended period of time once it has been prepared.

In a test environment or for temporary use, deleting resources after they have been used reduces costs and management burden. AWS's unique feature is that it can be designed and operated on the premise that resources can be deleted. On the other hand, leaving unnecessary resources in place can result in unintentional costs continuing to accrue.

Mistakes that are likely to occur if you continue to think of things as on-premise

There are some points that can easily trip you up if you use AWS in the same way as on-premises. A typical example is the idea that "once you set up a server, it's fine" or "it's okay if you're not using it."

With AWS, many resources incur charges simply by being running, and leaving them unattended can lead to increased costs. Using permissions and network settings in their default state can also pose a risk.

With AWS, you need to change your mindset to "use only what you need, for as long as you need it."

Operation and management points that are easy to get stuck on

While AWS is flexible to use, starting to use it without understanding the prerequisites for operation and management can lead to unexpected problems. Here we will summarize the main points to keep in mind in the early stages.

Learn about the basics of security: the "shared responsibility model"

AWS adopts the concept that security responsibilities are divided between the service provider and the user, a concept known as the "shared responsibility model."

While the security of the infrastructure itself is the responsibility of the service provider, the responsibility for configuration and operation lies with the user. If you think, "Because it's cloud, I can leave all security to you," a misunderstanding will arise. It is important to first understand "to what extent is your responsibility" before starting to use it.

The principle of "least privilege" in identity management (IAM)

AWS allows you to finely control who can perform which operations. This concept of permission management is called "least privilege."

If all operations are permitted from the beginning, configuration errors and unintended changes will occur, so it is safer to permit only necessary operations and gradually add permissions. Organizing permissions after operations have begun is time-consuming, so it is best to agree on a common approach at an early stage.

Logging and monitoring is too late if you wait until a problem occurs

AWS provides a system for recording and monitoring operation history and system status, but these are not just for investigating the cause of problems after they occur.

Setting up logs and monitoring in advance will allow you to quickly notice abnormalities and make it easier to understand the scope of their impact. If you start operation without configuring them, you will not be able to track the situation when a problem occurs. While it is not necessary to implement advanced monitoring from the beginning, it is important to have an attitude of "thinking about it first, not later."

What AWS beginners should and shouldn't do

Many people tend to think, "I have to understand it properly" and "I can't fail," but there's no need to aim for perfection from the start. Here, we'll organize how to separate the decisions.

Don't try to understand all the services from the beginning

AWS has many services, but you don't need to understand them all from the beginning. If you try to learn everything comprehensively before you have decided on your use, you will be overwhelmed by the amount of information.

The important thing is to understand only the extent to which it is relevant to your current purpose. Investigating services you won't use in depth will only be a burden in the early stages. First, grasp the basic structure and typical roles, and then understand individual services when you need them.

Separate the testing and production environments

With AWS, it is relatively easy to build separate environments. Taking advantage of this characteristic, it is important not to treat testing and production environments in the same way. Testing environments are premised on trial and error, while production environments require stability and management. By having the perspective of "Is this for testing or production?" from the very beginning, it will be easier to organize operations later on.

Start with a small application

AWS is unique in that it allows you to start small and expand gradually. There's no need to migrate a large system right away. Starting with a use case that has a limited scope of impact makes it easier to get a feel for AWS's thinking and operations.

It will be easier to proceed if you think of your initial goal as "understanding as you use it" rather than "creating a perfect configuration."

AWS Basics: What's next?

At this stage, you should have a good grasp of the overall picture and underlying concepts of AWS. The important thing at this stage is not to immediately start building, but to prepare for the next decision.

Points to check before proceeding to specific service selection and construction

Before proceeding with service selection and construction, it's important to confirm your objective: "What do you want to achieve?" The service you choose and your design policy will vary depending on whether you want to create a testing environment or a production system. Rather than jumping straight into comparing individual services, organizing your intended use and constraints will make it easier to make a decision.

Deciding whether to proceed in-house or utilize support

Designing and operating AWS requires a certain amount of knowledge and effort. You need to consider how much of it you can do yourself, taking into account your company's structure and skills.

While it is easy to proceed in-house for verification or small-scale applications, if the operational burden or security requirements are high, there is also the option of utilizing external support. It is important to make a step-by-step decision rather than "should we do everything in-house or leave it all to someone else?"

Link to articles on the design and operation phases

Once you understand the basics of AWS, the next step will be to discuss specific concepts for design and operation.

How to configure it and how to operate it are extensions of basic understanding.

You can deepen your understanding by moving on to articles that cover selecting services based on your purpose, design concepts, and points to note when operating the service.

My Feelings, Then and Now

With AWS, it's important to understand the underlying assumptions before learning specific tools and services. Understanding the basic structure of accounts and regions, the idea that services are used in combination as components, and the premise of pay-as-you-go pricing and operations will help reduce stumbling blocks during learning and testing.

Also, don't try to understand everything from the beginning, but start with a small application. Separating the testing environment from the production environment and understanding operation and management at an early stage will prevent future problems and rework.

AWS basics are not a goal, but a foundation for moving on to the next phases of design, construction, and operation. After organizing the overall picture and thinking, it is important to gradually proceed with utilization in a way that suits your company's objectives and structure.