welcome back to BackSpace Academy. In this lecture I'm going to run through 2
architecture design for solutions architects we'll start by going through 3
the five pillars of a well architected framework those being security 4
reliability performance cost optimization and operational excellence 5
then we'll have a look at an example architecture and then we'll also point 6
to where you can go to find more of these example architectures that you 7
should have a look at before you sit the exam there are a number of general 8
design principles that we should take into consideration when we're doing our 9
architecture we should scale automatically and scale horizontally we 10
don't want to be replacing servers with new servers of a bigger capacity that 11
takes time it's not cost-efficient and it's not the right thing to do we should 12
scale horizontally and do that automatically based on demand we should 13
have production scale testing we should be testing in an environment similar to 14
what we would expect from production we need to automate our creation and 15
replication of systems obviously to make it easier to tear down and recreate 16
systems using services such as cloud formation we need to allow for 17
evolutionary architectures making sure that our design is not set in stone and 18
that we are flexible to new technology as it comes in because AWS is very much 19
an evolutionary service data driven architectures we need to take away the 20
emotion about what services we choose for example you know you might want 21
Oracle or you might want no sequel as a database service so you need to make 22
sure that the data that you're using drives that decision and and to make 23
sure that you use data to drive improvement going forward as well 24
you should also regularly simulate simulate your events in a production 25
environment and a good example of that is chaos monkey now that is a an open 26
source project that created by net six and if you go to the 27
Netflix github repository for chaos monkey you can download that and install 28
that on your infrastructure and what it does it it will basically go inside your 29
infrastructure we running around shutting down instances and basically 30
creating chaos inside your environment and we'll be looking to see how 31
resilient your environment is and how quickly those ec2 instances that are 32
shut down I've recreated and back on deck and so that's something that you 33
can do in a production environment we and we certainly database certainly does 34
recommend doing that sort of thing in a production environment if it's far 35
better to do it when it's planned rather than when it's unplanned so the five 36
pillars of the AWS well architected framework we have security we need to 37
protect our information our systems and our assets we need to conduct regular 38
risk assessments of any changes that we make and of any deployments that we make 39
we need to have a mitigation strategies in place if something goes wrong 40
reliability making sure that our infrastructure is 41
highly available it is fault tolerant it is elastic it can cope with changes in 42
demand we need to have good configuration management so that if 43
something does go wrong we understand what the configuration should look like 44
and if there are any changes to configuration we can look at those as 45
being causes of any problems performance efficiency we need to obviously make 46
sure that we're getting the best bang for our buck making sure that our 47
infrastructure is efficient making sure that it can cope with changes in demand 48
and also making sure that it can cope with changes in technology cost 49
optimization reducing costs making sure that we have billing alerts making sure 50
that we have our resources tagged and making sure that we understand where our 51
sub optimal resources are and looking to downgrade those resources or terminate 52
those sources if they're not required and operational excellence making sure 53
that we have a maximum business value from our infrastructure and we 54
continuously improve our architecture we make small gains on 55
a regular basis I mean we do not assume that we have the best architecture 56
available and we make sure that we continuously improve that architecture 57
the design principles that we need for security we need to apply security at 58
all layers not just the firewall we need to also assume that a threat might come 59
from within our own infrastructure our firewall could be penetrated or we could 60
have for example a contractor or a disgruntled employee or someone who may 61
instigate an attack within our infrastructure we need to enable 62
traceability making sure that we know what's going on inside of our 63
infrastructure granting least privilege making sure that people only have the 64
access that they need and nothing more we need to focus on our responsibility 65
to secure our system it is not a WSS responsibility to secure our system it 66
is a shared responsibility model and we need to take responsibility for what we 67
can affect we need to automate our security best practices and those best 68
practices being Identity and Access Management root access don't use it lock 69
those credentials away and don't use them create users groups and roles and 70
make sure wherever possible that you have implemented multi-factor 71
authentication use identity identity Federation when you need access from 72
outside of your system when you need access to a large number of people and 73
you need to control that identity Federation is the best way to do that 74
implement detected controls cloud trail is a great service and for auditing and 75
generating logs of exactly what is going on inside of your infrastructure and you 76
can link that to Kinesis streams and cloud watch alarms you can also link 77
that to further to a lambda function that could implement some corrective 78
action and infrastructure protection so making sure our 79
is secure we have a VPN if needed Direct Connect we can implement a well a if we 80
require and cloud front which is great for denial of service attacks and we 81
should also look at penetration testing but if we do go down the path of 82
penetration testing we need to make sure that we notify AWS that we're going to 83
be doing that so that they don't think that that penetration testing is 84
actually a real penetration attack data protection making sure that we classify 85
our data what is sensitive data what do we need to encrypt and what the window 86
data encrypt what should be public and what should be 87
private how are we going to encrypt our data and how are we going to manage the 88
encryption keys for that implementing version control making sure that if 89
something does go wrong we can always go back to a previous version an incident 90
response marking offending IP addresses in our in our networks access control 91
this for example we can conduct forensics in a clean environment we 92
don't have to use our production environments such we can quarantine an 93
environment and conduct our forensics on that environment we can look at DNS 94
failover in the event that we have a major problem with our infrastructure 95
just looking at the diagram there with kind of shows the different layers that 96
we can implement at the security group level so at the web layer there we've 97
got port 80 and 443 access open to the Internet then we go down to our app 98
server layer which is only permitted to the web server it can access that or 99
from outside only port 22 so SSH into that application server and that would 100
normally be linked to an IP address of of your corporate office network and 101
then we go down to the next layer there is the DB server and that is only access 102
is only permitted to that from the app server and any other traffic there is no 103
traffic over the wide internet that is allowed access to our database server so 104
that's obviously a good practice to intermediate you've got a web 105
application 106
you will hear a lot in discussions with in AWS around reliability reliability 107
you will hear the comment made to design for failure if you design for failure 108
then nothing or fail what that means is that we need to not assume that our 109
infrastructure is bulletproof and that no nothing will cause that the file we 110
need to assume that something is going to go wrong and we need to make sure 111
that we have appropriate mitigation strategies in place for that so the dot 112
design principles around reliability we need to test recovery procedures and we 113
need to make sure that we automatically recover from failure using things such 114
as health checks on our Al B's on our ec2 instances and making sure that we 115
recover quickly from a failed ec2 instance for example we need to scale 116
horizontally to increase aggregate aggregate system availability so if one 117
of those instances taken out is not going to affect the aggregate system 118
overall and we can recover from that easier than if we have a small amount of 119
instances that we're taking out stop guessing capacity we we shouldn't try 120
and predict the future we should be having strategies in place to change our 121
capacity in relation to demand so obviously having cloud watch alarms 122
auto-scaling instances and that sort of thing use 123
automation for changes use cloud formation use elastic Beanstalk use 124
container services but automate those changes and manage those changes within 125
the automation itself the best practices around reliability the foundations 126
making sure that our VPC isolate the environment that we have for testing and 127
make sure we identify the on-premise issues make sure they identified do we 128
have appropriate bad which available for our connection to Amazon Web Services 129
change management making sure that we can respond to changes making sure that 130
when demand exceeds what we expected we had elasticity in place 131
to to react to that making sure that we have a version control about a cloud 132
formation templates making sure that we understand what has changed so we can go 133
back to previous versions we can look at cloud trail logging and we can look at 134
AWS config which details our resources and our configuration changes that have 135
been made to our infrastructure so it's a very good 136
that combined with cloud trail is a very good fault finding 137
resource failure management obviously we need to have a good backup and recovery 138
strategy we need to have highly available and fault tolerant 139
architecture and we need to test we need to test on a regular basis 140
performance efficiency and the design present principles around it are that we 141
need to make sure that we use advanced technologies as a service so Amazon Web 142
service one of the great features of that is that it is a very broad offering 143
and it has some really quite high tech services that are available for you so a 144
good example that would be machine learning for you to actually get 145
something like that up and running and being able to understand the very 146
complex algorithms around that would be quite difficult for you your if you're 147
not a specialist in that area you can go global in minutes you should use service 148
architectures s38 against lambda again you don't have to worry about your 149
architecture then you can have a service environment experimentation again this 150
is all part of they continually improve and experiment with things see what 151
works see what doesn't work making sure that your architecture architecture has 152
mechanical sympathy it is aligned with our business we need to understand what 153
are our business objectives and is this architecture aligned towards those 154
business objectives the best practice is around performance efficiency so 155
selection making sure that we have the appropriate compute resources so what 156
what are we using are we're using instances are using containers are we 157
using lambda functions storage what are the active access 158
messages access methods are using block file or reusing objects patterns of 159
access random or sequential the throughput required the frequency of 160
access the frequency of updates data and the availability and durability 161
constraints that we're working within with databases we need to have a 162
data-driven approach again no emotion there we need the data to tell us are we 163
going to go with no sequel are we going to go with sequel and what is the best 164
solution for us also look at non database solutions using a search engine 165
using an elastic search what using a data warehouse such as redshift and 166
network looking at cloud front using rope 53 for latency routing and also 167
don't forget about Direct Connect certainly the gold standard of 168
networking with Amazon Web Services we need to have regular review making sure 169
that we are up to date with new innovations and releases from AWS and 170
any other applications that are running on our AWS infrastructure we need to 171
monitor we need to use cloud watch we need to have performance metrics and 172
have those performance metrics aligned with what we're trying to achieve and we 173
need to have trade-offs in place so we need to have an optimal approach we and 174
that needs to be variable over time so we don't have something set in stone we 175
need to look at the consistency the durability space versus time latency and 176
what what are we trading off here and what is the best thing that's going to 177
give us the the best bang for our buck in relation to our business objectives 178
that we're trying to achieve cost optimization design principles around 179
that we have a consumptive consumption model we pay as we use it we had 180
economies of scale with AWS it's a great a great tool for that we can really 181
reduce our costs because we're not employing people to look after our 182
infrastructure and we don't have the risk involved in that 183
so again stop spending money on data center operations outsource are 184
completely put it on AWS it just makes sense analyze and attribute attribute 185
expenditure making sure that we have resource tagging making sure that we 186
have billing alerts and using managed services to reduce the cost of ownership 187
so again if we're looking for something like machine learning or one of these or 188
Hadoop or Amazon quick side for analysis these are great many services that will 189
greatly reduce our cost of ownership for that and we have a number of best 190
practices around it so using cost-effective resorts resources and a 191
good example of that is ec2 instances we have a number of different options 192
available there we can we can look at using spot instances to bid on capacity 193
if we find that we don't particularly need something done at this particular 194
time we can do it when when the price is good so don't forget about spot 195
instances matching supply and demand auto scaling making sure that we have 196
cloud watch alarms that we're going to trigger auto scaling events making sure 197
that we have a decoupled environment if we're using sqs for example d to 198
decouple our environment we need to make sure that we're aware of our expenditure 199
again billing alerts and resource tagging and we need to optimize over 200
time making sure that we are fully understanding what the new technology 201
that is out there we're making sure that we're decommissioning resources that are 202
not required and we do that using AWS trusted adviser which is great tool but 203
you should will identify areas that we can improve and resources that we're not 204
particularly utilizing properly so here's a simple example of cost 205
optimization immolation to elasticity so we can see there in the on the on the 206
red line we've got the actual demand and we don't try and predict that in any 207
way to do that we it's not cost-effective for us to try and predict 208
that because it was always going to be an error with that so the blue line 209
there the blue dotted line is a scale-up approach it's our vertical scaling 210
approach and what happens is that when we find that our demand is starting to 211
creep in on our capacity and we are at risk of of having problems because of 212
that we go out and we replace a server with another bigger server and we have a 213
big step change that goes on there the problem with that is that we have a big 214
gap between when we do have that step we have a big gap between our actual demand 215
and what we're then what our actual capacity to service at the mat is so 216
it's expensive to do that it's costly to do that then we can go to a scale out 217
approach and manual scale out approach so we're adding smaller instances as the 218
main increases so we're still going to get that step approach but it's going to 219
be better than scaling out vertically and then we can look at automated 220
elasticity so where we would have an elastic load balancer where we'd have an 221
auto scaling group that would scale out the scaling depending on our demand and 222
so that would actually follow our actual demand and the gap between our capacity 223
that has been implemented from automated elasticity and our actual amande will be 224
significantly less than we will obviously be saving a significant amount 225
of money if we go down with that approach operational excellence and that 226
is the last of the the five deep pillars so the design principle around that 227
perform operations with code don't manually perform operations try and do 228
it with code and then you'll have good version control around it and you can 229
identify what an appropriate configuration is and you can go back and 230
and identify when problems occur so always perform operations with code make 231
sure that you're aligned what you're doing with your business objectives and 232
of course make sure that if you have performance metrics that they are 233
closely aligned with what your business strategy 234
is make regular small incremental changes don't make big changes make 235
small ones but and more of them test for responses to unexpected events and learn 236
from unexpected events and failures and keep your operations procedures current 237
dangerous writer months don't make them in one situation they are a living 238
document and they should be updated and regular updated as our architecture is 239
also regularly updated so best practices around it's like preparation we need to 240
identify problems at the design stage it is far better and far less expensive to 241
fix problems at the design stage it's very easy but to do it after it rolled 242
out in our infrastructure it's far more difficult and explosive exposes us to 243
far more risk we have operations checklists how we're going to run how 244
we're going to operate this and what do we need to check off to make sure that 245
their infrastructure is operated correctly we have run books that clearly 246
detail how to run a mature infrastructure how to operating 247
infrastructure and play books which are what we use if something goes wrong we 248
need to be able to respond if we have a business continuity event we need to we 249
need to look at our play books and see how we're going to mitigate that damage 250
and how we're going to recover from that event and we have cloud formation again 251
making sure that we use cloud formation to to define our architecture is always 252
a good thing in operations making sure that we had a continuous integration 253
continuous deployment environment and making sure that our monitoring that we 254
implement is aligned with our business objectives and in relation to responses 255
we need to automate responses wherever possible using predefined playbooks that 256
will detail what needs to occur when we have an unexpected event and that will 257
include a list of the appropriate stakeholders it'll have the escalation 258
process that we need to go through to make sure the 259
deliver aware of what is going on and also the procedures that are going to be 260
following so I'm just going to finish up here with having a look at a a model 261
architecture for you on AWS reference architecture for a web application so 262
what we've got there if we start if we go from the start we've got Amazon route 263
53 which we're going to use for a DNS resolution for our domain name and then 264
we're also going to have Amazon Cloud Front and that is going to be delivering 265
our resources and static content that's not going to be changing too much we can 266
also use it for our dynamic resources you'll be have a low TTL or else we can 267
just let that pass straight through to our elastic load balancer our elastic 268
load balancer is going to distribute requests across our ec2 instances that 269
we're going to look after our web application layer and they will be added 270
and terminated by an auto scaling group and then we have another layer our 271
application layer and we're going to have an internal load balancer and that 272
internal load balancer will distribute it requests from the web application 273
layer across to again another auto scaling group of application ec2 servers 274
and then those application servers will be able to communicate to an Amazon RDS 275
master database and because it's operating in a multi AZ environment 276
we're going to also have a standby instance there with synchronous 277
replication between it so that is a really good environment that really good 278
architecture that we just use if you are going to implement a web application in 279
your enterprise so there's no point in reinventing the wheel here so there are 280
a number of these reference architectures quite a lot of them and 281
you need to have a look at those and make sure that you understand those 282
because they are what AWS defined as being a good framework for certain app 283
for for certain applications and use cases 284
so those reference architectures will be available at the AWS architecture site 285
so they go to aws.amazon.com slash architecture and that will have AWS 286
reference architectures a whole heap of them so make sure that you have a look 287
at those and understand those before you go ahead with setting an exam it will 288
also have AWS QuickStart reference deployments you won't necessarily need 289
to understand those for the exam but be aware that they are there and they're 290
very very good because you again you're not reinventing the wheel so you want to 291
deploy for example a a MongoDB database with replication or whatever there will 292
be a QuickStart reference to point for that so again have a look at that as 293
well and take advantage of that in your working environment so that's it for 294
architecture as it relates to being a solute certified Solutions Architect 295
associate I will see you in the next lesson