How to Get Started with AWS in 2025

Introduction

What does it need to get started with AWS in 2025? Actually, it's not that hard. But, there are a lot of things to consider.

In this blog post, we will cover the basics of AWS and how to get started. This includes setting up your AWS account, making the most important security decisions and setting up your local machine to work with the AWS API.

We will also cover the best practices and tools to help you in the most efficient way.

AWS Lambda on One Page (No Fluff)

Skip the 300-page docs. Our Lambda cheat sheet covers everything from cold starts to concurrency limits - the stuff we actually use daily.

HD quality, print-friendly. Stick it next to your desk.

Grab the Cheat SheetPrivacy Policy

By entering your email, you are opting in for our twice-a-month AWS newsletter. Once in a while, we'll promote our paid products. We'll never send you spam or sell your data.

Setting Up your AWS Account

First things first: we need to create and verify an AWS account. This is a multi-step journey.

The main steps are:

1. Account Creation & Verification: We'll create an AWS account with an email address. Then, we'll verify the email address. Finally, we'll set up a strong password.

2. Personal & Payment Setup: We'll provide contact information and agree to the terms and conditions. We also need to setup a payment method.

3. Security & Support Configuration: We'll verify a phone number and select a support plan.

It sounds like a lot, but it's actually quite simple and straightforward. Let's dive into the details.

For this, let's jump to the AWS Management Console's register page.

We will need to provide a few details to create an AWS account.

• Email Address: This is the email address you will use to access your AWS account.
• AWS Account Name: This is the name you will use to identify your AWS account.

You'll receive an email with a code that you need to enter to verify your email address.

The provided email address will be used as the root user of your AWS account. This user has full access to your AWS account and is not intended for your daily use. We'll talk about this in a later section of this article.

After entering the code, you'll be prompted to create a password for your AWS account. Please, for the sake of security, do not use a password that you use for other services. With a cloud account, there's comes basically unlimited harm that could be done to your wallet. It's an on-demand unlimited virtual data center.

We recommend using a password manager to generate a strong password. This is a good habit to have in general, but especially for sensitive accounts like AWS.

Next, you'll be asked to provide contact information and agree to the terms and conditions and provide a valid payment method. Don't be scared, you won't be charged anything here. We'll also talk about measures on how to protect your account in the later sections.

In the next step, you'll be asked to provide and verify a phone number.

The final step is to select your desired support plan. As we're just getting started, we'll go with the free plan.

Afterward, your account will be created and you're able to sign in.

The AWS Management Console

Currently, we don't have a dedicated user nor SSO set up, so we need to log in with our root user. We'll tackle that in this section.

Let's select Login with root user and enter our email address and the credentials we just created.

We'll be taken to the AWS Console Dashboard. Let's go straight to the Security Credentials section so that we can start to secure our most vulnerable resource: our root user.

Securing your Account with Multi-Factor Authentication

Why is the root user so dangerous?

• It has full access to your AWS account.
• It can be used to access any resource in your account.
• It can be used to delete your whole account.

We should never use the root user for any purpose besides the initial setup.

Securing your Account with Multi-Factor Authentication

That's why our first action is to set up multi-factor authentication. This way, we have an additional layer of security for our account.

With a multi-factor authentication, each login requires a physical (or virtual) device to generate a one-time password. Let's do exactly that by clicking on Assign MFA device.

We'll be taken to the MFA device setup page. Here, we can choose between a virtual MFA device or a physical MFA device.

If you have a physical MFA device (e.g. a YubiKey) that supports Passkeys, please select Passkey or security key. If you want to use a virtual MFA device, e.g. the Google Authenticator or Microsoft Authenticator app, please select Authenticator app.

In the next step, after entering a name for your device, you'll be either presented with a QR code or with a prompt from your browser to use a passkey.

Please follow the instructions to complete the setup.

In the end, you should be taken back to the Security Credentials page and see your new MFA device.

Creating a Dedicated Administrator User

Now that we have a multi-factor authentication set up, we can create a dedicated administrator user. This way, we don't have to use the root user anymore.

Let's jump to the IAM section to create a new user.

Let's click on Create user.

We need to type in a name for our user. We can ignore the checkbox for AWS Management Console access for now. We'll tackle that later on.

In the next section, let's create a group for our user. This way, we decouple the user from their permissions.

Let's click on Create group.

