Security:
AWS Shared Responsibility Model:
The AWS Shared Responsibility Model suggest that the AWS is responsible for security of the cloud and customers are responsible for security in the cloud. That means AWS will take care of the underlying hardware's security essentially about the Data Centers. So that no data is being Stolen from there and Customers responsibility is to ensure that Any unknown person not enter into there system from outside from any Vulnerabilities through Operating System, Client-Requests, etc., . AWS can't do anything to your data inside the resources after being provisioned. If some vulnerabilities are found inside a recent version of Windows AWS cannot patch those by reducing the version of Windows, Most-of that they can do is, Give a notification to your operations team.
AWS Identity and Access Management (IAM):
Suppose you have a coffee shop and It has many different employees working with their separate tasks assigned to them. They cannot do anything else, for example a person working on the inventory computer system, so that person cannot access the login of the accounts computer system. But as the owner of your coffee shop you have the access of everything inside your coffee shop.
Similarly AWS IAM works, You can assign different people in company as they can do whatever is in their scope of work. A person X can only create and work with EC2 instance and Cannot go onto the billing section and make some changes.
When you create a AWS account, what you get is a root account which by default has every damn permission inside the AWS account. So you don't wanna give that to anyone what you must do is create Users, Groups and Roles for them to get the access.
Users is a section which when created for the first time has the least privilege access that means he/she has no access to anything, You exclusively have to give the access for everything. This can be a good thing to keep everything separate.
Groups are basically the grouping of people which have the common permission defined in a the IAM Policy. This is good when a few people do same tasks in you organization, grouping them helps in setting a permission one time and can change without and hustle.
An IAM role is an identity that you can assume to gain temporary access to permissions. When a person has several tasks to do into different sections of account he/she can be given an IAM role.
Before changing to a new IAM role, permission to make that change is needed. When the change happens, old permissions are given up for the new role's permissions.
AWS Organizations:
When you start with just one AWS account and as the company expands you end up having a bunch of entangled sets of account in your Organization. So in order to manage all of them AWS Organization is the key. You can use AWS Organizations to consolidate and manage multiple AWS accounts within a central location. You can create various sections called as Organizational Units. Let's take an example and understand it, So you can make a OU of Finance team and IT team because many times they need to access each others information and other OU can be of the HR and Legal team.
Distributed Denial of Service Attack (DDoS) and Its Prevention by AWS:
A denial-of-service (DoS) attack is a deliberate attempt to make a website or application unavailable to Legitimate users. In a distributed denial-of-service (DDoS) attack Multiple sources are used to start an attack that aims to make a website or application unavailable. This can come from a group of attackers, or even a single attacker. The single attacker can use multiple infected computers (also known as “bots”) to send excessive traffic to a website or application.
AWS Shield Standard automatically protects all AWS customers at no cost. It protects your AWS resources from the most common, frequently occurring types of DDoS attacks. As network traffic comes into your applications, AWS Shield Standard uses a variety of analysis techniques to detect malicious traffic in real time and automatically mitigates it.
Monitoring and Analytics:
The monitoring and analytics are important because, it helps you to track everything that is going on with your resources such as, EC2 instance, AWS Lambda Function, etc., . How they are scaling according to the traffic, At what time the traffic is more. So AWS provides various tools for Monitoring and Analytics, lets get to them one by one.
Amazon CloudWatch: Amazon CloudWatch is a web service that enables you to monitor and manage various metrics and configure alarm actions based on data from those metrics.
CloudWatch uses metrics to represent the data points for your resources. AWS services send metrics to CloudWatch. CloudWatch then uses these metrics to create graphs automatically that show how performance has changed over time.
CloudWatch alarms: With CloudWatch, you can create alarms that automatically perform actions if the value of your metric has gone above or below a predefined threshold.
For example, suppose that your company’s developers use Amazon EC2 instances for application development or testing purposes. If the developers occasionally forget to stop the instances, the instances will continue to run and incur charges.
CloudWatch Dashboard: The CloudWatch dashboard feature enables you to access all the metrics for your resources from a single location. For example, you can use a CloudWatch dashboard to monitor the CPU utilization of an Amazon EC2 instance, the total number of requests made to an Amazon S3 bucket, and more. You can even customize separate dashboards for different business purposes, applications, or resources.
AWS CloudTrail: AWS CloudTrail records API calls for your account. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, and more. Recall that you can use API calls to provision, manage, and configure your AWS resources. With CloudTrail, you can view a complete history of user activity and API calls for your applications and resources. Events are typically updated in CloudTrail within 15 minutes after an API call. You can filter events by specifying the time and date that an API call occurred, the user who requested the action, the type of resource that was involved in the API call, and more.