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 PapersExam 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