The document discusses how to scale projects using Amazon Web Services (AWS). It recommends following the Twelve Factor Application methodology, with a focus on proper integration of backing services. AWS offers many scalable services, including EC2, S3, RDS, and ElastiCache. The document provides an overview of these services and how to structure applications across multiple AWS resources for scalability and high availability. It emphasizes the importance of configuration, security groups, load balancing, and auto-scaling to build resilient architectures on AWS. While AWS enables scaling, the document warns that costs can increase significantly without proper usage and planning.

1. Projects scaling with
Amazon Web Services
Alexander Torosh
Demio Inc.

2. Alexander Torosh
https://github.com/alexander-torosh
Director Of Engineering
Demio Inc.

3. Projects scaling with
Amazon Web Services

4. Why do we need Scaling?
‣ Support more traffic
‣ Support more active users
‣ Increase system performance
‣ Increase system stability
‣ Do more parallel tasks at once
‣ Increase working speed for users on different continents
‣ And more other reasons…

5. How we can be sure that
our application is scalable?

6. How we can be sure that
our application is scalable?
Twelve Factor Application

7. Twelve Factor Application
‣ Codebase
‣ Dependencies
• Use Composer. Describe all packages, libraries and php-extensions
‣ Configuration

8. Configuration
‣ Dotenv package
‣ Configuration stored in .env file
https://github.com/vlucas/phpdotenv
https://github.com/symfony/dotenv

9. Configuration

10. Configuration

11. Configuration

12. Twelve Factor Application
‣ Codebase
‣ Dependencies
• Use Composer. Describe all packages, libraries and php-extensions
‣ Configuration
‣ Stateless
‣ Backing Services

13. Backing Services
«A backing service is any service the app consumes
over the network as part of its normal operation»
«Treat backing services as attached resources»

14. Backing Services Examples
‣ Databases
‣ Caching systems
‣ Messaging/Queueing systems
‣ File storages
‣ Email/SMTP services
‣ And others…

15. Backing Services Connection

16. Backing Services Abstraction
‣ Use adapters
‣ Use wrappers
‣ Use service classes

17. Abstraction

18. Abstraction

19. Abstraction

20. Bad Example

21. Better Example

22. Database Connection
Use separated Database connection endpoints for Write and Read queries

23. Database Connection

24. File Storage
‣ Create associated entries in database with your files on disk
‣ Save the main file properties to the DB: path, extension, size
‣ Define importance and possible access frequency
‣ Define access rules: public/private
‣ https://min.io/ - Open Source S3 Compatible Object Storage

25. Few more advices
‣ Try to imagine your architecture stack in the future
‣ Check information about the scalability of used backing services

26. Hosting
‣ Bare-metal physical servers
‣ VPS/VDS
‣ Cloud Hosting
‣ Hybrid Hosting

27. Cloud hosting pros
‣ Almost infinite potential for scaling
‣ Easy to manage
‣ Multiple built-in services for load-balancing, traffic security, etc.
‣ Much easier server administration compared to bare-metal servers
‣ Better failover during possible outages
‣ Tools, API, SDK for better apps integration

28. EC2RDSS3 CloudWatch ElastiCache SQS

29. Amazon Web Services
‣ 18 regions
• USA - 4
• Europe - 5
• Asia - 6
‣ Availability Zones
‣ 170 services and sub-services in 23 categories

30. Amazon Web Services
Short review of:
• EC2
• S3
• RDS
• ElastiCache

31. Common Servers Architecture

32. Basic AWS EC2 architecture

33. Elastic Load Balancer
‣ High availability and capacity
‣ Multiple target groups
‣ Built-in TLS/SSL certificate support
‣ Health-Check mechanism
‣ Traffic control by Security Groups

34. Basic AWS EC2 architecture

35. Security Groups
‣ Virtual firewall
‣ Outbound traffic is allowed by default
‣ Rules are permissive
‣ Stateful
‣ Multiple applying

36. Security Groups
Load Balancer Inbound Rules
Load Balancer Outbound Rules

37. Security Groups
EC2 Instance Inbound Rules
EC2 Instance Outbound Rules

38. Security Groups
Strict EC2 Instance Inbound Rules
Strict EC2 Instance Outbound Rules

39. Basic AWS EC2 architecture

40. Health Check
‣ Create some URL endpoint for checking your app health
‣ Use your normal dispatching process - route, controller, action
‣ Exam your most important backing services availability

41. Health Check

42. AWS: one node + services

43. AWS: multiple nodes + services

44. Auto Scaling
‣ Auto Scaling Group
‣ OpsWorks
‣ Elastic Beanstalk
‣ SDK, CLI tools

45. AWS: multiple applications

46. S3 - Simple Storage Service
‣ Storage Classes:
• Standard
• Intelligent Tiering
• Glacier
‣ Permissions
‣ Lifecycles

47. S3 - Simple Storage Service
‣ Care about your buckets regions
‣ Use a reasonable amount of buckets only!
‣ Use different Storage Classes for reducing cost
‣ Use Permissions for better Objects access security
‣ Use Lifecycles for cleaning up and reducing cost

48. RDS - Relational Database Service
‣ Relational database cluster out of the box
‣ Supports:
• MySQL
• MariaDB
• PostgreSQL
• Microsoft SQL
• Amazon Aurora

49. RDS - Relational Database Service
‣ Supports Master-Slave replication
‣ Storage encryption
‣ Automatic snapshots/backups
‣ Automated maintenances
‣ Multi A-Z failover (expensive)
‣ Monitoring
‣ S3 integration

50. ElastiCache
‣ Managed in-memory data store
‣ Supports:
• Redis
• Memcached
‣ Scaling out of the box. Supports Shards and Replicas
‣ Storage encryption
‣ Multi A-Z failover

51. Instance Types
‣ https://aws.amazon.com/ec2/instance-types/
‣ General Purpose
‣ Compute Optimized
‣ Accelerated Computing
‣ Storage Optimized

52. Instance Types
‣ Always use the latest instance type generation, it’s cheaper
‣ Start with small Burstable Performance Instances - T3 family
‣ Care about the network bandwidth of chosen instance type
‣ Run load tests. Analyze received instances metrics
‣ Increase their size or change the instance type
‣ Try to predict your cost https://calculator.s3.amazonaws.com/index.html

53. Reserved Instances
‣ If you plan to use defined instances for a long period of time - reserve it!
‣ 1 and 3 years reservation
‣ Full / Half / No-Upfront offering types
‣ Applies automatically

54. Service Level Agreement
https://aws.amazon.com/compute/sla/

55. Service Level Agreement
«AWS will use commercially reasonable efforts to ensure that each individual Amazon
EC2 instance has an Hourly Uptime Percentage of at least 90% of the time in which
that Single EC2 Instance is deployed during each clock hour.»

56. Be aware of
‣ To get qualify support you should buy Support Plan
‣ Hard to predict cost before the Production launch
‣ Might be extremely expensive in wrong hands
‣ Check your Cost Explorer every month
‣ Sometimes instances just stuck
‣ There is no 100% uptime guaranty
‣ Don’t use just a single instance, scale it

57. Summary
‣ Use Twelve Factor Application methodology
‣ Take care about Backing Services integration
‣ Amazon Web Services is a really great Cloud Hosting with varied services
‣ It might be really expensive due to wrong usage and configuration
‣ AWS is not a silver bullet
‣ Always use horizontal scaling

58. Thank you for attention
https://github.com/alexander-torosh