 working on cloud, working very good on AWS, so good, remaining are my audience. I have a good number of people to tell about. Okay, part of this portion will be we will only take how you log in into AWS, okay, how you access AWS service, we will not talk about the authentication authorization for the applications and all that thing. It will be only to AWS, okay. When you create AWS account, okay, you have a privilege to create an organization out there. Organizations can be assumed as any organizations where you have multiple department, so you can make an account as organization, so that will shift into management and the remaining you can add for each, you can define it depending on the organizations how exactly they take AWS into their day-to-day activity. They can for each department, they can have a separate account, okay, or for specific product, they can do internal bifurcations where they will have accounts and all the associate service will be linked into it, our resources and service out there, okay, to better manage use OU, which is the options out there where you can define in OU that this specific account will be used for for example XYZ project or for the department and you can do that. Inside the OU you can have multiple account, best example for accounts or environment, DEV, UAT or PROD, which you can do out there, so when you create an account, okay, there will be two things which you have to do, first thing the account which you have created it will be a root account, when you create a root account, okay, the standard advisory is to don't use an individual's account, for example for XYZ reason, he leaves the organizations, you will have trouble managing that specific AWS account, so the best advisory is you create a generic group and a generic mail ID and create that account with that, for example if it's a project and it's for the DEV environment, the DEV, then project name and that mail ID, so create accounts based on that, so when you create account there are two things you can, when you create you have to always create with the ID which is given by AWS, but you are given a provision to give a proper namespace for that, so you can change the name as per your convince out there, second when you create account or root account, once the root account is created you can create users, you can create roles, you can create policies, as well as if for example your organization which you already have users out there, you already have a user out there, so in this case you can integrate that specific users inside AWS, we call it predated users, you can have a requirement where your activity will be done by certain application, for example a lambda, that will be representing or working out there, that is one thing, any service which go and authenticate, when you go to any applications, you give your user name and password that become a user, in AWS term we call that as a principle, a principle will be the person who will be approaching out there, okay, in IAM you can have principle as a user, for example any employee of your organization or any individual like myself, if I create an account I will be the first user, second will be a role, you can define a role and assign that role and work on top of that, third the predated, just like if you have a Google account you can integrate with Google out there, if you have a Facebook you can integrate with that, most of the organization use actor directory which is the common for most of the organizations to work out there, fourth is applications or lambda functions where you can use them to authenticate and work on resources or the current buzzword, automations out there, why you want to access that account to use AWS resources, okay, so there are multiple resources in AWS which you can use out there, which can be easy to instance, which you can use, it can be S3 bucket, this can be database, RDS, it can be S3, there can be multiple, all the services and applications are provide by AWS, you can consume out there, when you are consuming out there you want to authorize out there, authorization out there, what you want to do is what permissions should that specific resources should have, how exactly or what privileges you should give and utilize out there, okay, that you do with the help of policies, so when you define policies in AWS, there are multiple way of defining policies, but we will be covering majorly four, one is identity based policies which will be the user, the principle which we have created, this principle, it can be user, role of added or applications, we can define, give the policies out there, second will be these are limited, resource based policies are very restricted for certain resources, just like S3 bucket which is also allowed to be accessed from internet, you can deploy a static website with the help of S3 bucket, so search specific cases, we can use S3 resource based policies, in case of Dynamite DB, you can also use resource based policies out there, third is permission boundary, in case of permission boundary, what you exactly do is for example, I have been given a role to be, to manage my department, I should not have privilege to go into other account or other department and start accessing out there, so by default, there is permission boundary, if you are given a permissions, you can maximum give the permission to your department, if you give permission more than your department, AWS will block it, the fourth is service control policies, service control policies is more about restricting, we normally call as SCP, in SCP, we define this in AWS organizations, where we define this specific account, for example, it's a dev, so when developers are working on it, you want to scope them, that they can only use low end resources, they should not start consuming high end resources, there are probably, you might be knowing or not, one of the developer have, so there is, when you are accessing, you can access with username password or you can use the access key and secret, one of the developers have checked in the ID and the secret on GitHub, which have been used by the user to hack and do the bitcoining mining and will have went into very high, so that's where one of the reasons you should scope on, there is other way of managing it, you can have billing, where you can have monitoring on top of that to restrict out there, but as part of security, it doesn't command out there, so there are, as we are managing AWS, we are managing AWS two ways, one, when we go to AWS website and login and work, we call that as AWS management console, second via CLI or via API, that is called as via code, when you're programmatically accessing out there, so when you're accessing from AWS management console, it's called action, when you're using CLI or using SDKs, we call that as operations, once we create account, as we see in the organizations that we can create accounts for multiple accounts, when from one account, we want to try to access another account, we have to build a trust relationship between them, if the trust is not built out there, you cannot make connection to that account and work on top of that, so if anybody have worked on AD or any, any authentication out there, so from one AD, if you're trying to access other AD, you have to build at least one way trust, if you build one way trust, you can have the access of the other AD and get the information same out here, if you are from one account trying to access other account and want to perform actions on top of that, you have to have a trust relationship out there, so if you see the red dots, that's highlight out there, so what we have discussed, now come to a real case, where there will be, when we create AWS account, we will first have principles, principle will make a request to access certain services, when the request happen, we will go to the authorizations which will check what policies does this current user have, does either the policy will be or identity based policy or resource based policy, it will also validate whether there is CSCP applicable on that specific resources, do we have to restrict that, do permission boundary applicable to that specific resource, yes or no, that comes authorizations, next part is what action you are going to perform, right, are you just going into that, you are going to create a EC2 instance, are you going to create a custom RDS, do you have the privileges, so when you come to action, when you're requesting that I want to create a EC2 instance, it will check whether you have the policies to perform that actions or not, okay, so you are making an actions to specific resources, check whether the authorizations is there based on the user, second is when you are working in organizations will have multiple accounts out there, each account will be linked to the other accounts, very fast, here comes question answers, you can drop in I think, 15 minutes, I am fast, yep, questions, okay, no questions, thank you.