- Welcome back, and in this lesson,
I want to introduce AWS Accounts,
really understanding what an AWS Account is
and what benefits it provides
is one of the most important things within AWS.
Many students, especially at the start
confuse AWS Accounts with users inside of those accounts,
and I want you to be a hundred percent clear
on the difference.
If you've used AWS before, you might already have an idea
of what AWS Accounts are and how they work.
But understanding accounts to really instinctive level
is essential for a solutions architect, developer,
or engineer.
Simple systems which you design might operate
from within a single AWS Account,
but more complex systems or environments operated
by large enterprises might use tens or in some cases,
hundreds of AWS Accounts,
and for that reason,
it's important that you really understand the features
and benefits provided by AWS Accounts.
Now this might seem pretty basic,
but it's really powerful when you do fully understand it,
and really dangerous to operate at production scale
if you don't.
So let's jump in and get started.
Now this is an AWS Account.
When you're just starting with AWS,
you might only create one of these.
You might even already have one.
Bigger, more complex projects or businesses
will generally use many AWS Accounts.
And in this course,
you're going to use multiple AWS Accounts
for the demo lessons,
and this will help you understand how businesses
actually use AWS in the real world.
At a high level, an AWS Account is a container
for identities and AWS resources.
Identities is just the technically correct way
of referring to things like users,
so the things which you use to log in to systems
such as AWS.
So an AWS Account contains users
which you log in with and resources which you provision
inside of that account,
so keep this idea of an AWS Account being a container
in your mind constantly as you move through the course,
but this is especially important in this stage of the course
where you're going to be creating the AWS Accounts
that you'll use constantly as you move through the content.
When you create an AWS Account,
you give the account and name,
you need to provide a unique email address,
and you also need to provide a payment method,
which is generally a credit card.
So if we're creating a production account,
we might name the account prod for production,
we would use a unique email address
which is unique for this specific AWS Account
and provide a credit card for this production account.
So just to reiterate,
the credit can be used for multiple AWS Accounts,
but the email address can't,
it has to be unique,
you need one unique email address for every AWS Account.
Now the email address that you provide
when creating the account
is used to create a special type of identity
within the AWS Account which is known
as the Account Root User.
So every AWS Account has an Account Root User,
so the Root User of that AWS Account.
In this example, if you create a production AWS Account,
then the Account Root User of that account
can only log in to that one production AWS Account.
If you make another AWS Account,
let's say a developer account,
then that account will have its own unique Account Root User
with its own unique email address,
so those Account Root Users are different.
The production Account Root User
can only access the production account,
and the developer Account Root User
can only access the developer account.
Now initially, the Account Root User
is the only identity, the only user created
with an AWS Account.
So initially, you have the blank account, the container,
and inside that is the Account Root User of that account.
Now the Account Root User has full control
over that one specific AWS Account
and any resources which are created inside it.
Now the Account Root User can't be restricted,
it will always have full access
to everything within that one AWS Account
which it belongs to.
Now this is the reason why we need to be really careful
with the Account Root User,
because if the username and password ever become known,
the results can be disastrous
because the details can be used
to delete everything within the AWS Account.
The credit card that you provide
when you create the AWS account,
that set as the account payment method.
So you can create resources within an AWS Account,
and I'll be covering these throughout the course,
and if those resources have any billable usage,
then that usage is billed to the account payment method,
in this case, a credit card.
I'll talk about this later in the course,
but on the whole, AWS is what's known
as a pay as you consume or pay as you go platform.
If you use a service within an AWS Account for two minutes,
then you pay you for two minutes of that service.
Certain services include a certain allocation
of free usage per month, and this is known as the free tier,
and this is what we're going to take advantage of
in this course to keep costs at an absolute minimum.
So now that I've covered the Account Root User
and billing within an account,
now on to torch on the security
as it relates to AWS Accounts,
so you know that the Account Root User has full control
over this one specific AWS Account,
and this can't be restricted.
Well you can create additional identities
inside the AWS Account which can be restricted.
I'll talk about this more soon,
but this uses as a service called
Identity and Access Management known as IAM.
And with IAM, you can create all the identities
inside the account.
So these can be different types of identities,
we've got IAM users, IAM groups and IAM roles,
and I'll cover these in detail
in the relevant section of the course.
But at this point, it's important to understand
that all of these IAM identities
start off with no access to the AWS Account,
but they can all be given full or limited access rights
over this one specific AWS Account.
So just like the Account Root User,
the IAM service is also dedicated to your account.
So unless you specify otherwise,
any IAM identities created in my account
won't be able to access your account,
only identities which you create inside your account,
and then grant access will be able to access resources
within your AWS Account.
Now later in the course,
I'll talk about how you can do cross account permissions,
but for this point in the course,
just think of AWS Accounts as containers,
only things within the account
can access anything else within that same account.
And another key thing to remember
is that with the exception of the Account Root User,
any IAM identity starts off with no permissions,
you have to explicitly grant permissions
to any identities managed by the IAM service.
Now another concept
which I want you to be really familiar with
is the boundary of the account.
So on screen now, the orange line around the account,
think of this as a wall,
it can keep things inside the account from getting out
and also keep things outside the account from getting in.
AWS Accounts are really good at containing
any damaged caused within those accounts.
So things such as an inexperienced system administrator
doing something silly,
or a bad actor attempting to intentionally harm
your account.
If the credentials for the Account Root User are leaked,
then these could be used to delete everything
inside that one specific AWS Account.
And if your entire business
runs from that one single account,
then this can be really, really bad.
However, if you create separate AWS Accounts
for different uses,
maybe a development account, a test account,
and a production account, then you can limit the damage.
If you have any credential leakage
or if you have any system admins doing any silly mistakes
causing resources to be deleted,
then generally, these will be isolated
to that one specific AWS Account.
You can also create AWS Accounts for different teams
within your business or even different products
that your business sells.
AWS Accounts are great for keeping bad things inside
one specific part of your AWS environment.
They're also really good for keeping things outside
of that boundary,
by default, all access to an AWS Account is denied.
So unless you configure otherwise,
no external identity is allowed access to an AWS Account.
The exception to this of course,
is the Account Root User of that account
who always has full control.
Now this means that any external identities,
for example, external users are denied by default
if they attempt to access your AWS Account.
Now external identities can be granted access
such as Julie in the middle
if you explicitly want to allow this access,
but the default security stance
is that unless you explicitly allow something,
then no access is allowed to your AWS Account.
So that's AWS Accounts,
they're a crucial part of the AWS product set,
and understanding them to really instinctive level
is important,
whether you're a solutions architect to developer,
ASICS admin or a DevOps engineer,
you need to be comfortable with how to use AWS Accounts
effectively.
In the following lesson,
you're going to create the AWS Accounts
which you'll be using for the duration of this course.
Now I'm strongly recommending that you create
brand new AWS accounts.
Don't make the mistake of trying to use
your existing AWS Account or accounts
because they're likely to be in a pretty bad state.
The longer an AWS Account exists,
the more potential there is for misconfiguration,
and so it's much better to use brand new accounts
for this course.
I want you to learn how to configure all of this
in a correct way using best practices.
So please, go ahead and create brand new AWS Accounts
for this course.
I'll even show you a trick
so that you can use one email account
to create all of the unique email addresses needed
for these multiple accounts,
so it shouldn't take that much in the way of effort.
With that being said, go ahead and complete this lesson,
and then when you're ready,
I'll look forward to you joining me in the next lesson
where we're going to get started
on creating the AWS Accounts for this course.