We need to type in a name for our group. We've called it administrators for now. To keep it simple, we'll add the managed policy AdministratorAccess to our group. This way, our user will have full access to all resources in our account.

After we've created the group, we can add our user to it and then jump to the next section. By clicking Create user, we've finished the wizard and we have our first user.

In our overview, we can see that we have a user with the name administrator.

Let's click on it to set up our console credentials. This can be done in the Security credentials tab.

Let's click on the corresponding button to enable console access. Afterward, we can set our own password for the user.

In the final modal, we can see our new credentials and also the login link.

Let's copy the login link and log out of our root user.

From now on, we'll use our new user to access the AWS Management Console.

Budgets and Billing Alerts

We’ve already discussed this, but it’s worth repeating: there is no enforceable spending limit for your AWS account. Small start-ups have reported horror stories about exploding costs. This can be due to endless loops in event-driven architectures, high NAT Gateway data traffic, or exploding logs resulting in terabytes of ingested logs at CloudWatch.

However, there are ways to protect yourself from costs that get out of control:

AWS provides its Free Tier, which allows for exploring services without paying much or anything. There are pricing calculators to help estimate costs more accurately. You can set up Alarms for cost estimations that cross-defined thresholds. This is something that you definitely should not skip.

You will always pay for incurred costs. We have encountered many people who strictly avoid learning anything about the cloud. They are afraid of unexpected costs at the end of the month.

Let's get into the action by jumping to the Budgets Section of AWS and click on Create budget.

AWS Budgets will create alerts if cost thresholds are exceeded. AWS also calculates the future costs of your account via estimates based on current and previous usage.

By selecting the Use a template option and then Monthly cost budget, we can create a budget for our account. If the threshold is breached, either via the already incurred costs or the forecasted costs, we'll get an email alert.

The alerts are not in real-time as forecasts are only updated at time intervals. But they will nevertheless inform you via email if your predefined spending limits are or will be breached.

The Billing Dashboard

Before starting hands-on with any service, it’s a must to get familiar with its pricing structure.

• Are there any upfront costs?
• Are you charged per hour, per usage, and/or per induced traffic?

It’s critical to have a rough estimate of what you’ll pay. There’s no need to get into the deepest levels and calculate costs for every day, week, and month.

But as with other areas of life, if you’re not aware of your spending, you’re wandering in the dark, and you can easily get an unwanted surprise at the end of the month.

Let’s have a look at popular services and their pricing structure:

• CloudWatch The cost per used GB of storage is comparably low, but the ingestion of logs can be expensive. If you’re logging extensive JSONs, be sure to not escalate with debugging or trace levels, as ingested gigabytes of logs can quickly add up and contribute significantly to your bill.

• Lambda You’ll see that you’re charged per GB-seconds, which is not an intuitive declaration at all. This means that you’ll pay for your Lambda function per executed second, but dependent on your Lambda function’s provisioned memory. In other words, with the Free Tier of 400,000 GB-seconds, you can execute a Lambda function with 1 GB of memory for 400,000 seconds, or roughly 6666 minutes, or 111 hours, or 4.6 days. Equally, if you’re running a function with 10 GB memory, you’ll be charged after only about 11 hours of execution. Even though it’s expected at first, higher memory settings don’t have to increase your bill. We’ll explore this deeply in the Lambda chapter.

• DynamoDB You’ll pay for used storage and reads and write operations. In addition, it depends on whether you want to have on-demand or provisioned capacity. On-demand means you’ll only be charged for actual usage, so each read and write, while provisioned will introduce fixed costs as long as your table exists, but include all read and write operations. Both modes have certain advantages over the others depending on your usage patterns. As with all core services, we’ll talk about pricing in the corresponding chapter.

As seen, it’s often not easy to make a rough guess about costs as the pricing structures differ from service to service.

Practical advice is to regularly check your billing dashboard - weekly or bi-weekly - to get a better feeling of how costs evolve and which services significantly contribute to your bill.

Another good way is to keep a look at your Cost Widget that's shown by default on the console root page.

Cost Allocation Tags

AWS Cost Explorer allows you to gain deep insights into your cost structure. It enables you to drill down features by service, region, resource, or even instance type. With one glance, you can determine which services contribute the most to your bill and where you could improve cost optimization.

Another major feature offered by Cost Explorer that brings even more flexibility is Cost Allocation Tags. These tags can be defined to measure the costs per component level or any granularity you want as you decide how to structure tags and where they will be applied. It’s a perfect tool to get detailed insights into your cost structure.

