AWS Cloud Practitioner: Architecting for the Cloud Best Practices Part 1

In this short series, I outline the notes that I took while preparing for the AWS Cloud Practitioner exam.

These are my personal notes that I have made while working through the A Cloud Guru exam practitioner course. They are in no way official notes from AWS.

I would advise you that if you do use my notes to help you revise for this exam, that you use them as a supplement to the most recent information in the White Papers, Exam Guide and go over your knowledge with practice exam papers.

Previous notes within this blog series:

Architecting for the Cloud Best Practices: Part 1

Based on the white paper.
Read the white paper before reading the exam

Traditional Computing vs Cloud Computing

IT Assets as Provisioned Resources. Traditional computing would need you to purchase physical resources and install software manually.
Global, Available and Scalable Capacity
Higher Level Managed Services like machine learning using SageMaker
Built-in Security
Architecting For Cost. Can be designed to be more cost efficient for your business needs
Operations on AWS (refactoring and re-architecturing)

Design Principles: Scalability

Scale Up. Increasing the amount of RAM or amount of CPU inside an individual VM
Scale Out. Adding multiple VM behind an ELB

Stateless Applications (forgets the commands) like Lambda
Distribute load to multiple nodes
Stateless Components the more you have the easier ti scales like a signed cookie stored in the user’s browser
Stateful components like storing the information in a db
Implement session affinity like sticky session, stuck to a particular EC2 instance
Implement distributed processing allows you to have a load of EC2 instances that process large, complex amounts of data (like thousands!)

Design Principles: Disposable Resources Instead of Fixed Servers

Instantiating Compute Resources

Bootstrapping scripts. Enables you to install things on EC2 instances directly upon start up
Golden Images. After configuring an image, you are able to use this image to create a new EC2 instance.
Containers
Hybrid. Combination of containers and EC2 instances

Infrastructure As Code

CloudFormation

Design Principles: Automation

Serverless Management and Deployment

Don’t need to worry about infrastructure or individual services like EC2 or RDS just the deployment services like Codepipeline, CodeDeploy.

Infrastructure Management and Deployment

AWS Elastic Beanstalk. You only worry about your code
Amazon EC2 auto recovery
AWS Systems Manager
Auto Scaling

Alarms and Events

Amazon CloudWatch alarms
Amazon CloudWatch Events. Allows your environment to proactively respond to a change in the environment
AWS Lambda scheduled events
AWS Web Application Firewall (WAF) security automation. Automatically respond to someone doing something bad to your site like SQL injection or cross-site scripting. If this is set up in front of your site then this will prevent the attack.

Design Principles: Loose Coupling

Well Defined Interfaces

Amazon API Gateway. Creates your own API and exposed to the public internet.

Service Discovery

Implement Service Discovery. When EC2 instances go down but are connected to RDS using the DNS name and not the IP (when the EC2 instance has multi-AZ turned on), AWS will switch to the other AZ so the outage will be negibile.

Asynchronous Integration

When you have a loosely coupled environment like when you using queues (like RabbitMQ or NSQ or AWS SQS) within your application controller calls it gives your system resilience

Distributed Systems Best Practices

Graceful Failure in Practice. When you provide feedback to your users that you have a failure like showing an error page when pages don’t exist, and a way to tell your SysAdmins that there has been a failure.

Design Principles: Services Not Servers

Managed Services e.g. lambda, s3, route53
Serverless Architectures e.g. Old ACloudGuru architecture