Please enable JavaScript.

Coggle requires JavaScript to display documents.

ACA (VPC (advantages of multi VPCs (instead of 1 VPC): -configs can be…

- - - - use automatic scaling
        
        performance efficiency, reliability
  - - - performance efficiency, reliability, cost optimisation
  - - - operational excellence
  - - - operational excellence, reliability
  - - - operational excellence, performance efficiency
  - - - operational excellence
- - - - Automating your infrastructure (Module 5)
        
        automation means less human errors for 100% reproducibility and no human intervention required in case of failures
        
        CloudFormation - human readable source code as json or yaml (markup language = list of tags that mark and give meaning in a certain context) that gets interpreted by the CloudFormation engine to automatically launch stack of resources and create an environment
        
        Templates mean you can repeat and parallelise (run at same time) + can use parameters to slightly vary each time you run (eg. dev/test/prod params) + mapping for different contexts (eg. regions) cos mappings are keys and their associated values so they specify conditional parameter values + updating possible without creating a new stack from beginning + good for recoverability -> HA
        
        Blue-green deployment = blue area is where customers are connected; with changes, make them to green area and if you’re happy with how the changes are like after implementation, direct customers to green area now; green area now becomes the blue area and the areas switch
        
        scripts can act as documentation and they're always up to date
        
        Infrastructure as code = infrastructure not as hardware; define your infrastructure in code form cos code is extensible, changeable and reusable => repeatability for dev/prod for eg + maintainability, consistency and parallelisation
        
        Other options for infrastructure as code other than CloudFormation; have differing levels of convenience vs control (most convenient and least control at top)
        
        AWS Elastic BeanStalk
        
        automated deployment and scaling service
        
        infrastructure as code for web environments
        
        can be used for blue/green deployment - easier than CloudFormation for this purpose which requires using 2 stacks
        
        AWS OpsWorks
        
        config management service
        
        Amazon EC2 run command
        
        helps with administering, automating and manage resources
        
        Third-party applications on Amazon EC2 instances
        
        Run automation solutions on EC2 like Salt and Chef
      - tagging resources for easier searches and accounting at micro levels
  - - - DDoS is more of a threat with more IP addresses -> reduce with Elastic IPs and LBs
      - obsfucate through hiding (by putting something in front like intermediaries) eg. Route 53 can obfuscate where the source data is coming from
    - - Amazon Inspector - scans environment and looks for common security compliance/vulnerability
      - AWS Shield - protection against DDoS attacks
      - VPC Flow Log - logs of all traffic from inside the network
      - GuardDuty - To know how to attack, need to run software for finding out where things are and what they are - GuardDuty helps with this eg. port probes; monitors for suspicious activity
  - - - fault tolerance is higher bar than HA; it's also a factor of HA
      - 2 AZs is best practice but no need if instance is not likely to be overwhelmed
      - AWS managed has HA
      - High Availability (Module 3 + 4)
        
        having services across AZs and regions ie. redundancy
        
        Load balancing
        
        distributes traffic over EC2s and IPs (on-prem or virtual) so they aren't overwhelmed and can deal with high traffic (automatically scales too); can also send metrics to CloudWatch
        
        session id for stickiness that allows servers to remember ip addresses and login status (esp of mobile users) created by lb
        
        if instance is unhealthy, doesn't send requests to it
        
        HA within a region
        
        Route 53
        
        HA across regions
        if you have multiple systems that can be pointed to from route 53
        
        Domain name service to resolve to IP addresses
        
        distribute loads between regions - can be based on latency, weights, location or health checks
        
        no single point of failure ie. redundancy
        
        Elastic IP
        
        HA within region (like LB)
        
        If an EC2 instance went down, connect to another while keeping IP address
        
        Auto scaling policy
        
        Scale out early, scale in slowly
        
        Scaling group = instances that get scaling policies applied to
        
        EC2 Auto Recovery
        
        Managed by AWS is HA (eg. S3, RDS, EBS, DynamoDB, ELB) but EC2 and VPC are not AWS managed
        
        replaces impaired EC2 (eg. loss of network connectivity or system power) automatically; for failure with a legacy app that can have only 1 instance OR if you want to maintain same metadata or storage volume as auto scaling doesn't ensure this
        
        Scaling DBs
        
        Sharding = sharing load among DBs; dividing data into chunks
        
        RDS - scales automatically cos AWS managed
        
        horizontally scale with read replicas by replicating asynchronously
        
        Lambda
        
        event-driven scaling = scaling events can trigger lambda functions so that you can make API calls to other AWS services
        
        HA = minimising downtime, without need for human intervention; about availability to end users; need to balance with cost though so may just be about reaching an acceptable level you set eg. Recovery Time Objective (RTO) for how long you can afford to be down and Recovery Point Objective (RPO) for how much data you can afford to lose
        
        design with the fact/assumption that everything fails all the time
        
        Factors of HA
        
        Scalability (accommodating growth while keeping design; increase or decrease resource depending on demand)
        
        CloudWatch and Autoscaling to automatically launch instances under certain conditions; CloudWatch metrics tell you if you need scaling and notifications trigger scaling
        
        Autoscaling
        
        prevent provisioning to peak capacity and guessing capacity
        
        need to set when (policy), where (which AZ), what (type of instance)
        
        ELB, CloudWatch and Autoscaler work together
        
        Recoverability (restoring after catastrophe)
        
        Fault tolerance (built-in redundancy of app; whether it avoids single points of failure)
        
        Decoupling your architecture (Module 6)
        
        Decoupling can be achieved by adding intermediaries - don't make sense from efficiency pov but makes sense if you're designing with failure in mind
        
        decoupling = pulling apart things so that if one breaks, the other doesn't; minimising dependencies and adding intermediaries; about services rather than servers
        
        services include microservices which do one thing - opposite of monolithic architectures; serverless solutions instead of using persistent servers
        
        2 more items...
        
        intermediary includes ELB + Simple Queue Service (SQS) cos then process A just sends while process B just receives instead of communicating directly + putting partitioned data (assets) into S3 or Dynamo DB to break dependency within web server
        
        coupling = something talks directly to something else; no intermediary
        
        loosely coupled = not dependent on each other; even if one fails, the other is ok; design architecture with interdependent components ie. intermediaries
        
        scaling becomes easier because done by intermediary + no need to worry about connecting to multiple things as you would if you have a tightly coupled architecture
        
        Loose coupling with queues (SQS): recovery operations are easier (cos even if the instance fails, job remains in the queue and can be processed once an instance is back) and processing in parallel is possible
        
        Loose coupling with API Gateway: create APIs for backend services using API Gateway
        
        Loose coupling with serverless architectures (lambda): AWS Lambda is compute power that you do not have to manage ie. don't have to manage (including scaling) an instance for it. AWS Lambda allows you to further decouple your infrastructure by replacing traditional servers with simple microprocesses. Lambda handles queueing and polling as well as processing, scaling and load balancing
        
        Decoupling can be achieved by making everything as serverless as you can
        
        LB, Auto scaling, 2 AZs
  - - - Point of diminishing returns with vertical scaling cos for eg. more memory means more garbage collection required in java environment. Better to horizontally scale to achieve the same processing power.
  - - - CloudWatch can monitor the instance but not how the app on the instance is performing - need to do through custom metrics
- - - - randomise first 3-4 letters (hash prefixes) of file so that s3 performs quickly as the load is distributed with randomised names; s3 partitions buckets according to prefixes ie. first 3-4 letters
      - secondary index can help with more easily retrieving files
    - - CDN for delivering cached content to edge location (data centres)
      - If the content is not currently in that edge location, CloudFront retrieves it from an Amazon S3 bucket or an HTTP server—for example, a web server—that you have identified
    - - NoSQL DB good for temporary data like session data and game scores; SQL good for long-term or semi-permanent data; NoSQL is more flexible and scalable than SQL
        
        DynamoDB is AWS managed NoSQL DB that uses key and attribute
        
        RDS is AWS managed DB for relational data (SQL)