You’ll find out which parts - regardless of whether it’s a component, sub-component, a certain cluster of services, or anything else - of your infrastructure heavily contribute to your costs.

AWS Free Tier & Pricing

Almost all core services offer a certain amount of free usage for either the first 12 months or every month.

Famous free-tier offerings include:

• Lambda: 400,000 GB-seconds of execution. For small-sized Lambda functions, this results in several weeks of non-stop running. We’ll explore how the metric "GB-seconds" is calculated in the next paragraph.

• API Gateway: 1 million HTTP requests, which is quite a lot for starters and enables you to run and expose many small-scale applications for free.

• DynamoDB: 25 GB of storage and 25 Read & Write Capacity Units. A must for Serverless and Lambda fans, which covers a significant concurrency for your application’s database access.

• S3: 5 GB Storage, 20,000 GET, and 2,000 PUT requests. As S3 is part of nearly every application, this is another generous Free Tier that allows you to go deep with S3.

• EC2 and RDS: Both with 750 hours of running certain micro instances. If you do the math, this allows you to run such a micro instance for the whole month without getting charged at all.

Certainly, this is just a small fraction of the offerings, but they are the ones that matter the most. AWS regularly increases the Free Tier limits for many services. Therefore, it’s always worth checking the current state of the offerings. Especially for services that are managed and Serverless (not directly using containers or virtual machines, but only paying for your actual use without any upfront costs), you can do a lot without spending a dime in the first place.

Preparing our Local Machine for the AWS API

Generally, we don't want to manage AWS resources directly from the AWS Management Console. Instead, we want to either use the AWS CLI or better an Infrastructure as Code (IaC) tool like Terraform, AWS CDK or Pulumi.

For either of it, we need to set up credentials on our local machine so we can use the AWS API.

The AWS CLI

The AWS CLI is a command-line tool that allows you to manage AWS resources from your terminal. Generally, it's only an abstraction layer over the AWS API.

If you're using macOS, you can install the AWS CLI using Homebrew.

brew install awscli

For Linux, you can use your built-in package manager.

sudo apt-get install awscli

For Windows, you can use the AWS CLI Installer that you can download from the AWS website.

After installing the AWS CLI, you can configure it by running aws configure.

aws configure

It will prompt you to enter your AWS Access Key ID, Secret Access Key and Region.

• AWS Access Key ID: This is the access key ID for your AWS account.
• Secret Access Key: This is the secret access key for your AWS account.
• Region: This is the default region you want to use for your AWS account. You're not restricted to this region, but by default it will always fall back to this region.

Let's jump back into the console to create our credentials. For this, we need to go back to IAM and our created administrator user.

Let's click on the Security credentials tab and then on Create access key.

Next, we'll use Command Line Interface (CLI).

AWS will mention that this method is deprecated and that it's better to either use the CloudShell or authentication through SSO via the Identity Center. For simplicity, we'll stick with the CLI for now. We'll dive into Identity Center and AWS Organizations in the next sections!

With a click on Create access key, we'll be presented with a modal to download the access key.

Let's copy both the access key ID and the secret access key. You can also download the provided CSV file.

Now we can get back to our local machine and continue with the configuration of the AWS CLI. Let's put in the access key ID and the secret access key we just copied. For the default region, we'll use us-east-1.

After finishing the setup, we can test if everything is working by running aws sts get-caller-identity.

aws sts get-caller-identity

You should be presented with a JSON response that includes your AWS account ID, user ID, and ARN. If this is the case, we've successfully set up the AWS CLI.

Infrastructure as Code (IaC)

Infrastructure as Code (IaC) is a way to manage your infrastructure using code. This means you can define your infrastructure in a file (or better multiple files) and use that file to create and manage your infrastructure.

Our recommended tools for IaC are:

• Terraform - The most popular IaC tool.
• AWS CDK - The AWS-native IaC tool.
• Pulumi - The multi-cloud IaC tool.

Each of them has their own advantages and disadvantages. It's on you to explore them and find the one that fits your needs best.

AWS Organizations and SSO

As you work with AWS, you might need multiple AWS accounts. Each AWS account is separate from others. This separation provides security benefits.

AWS Organizations helps you manage multiple accounts from one place.

AWS Organizations provides these features:

• Account Management: You can create and manage multiple accounts in one place. You can move existing accounts into an organization. You can create new member accounts from a single location. You can add automation rules for account creation.

