13. Review: EC2 Standard Networking
Distinct private/internal and public/external IPs
• Simple model
• True 1:1 NAT (no port translation)
• “Split-brained” DNS
Security groups control ingress
Elastic IPs: fixed public IPs
14. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
Availability Zone 1a Availability Zone 1b
15. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
Availability Zone 1a Availability Zone 1b
Customer 1
16. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
10.1.2.3 10.218.5.17
10.141.9.8
10.16.22.33
Availability Zone 1a Availability Zone 1b
Customer 1
17. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
10.1.2.3 10.218.5.17
10.141.9.8
10.16.22.33
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2
18. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.141.9.8
10.99.42.97
10.16.22.33 10.131.7.28
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2
19. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.141.9.8
10.99.42.97
10.16.22.33 10.131.7.28
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3
20. Internet
EC2 instances dynamically assigned private IP addresses
from the one large internal Amazon IP address range
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.243.3.5
10.8.55.5 10.141.9.8
10.99.42.97 10.155.6.7
10.16.22.33 10.131.7.28
10.6.78.201
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3
21. Internet
EC2 instances dynamically assigned public IP addresses on
border network from Amazon’s public IP address blocks
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.243.3.5
10.8.55.5 10.141.9.8
10.99.42.97 10.155.6.7
10.16.22.33 10.131.7.28
10.6.78.201
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3
22. 23.20.151.66 23.20.146.1 23.20.103.11 72.43.2.77 23.19.11.5 72.43.22.45
Internet 72.43.22.5
23.20.148.59 72.44.32.9 72.44.21.7 23.19.10.51 72.43.1.7
EC2 instances dynamically assigned public IP addresses on
border network from Amazon’s public IP address blocks
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.243.3.5
10.8.55.5 10.141.9.8
10.99.42.97 10.155.6.7
10.16.22.33 10.131.7.28
10.6.78.201
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3
23. Value and Limits of Standard Networking
Simple to use and management free
Security groups are Ingress only
Different from subnet-based controls
Mental model issue
No private networking, DMZs, or NAT/PAT
No consistent / “fixed” IP addresses for instances
24. Introducing AWS Virtual Private Cloud
User-defined virtual IP networking for EC2
Private or mixed private/public addressing and
secured ingress/egress
Re-use of proven and well-understood
networking concepts and technologies
25. VPC Capabilities in a Nutshell
User-defined address space up to /16
• 65,534 addresses
Up to 20* user-defined subnets up to /16
User-defined:
• Virtual routing, DHCP servers, and NAT instances
• Internet gateways, ACLs, ingress/egress security groups and VPN
tunnels
Private IPs stable once assigned
Elastic Network Interfaces
26. Internet
VPC customers can launch instances in their own isolated network
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.243.3.5
10.8.55.5 10.141.9.8
10.99.42.97 10.155.6.7
10.16.22.33 10.131.7.28
10.6.78.201
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3
27. Internet
VPC customers can launch instances in their own isolated network
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.243.3.5
10.8.55.5 10.141.9.8
10.99.42.97 10.155.6.7
10.16.22.33 10.131.7.28
10.6.78.201
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3 VPC Customer
28. Internet
VPC customers can launch instances in their own isolated network
10.134.2.3
10.1.2.3 10.218.5.17
10.27.45.16
10.243.3.5
10.8.55.5 10.141.9.8
10.99.42.97 10.155.6.7
10.16.22.33 10.131.7.28
10.6.78.201
Availability Zone 1a Availability Zone 1b
Customer 1 Customer 2 Customer 3 VPC Customer
29. Internet
VPC customers can launch instances in their own isolated network
Availability Zone 1a Availability Zone 1b
VPC Customer
30. Internet
VPC customers can launch instances in their own isolated network
Availability Zone 1a Availability Zone 1b
VPC Customer
32. Internet
You can assign your own IP range to the VPC network
10.0.1.5 10.0.1.6
10.0.0.5
10.0.0.6 10.0.1.8
10.0.3.5
10.0.1.25
10.0.3.17
Availability Zone 1a Availability Zone 1b
VPC Customer
33. Models of Data Centre Extension
Isolated project
Expand existing systems into the cloud – no public
Expose systems to the public - hosted in the cloud
Branch office access
34. Isolated Project
Dev/Test. Corporate
Users
Proof of Concept.
“Fail Fast” projects.
Time bound/ephemeral. Router & Firewall
No need for internal system access of
resources.
AWS
35. Expanding Existing Systems Into The Cloud
Leverage additional processing nodes. Corporate
Host entire stack in the cloud with secure
data centre Corporate
Users
LAN/WAN access.
• E.g. Sharepoint, CMS, CRM, etc
Dev/Test. Router & Firewall
Disaster Recovery.
Big Data analysis. VPN Connection
Use existing management tools.
No Internet access to systems.
AWS
36. Expanding Systems Into The Cloud, with Public
Internet Access
Enable access by customers/partners to Corporate
systems. data centre Corporate
Users
Enable internal systems to be involved
and accessed by applications.
Router & Firewall
Secure segregation of components and
network access. VPN Connection
Customers/
Partners
AWS
37. Branch Office Access
Branch Office Users
Enabling remote users & offices Router & Firewall
to have secure access to
resources. VPN Connection
Centralised systems with
minimal infrastructure. AWS
VPN Connection VPN Connection
Router & Firewall Router & Firewall
Branch Office Users Branch Office Users
43. Corporate
Data Center
Availability Zone 1
Corporate
Headquarters
Availability Zone 2
New Enterprise IT AWS Region
Network Architecture
44. Corporate
Data Center
Availability Zone 1
Router
Corporate
Headquarters
Amazon VPC
Availability Zone 2
New Enterprise IT AWS Region
Network Architecture
45. Corporate
Data Center
Availability Zone 1
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Amazon VPC
Availability Zone 2
New Enterprise IT AWS Region
Network Architecture
46. Corporate
Data Center
Availability Zone 1
Private Subnet
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Public Subnet
Amazon VPC
Availability Zone 2
New Enterprise IT AWS Region
Network Architecture
47. Corporate
Data Center
Availability Zone 1
Private Subnet
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Public Subnet
Amazon VPC
Availability Zone 2
New Enterprise IT AWS Region
Network Architecture
48. Corporate
Data Center
Availability Zone 1
Private Subnet
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Internet Public Subnet
Gateway
Amazon VPC
Availability Zone 2
New Enterprise IT AWS Region
Network Architecture
49. Corporate
Data Center
Availability Zone 1
Private Subnet
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Internet Public Subnet
Gateway
Amazon VPC
Availability Zone 2
Branch Offices
New Enterprise IT AWS Region
Network Architecture
50. Corporate
Data Center
Availability Zone 1
Private Subnet
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Internet Public Subnet
Gateway
Amazon VPC
Availability Zone 2
Branch Offices
Elastic
New Enterprise IT
S3 SQS/SNS/SES SWF SimpleDB DynamoDB
Beanstalk
AWS Region
Network Architecture
51. Corporate
Data Center
Availability Zone 1
DirectConnect
Location
10G
Private Subnet
Router
Customer VPN Gateway
Gateway
Corporate
Headquarters
Internet Public Subnet
Gateway
Amazon VPC
Availability Zone 2
Branch Offices
Elastic
New Enterprise IT
S3 SQS/SNS/SES SWF SimpleDB DynamoDB
Beanstalk
AWS Region
Network Architecture
52. Rich Capabilities in VPC
Elastic Load Balancer, AutoScaling, CloudWatch, Alarms
Relational Database Service (MySQL engine, for now)
Elastic MapReduce
CloudFormation
And many others, with more to come…
“Blackbox” services with public endpoints reachable via
Internet gateway (or VPN via your own network)
53. Dedicated Instances
Option to ensure physical hosts are not
shared with other customers Single Tenant
Compute Instance
$10/hr flat fee per Region + small hourly
charge
Can identify specific Instances as
dedicated
Optionally configure entire VPC as
dedicated
54. DirectConnect: Private X-Connect to AWS
Dedicated bandwidth to AWS border
network in 1Gbps or 10Gbps chunks.
Full access to public endpoints, EC2 Internet
standard & VPCs.
• VLAN tagging maps to public side or VPCs
Benefits:
• Faster / more consistent throughput
• Increased isolation and control
Great companion technology to VPC.
55. 15 Daily Newspapers
50 Web Sites
62 MM unique users per month
Over 1 Billion page views per month
59. “The AWS Cloud brings business agility as Shell is able to
deploy services much more quickly”
Johan Krebers
Vice President of Architecture
Use of AWS Business Benefit
Global oil and gas company. No minimum commitment up front and pay
per use brings significant savings.
Operationalizing their cloud strategy.
Fast provisioning within minutes for many
Shell Foundation Platform – an IT applications.
framework – is AWS approved.
Elasticity – the ability to expand and
Core operational applications running in contract IT infrastructure as needed.
production on AWS.
Development and test environments
running on AWS.
33
70. Migrating to the Cloud Cloud
Benefits
Zero upfront investment
On-demand provisioning
Instant scalability
Auto scaling and elasticity
Pay as you go
Removes undifferentiated
heavy lifting
Developer productivity
Automation
71. Migrating to the Cloud Cloud
Benefits
Zero upfront investment
On-demand provisioning
Cloud Strategy Instant scalability
Auto scaling and elasticity
Pay as you go
Removes undifferentiated
heavy lifting
Developer productivity
Automation
72. Migrating to the Cloud Cloud
Benefits
New Zero upfront investment
Applications On-demand provisioning
Cloud Strategy Instant scalability
Auto scaling and elasticity
Pay as you go
Removes undifferentiated
heavy lifting
Developer productivity
Automation
73. Migrating to the Cloud Cloud
Build a Cloud- Benefits
Ready Design
New Zero upfront investment
Applications On-demand provisioning
Cloud Strategy Instant scalability
Auto scaling and elasticity
Pay as you go
Removes undifferentiated
heavy lifting
Developer productivity
Automation
74. Migrating to the Cloud Cloud
Build a Cloud- Benefits
Ready Design
New Zero upfront investment
Applications On-demand provisioning
Cloud Strategy Instant scalability
Auto scaling and elasticity
Existing Pay as you go
Applications Removes undifferentiated
heavy lifting
Developer productivity
Automation
75. Migrating to the Cloud Cloud
Build a Cloud- Benefits
Ready Design
New Zero upfront investment
Applications On-demand provisioning
Cloud Strategy “No brainer to
Instant scalability
move” Apps Auto scaling and elasticity
Existing Pay as you go
Applications Removes undifferentiated
heavy lifting
Developer productivity
Automation
76. Migrating to the Cloud Cloud
Build a Cloud- Benefits
Ready Design
New Zero upfront investment
Applications On-demand provisioning
Cloud Strategy “No brainer to
Instant scalability
move” Apps Auto scaling and elasticity
Existing Pay as you go
Applications Removes undifferentiated
heavy lifting
Planned Phased Developer productivity
Migration
Automation
77. “No-brainer to move” Apps
• Dev/Test applications
• Self-contained Web Applications
• Social Media Product Marketing
Campaigns
• Customer Training Sites
• Video Portals (Transcoding and
Hosting)
• Pre-sales Demo Portal
• Software Downloads
• Trial Applications
78. Cloud Migration : a Phased-driven Strategy
http://aws.amazon.com/whitepapers
79. A Bridge to the IT Capabilities
Your Business Needs
Website precis: \nThe AWS Virtual Private Cloud (VPC) is fast becoming the networking option of choice for enterprise and government customers because it provides a powerful set of virtual networking capabilities. VPC allows you to isolate, control, connect, and empower your systems at the network level. Did you know that, for example, that VPC allows you to attach a single EC2 instance to multiple private subnets? To create DMZs, control subnet routing, and enable totally private interconnects with your on-premises systems? To deploy dedicated, isolated, single tenant hardware for your virtual machines within the public cloud? Come learn about the extensive set of features specific to VPC that you should know about before your next cloud deployment.\n\n1360x768\n
Short on power\n
Short on space\n
Need more processing capacity\n
Have some new ideas you want to try\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
Data egress charges are a measure of the packet flows across the public IP address at the network edge (i.e., gray lines in the slide), even if the packets return into EC2. Internal to internal traffic and internal to AWS service endpoints traffic is all free. \n\n[Will add more valid public IPs to the animation later]\nExample valid ranges:\n216.182.224.0/20 (216.182.224.0 - 216.182.239.255) 72.44.32.0/19 (72.44.32.0 - 72.44.63.255) 67.202.0.0/18 (67.202.0.0 - 67.202.63.255) 75.101.128.0/17 (75.101.128.0 - 75.101.255.255) 174.129.0.0/16 (174.129.0.0 - 174.129.255.255) 204.236.192.0/18 (204.236.192.0 - 204.236.255.255) 184.73.0.0/16 (184.73.0.0 – 184.73.255.255) NEW\n
\n
“User-defined” is important because it can be a private OR a public address space. If public, must be routed to/from customer gateway / VPN tunnel.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Shell’s Cloud Journey: Operationalising the cloud strategy\n Shell started provisioning AWS services in April 2010 \n The Shell Foundation Platform – an IT framework – is AWS approved\n That means that the Center of Excellence has a pre-approved framework that allows LOBs to deploy cloud-approved applications onto AWS\n The Shell Foundation Platform is a framework used by all new projects utilizing on-demand cloud services. The SFP is certified to run on AWS. Compliant applications built on the SFP are able to be run in production on AWS. \n Development and Test Environments are considered AWS ready within a VPC and may run on AWS\n Core operational applications running in production on AWS\n The business is dived into upstream (research, extraction, production) and downstream (distribution and sales) applications\n Shell is running a number of downstream applications – enterprise applications that operate the retail business – in production in the AWS Cloud\n Shell is running several development and test environments in the AWS Cloud\nComments: \nOne of the major enterprises using AWS is Royal Dutch Shell, the global petroleum company. Shell IT has strategically decided to incorporate cloud computing as a core practices in his IT department. Shell contemplate the benefit of public cloud computing and AWS, and Shell IT management state clearly that “everything that makes sense to run in the cloud should be just running in the cloud”. Shell is using AWS (especially EC2) services since April 2010 and has a running contract with Amazon and a very close cooperation with AWS team. \nThe usage of AWS has progressively increased at Shell in the last 2 years. AWS deployment obviously did not happen overnight, and after a careful analysis of the types of applications and analyzing cloud risks Shell is expanding the usage of AWS in diverse types of applications enterprise wide. \n-----------------------------------------------------------------------\nGovernance and risk management central to Shell’s approach:\n A Cloud Governance Group with stakeholders from different business lines was created.\n Shell conducted thorough security analysis, with access to AWS certifications, to meet legal and regulatory requirements for hosting applications in the cloud.\n A Center of Excellence was established to build expertise in cloud capabilities.\nAs a large organization with strong IT standards, Shell needed to establish governance processes to ensure that the cloud computing effort was aligned with IT policies. Shell created a Cloud Computing Governance group with exec level stakeholders from every major division. On a regular basis the group evaluates the cloud computing implementation status at Shell and make sure that usage is in the right direction.\n Shell did an extensive evaluation of AWS security practices, AWS security experts engaged with Shell discussed extensively on security in order to meet Shell expectations, AWS also provided to Shell the SAS70 report of AWS audited by an external firm. \nShell created as well a Center of Excellence which is the AWS resource department within the company. The Center of Excellence provides AWS services to end users (a very divers setting of projects and applications) within Shell specific context. They provide startup services, training, consultancy and additional managed services to their customers who can benefit from AWS and still being safe in the Shell of IT context.\nShell uses AWS for a diverse set of use cases:\n The Shell Foundation Platform is a framework used by all new projects utilizing on-demand cloud services. The SFP is certified to run on AWS. Compliant applications built on the SFP are able to be run in production on AWS. \n Development and Test Environments are considered AWS ready within a VPC and may run on AWS. \n Shell has a diverse set of applications running in production and development on AWS across the entire company.\n Three production applications running in AWS; first live October 2010\n Widely used for temporary requirements and Development and Test\n Cost advantageous for smaller applications and at parity for many others\n Up to 40% of the applications portfolio passed initial viability screens for production deployment on AWS\nThe usage of Shell is in many and diverse scenarios setting ranging from development and test to applications in productions within different business units.\n At Shell standards are important; they have frameworks of software which are reused in every project at Shell. These foundation frameworks provide functionality to do effective project management and delivery within the Shell . Shell has adapted this framework to AWS EC2, and therefore upon the release of a new project the common foundation functionality is ready within minutes to the project team. \nDev and test is a very interesting use case at Shell as well. The project manager and developers can have test environments ready in seconds in a safe area within Shell using the AWS VPC service. This dramatically decrease the development cycles and increase quality of applications. \n-----------------------------------------------------------\nBenefits of Amazon Web Services for Shell: \n No minimum commitment upfront and pay per use brings significant savings.\n Fast provisioning within minutes for eligible applications.\n Elasticity – the ability to expand and contract IT infrastructure as needed.\n Cloud brings business agility as Shell is able to deploy services much more quickly.\n \nShell benefits from the flexibility of AWS pay per use model. They are able to provision the infrastructure required within seconds and the Cloud Competence Center provides AWS services to end users with Shell specifics. Shell obtains with AWS agility in his business and users can deploy services much more quickly than before bringing significant savings in the IT expending. \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Applications that are very interesting, easy to experiment with, simple sel\n
The Blueprint offers a step by step approach to cloud migration and has been proven successful. When customers will follow this blueprint and focus on creating a proof of concept, they will immediately see value in their proof of concept projects and see tremendous potential in the AWS cloud. After they move their first application to the cloud, they will get new ideas and will want to move them into the cloud.\n