- Developer Tools
- Management & Governance
We can view the AWS service in the following way
- By Cost
- By Resiliency
- By Security
- By Governance
- By Monitoring
- By Services
Following is just the generalization as per my view.
- Cost is calculated where the cloud subscriber
- use storage
- use compute
- use network for outbound data transfer
eg: AWS Storage family has the cost on basis of storage used, and what kind of storage used [HDD, SDD, IOPS provisioned]
Compute Family on basis of computing resources are running along with lambda
Network, for outbound data, to the internet, to the region, and to AZ as well.
- There are three modal of cost
- Always Free under the limit
- 12 Months free under the limit
- There is a pay-per-use, a monthly bill is generated on the 3rd of every month
- In general, many of the serverless services have an always free tier limit, such as SNS, SQS, SES, Lambda, API Gateway, Cognito, etc, while provisioned resources are paid
- Cost is roughly per minute or per hour round of depend upon service
- You can create an estimation at: https://calculator.aws/#/
- AWS services are focused on resiliency whether zonal failure, regional failure
- AWS serverless services are by default regional in nature, providing a regional availability and those are highly available
- generally, Provisioned resources are in AZ, which provides zonal level availability, To maintain regional level availability, there are options, by which you can apply different types of DR policies according to your RTO and RPO need as well you can maintain HA, like for ec2, there are AMI for backup restore, there is ASG to maintain availability and can set up to use the instance in different AZ, one can deploy Multi-AZ RDS, etc.
- To achieve the regional level DR and HA for the provisioned resources, there is a cost, this is why those are optional.
- One can also apply a multi-region modal for DR policies to avoid regional-level failure downtime.
- AWS provides SLA, different for different services, for availability and durability.
- AWS provides services that can be used altogether to provide operation-level resiliency as
- ec2 can be set up to reboot or auto recover using cloud watch.
- You can define redemtion option under aws config to monitor the change and recover
- You can use route 53 to apply failover rerouting,
- you can also apply health checks to [route53, elb, asg, target groups] monitor, and perform the failover action.
- Runs on a Shared security modal, physical security are with AWS, while authN/authZ and data security are managed by a cloud subscriber
- Authentication is managed by IAM
- Authorization is managed by Policies and roles
- Everything is governed by AuthN/AuthZ, whether single account, interaction among services, multi-account or cross-account, whether it is data at S3 or branch at code commit.
- In general, there are 2 types of credentials. username/password and programmatic credential [accesskey/secret key]. there are 2 others as well, for special services like code commit and Cassandra
- For data [In-rest], all the services provide an option to store the data as encrypted by using AWS KMS [key management service] where the key can be generated by the client and stored at AWS, encryption using keys also has a cost impact as encryption-decryption utilize key
- For -Intransit, all the provision resources are under VPC which is internal to cloud subscribers and secured by AWS, all the outbound should use HTTPS, however, this is not a compulsion. All the AWS server-less services are accessible through HTTPS only. and more into this, you can also create a VPC endpoint for serverless services so that, your resources are available within your VPC.
- All resources are private by default, if you need to make them public, you can do it explicitly, like AMI, volumes, snapshot, s3 bucket etc
- There are AWS services for this, like,
- AWS Config to maintain the complaints
- SSM [System manager] for operations like, run command, patching, etc
- Cloud shell for the in-browser command line tool
- Cloudformation for IAC [infra as code], Elastic beanstalk and Opsworks
- AWS control tower, AWS Trusted advisor
- AWS Organization, for a multi-organization model
- You can interact with or manage the resources by
- Console [browser based interaction]
- SDK [Software Development Kit in multiple lanaguage]
- CLI [Command Line Interface]
- CDK [cloud development Kit]
- Cloud Control API [Unified Rest API]
- Cloudformation/ SAM templates [json/yaml based templte, internally used API]
By Monitoring & Logging
- Cloudwatch is the service for this, which is a unified service for aws resources as well as you can use that on-premise resources
- You can use this service for monitoring, for alarming, for communicating with other AWS services
- You can use Cloudwatch Logging for the logging perspective
- AWS cloud trail is the service to log and insights all the communication with your cloud account whether on Management Plane [managing infra] or Data plane [s3 bucket data], which is governed by AWS
- You can automate the operation using Cloudwatch Events / Lambda, and can use SNS for notification
- Services are categorized by their usage type
- Application Integration
- Business Applications
- Cloud Financial Management
- Contact Center
- Developer Tools
- End User Computing
- Front-End Web & Mobile
- Internet of Things
- Machine Learning
- Management & Governance
- Media Services
- Migration & Transfer
- Networking & Content Delivery
- Quantum Technologies
- Security, Identity, & Compliance
- EFA Elastic Fabric Adapter: EFA brings the scalability, flexibility, and elasticity of the cloud to tightly-coupled HPC applications
- SR-IOV (Single Root I/O Virtualization). SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization compared to traditional implementations
- Yes, Amazon CloudWatch stores metrics for terminated Amazon EC2 instances or deleted Elastic Load Balancers for 2 weeks.
- AWS CDK: cloud development kit: use to launch resource, an abstraction top of cloud formation
- AWS SDK: use to interact with those resources.
- Cloudformation Vs Elastic Benastalk : We can use cloud formation to make resources, where we need to write the code.EB [Elastic Beanstalk], do this thing for use from front end by option and configuration. By EB: one can monitor and configuration can be part of the version management system by having .ebextension file. Elastic beanstalk is more towards application, CF is more towards aws service, as aws service rollback on failure on update the configuration
- AWS copilot is the CLI based automation tool for ECS, where we create a manifest file
- ECS as well as EB, can be fully automated with cloud front.
- Swap url feature [Elastic Beanstalk] can be suitable for two identical env , basically blue/green deployment
- Codedeploy and Opsworks and many other services which utilize agent support on-premise servers, like CW, inspector, etc.