• Consolidated Billing: Member accounts send their bills to the management account. Each AWS account still gets its own Free Tier.

• Cross-Account Policies: You can apply permissions and compliance policies across accounts. You can control them from one place. You can enable access between accounts.

• Identity Federation: AWS Organizations manages identities and permissions across the organization. This includes connecting to external identity providers for Single Sign-On.

The identity federation part is more complex. With AWS Identity Center, you can connect to external identity providers like Azure AD or Okta. You can also connect to corporate directories like Active Directory. This enables Single Sign-On for your users. You can manage users and groups through the Identity Center. This means you don't need IAM users in every account.

Here are the main concepts of AWS Organizations:

1. Management Account The management account is the account that created the organization. It has full access to all AWS resources and services. Due to its unlimited permissions, use it only for initial setup and account management tasks.

2. Organization An organization is a container for multiple AWS accounts. It lets you manage all accounts from one central place. You can apply policies and permissions across all accounts.

3. Organizational Units Organizational units group accounts together. Each unit can contain accounts and other organizational units. This lets you structure applications, projects, or organizational layers.

4. Service Control Policies Service Control Policies (SCPs) restrict access to AWS resources and services. You can apply them to an organization, organizational unit, or individual account. SCPs help you apply permissions across accounts. They help you meet compliance rules. They help you enforce security setups.

5. Consolidated Billing With Consolidated Billing, all member accounts send their bills to the management account. The management account can access all billing and account information. This includes member account activity within the organization. This simplifies the billing process. It gives you insights into your organization's spending.

6. Centralized Root Access Management AWS Organizations can manage root access for member accounts. This means you can safely delete root credentials from member accounts. This is a key security feature of AWS Organizations.

The organization's root user can manage each member account without restrictions. You don't need to worry about losing access to member accounts.

Security Best Practices

Let's wrap up some security best practices we've already learned and extend them with some new ones.

1. Lock Down Your Root User This is the most important step. It includes that you delete all access keys immediately, enable MFA and store the password in a secure vault. Please do not re-use your root user password for any other purpose.

2. Make use of AWS Organizations For multi-account setups, use AWS Organizations. This way, you can manage the root access of your member accounts from a single place. Make sure to the delete the member accounts' root users.

3. Delete Default VPCs Everywhere you wish to deploy your infra AWS creates default VPCs in every region. They're overly simple and rarely needed. Clean house: if you're not using them, delete them.

4. Block S3 Public Access One toggle prevents most S3 data leaks. Apply at the account level, override it only when needed. A public S3 bucket is one of the most common ways to create incidents.

5. Enforce EBS Encryption by Default Protects against accidental unencrypted volumes. Zero performance impact, maximum peace of mind.

Helpful Tools and Resources

The cloud development journey is a long one. Luckily, there are a lot of tools and resources making your life easier.

Obviously, this is a non-exhaustive list.

Leapp.cloud - Easily Working with Multiple AWS Accounts

Leapp.cloud is a powerful tool that simplifies working with multiple AWS accounts. But it's also very usable for a single account, as it makes it easy to switch between roles. It's definitely the recommended tool for any work with AWS.

Awesome AWS - A curated list of AWS resources

Awesome AWS is a GitHub repository that curates the best AWS resources, tools, tutorials, and documentation. It's an excellent starting point for finding community-vetted solutions and learning materials for AWS services.

AWS FinOps Dashboard - A dashboard to track your AWS costs

The AWS FinOps Dashboard is an open-source solution that helps you monitor your AWS spending. It provides detailed cost analytics, budget tracking, and insights where costs are coming from. Instead of having to dig through the AWS console, you can use a single-command dashboard to get a great overview.

Find more resources on our Resources Section!

Conclusion

Yes, it's not super easy to get started with AWS. But it's not that hard either.

We've covered the basics of AWS and how to get started. We've also covered how implement the best practices and tools to help you in the most efficient way.

Now, it's time to get your hands dirty and start building something.

AWS Lambda on One Page (No Fluff)

Skip the 300-page docs. Our Lambda cheat sheet covers everything from cold starts to concurrency limits - the stuff we actually use daily.

HD quality, print-friendly. Stick it next to your desk.

Grab the Cheat SheetPrivacy Policy

By entering your email, you are opting in for our twice-a-month AWS newsletter. Once in a while, we'll promote our paid products. We'll never send you spam or sell your data.