1. Festival della Tecnologia ICT
Ing. Stefano Dindo
Zero12 s.r.l.
@stefanodindo
Ing. Paolo Latella
Interact SpA
@latellapaolo

2. Chi siamo ??
Ide
an
Fon
3M
dat
eet
up
el 2
on
e3
s009
el 2
011
eve
nti

3. TE
AM
Ing. Stefano Dindo
Zero12 s.r.l.
s.dindo@zero12.it
@stefanodindo
Ing. Paolo Latella
Interact s.r.l.
paolo.latella@interact.it
@latellapaolo

4. Perchè usare AWS per le App
Flessibilità
• Elevata quantità di servizi
• Pay per Use
• Risorse di diverse tipologie
• Strutturare l’infrastruttura secondo
le esigenze di progetto
Scalabilità
• Infrastrutturale in caso di
picchi di traffico
• Delle risorse in real-time
• Elasticità di gestire le risorse
su costi orari
• Risorse disponibili al
crescere del progetto
Varietà di metodi
• Protocollo disponibili: JSON,
BSON, SOAP, REST, HTTP/s,
TCP, RTMP
• SDK di sviluppo Mobile
• Supporto di diversi linguaggi
di programmazione server side:
java, Python, PHP, Ruby

6. Distribuzione Geografica

7. Architettura Amazon Web Services
Servizi “cross”
Servizi basso livello
Strumenti

8. Region
AZ- A
AMI
AZ- B
RDS
o
NoSQL
AZ- C
EC2
EBS
Cloud
watch
Security Groups
S3
Autoscaling
Load Balancer
Web Traffic

9. Architetture Cloud
per le App

10. Per le App il Cloud rappresenta :
il tuo Storage
il tuo Processore
la tua Estensione

11. Il tuo Storage:
SimpleDB
1
IAM
STS
2
S3

13. Instagram Case Study
IAM
STS
Instagram
AZ-A
App Terzi
S3
AZ-B

14. Il tuo processore:
AZ-A
AZ-B
Multi-AZ

15. La tua estensione
Amazon Virtual Private Cloud
VPC Subnet 1
EC2 Instance
for mobile
VPC Subnet 2
AZ - 1
AZ - 2
Connessione VPN
Corporate Datacenter
DB
E-Mail
CRM
File
Server

16. Architetture Cloud
per il Disaster
Recovery

17. €€
€€
RPO
RTO
Disastro

18. Modelli di costo
Ability to scale – no
arbitrary time limit to
failback
Infrastructure Cost
!
Cost savings w/
AWS
Time
!
Test
Test
Failover
Failback

19. Backup e restore - Backup

20. Backup e restore - recovery

21. In Caso di disastro
1.Recuperare l’ultimo backup da S3
2.Avviare le istanze da AMI preconfigurate
3.Aggiornare i volumi delle istanze dal backup
4.Switch del DNS
Obiettivi
• RTO: tempo necessario ad aggiornare i volumi +
tempo necessario ad avviare le istanze dalle AMI
• RPO: tempo dell’ultimo backup

22. Soluzione “pilot light” - preparazione

23. Soluzione “pilot light” - recovery

24. In caso di disastro
1.Avviare (automaticamente) le risorse intorno alle
risorse “core”
2.Scalare il sistema per il traffico di produzione
3.Switch DNS verso la nuova architettura (AWS)
Obiettivi
• RTO: tempo necessario ad avviare le risorse non
core (es. istanze) + tempo necessario a scalare

25. Soluzione warm standby - preparazione

26. Soluzione warm standby - recovery

27. In caso di disastro
1.Switch del DNS verso l’architettura “hot”
2.Scalare il sistema per il traffico di produzione
Obiettivi
• RTO: tempo necessario allo switch + tempo
necessario per entrare a regime
• RPO: dipende dal tipo di replicazione

28. Soluzione multi sito - preparazione

29. Soluzione multi sito - recovery

30. In caso di disastro
1.Isolare l’architettura guasta
2.Scalare il sistema per il traffico di produzione
Obiettivi
• RTO: tempo di identificazione del guasto
• RPO: dipende dal tipo di replicazione

31. www.meetup.com/awsusergroupitaly
do
Ing. Stefano Din
Zero12 s.r.l.
@stefanodindo
Ing. Paolo Latella
Interact SpA
@latellapaolo