| description |
notes |
|
|
| CON361- Deep Dive on Amazon EKS |
|
| CON409 – Running Kubernetes Across Multiple AWS Accounts
slides |
|
| AWS re:Invent 2018: Breaking Observability Chaos: Monitor AWS Cloud Native Apps (DEV311) |
- Monitoring, Logs, Events, Traces
- Align metrics to biz needs
- Include dashboards
- React to failures automatically as much as possible
- Observability: Measure, Detect, Notify, Fix
- X-Ray: Dependency service map, Traces
- X-Ray works not just on lambda, but also containers and other app types
- Monitor everything: services, limits, costs, API interaction
|
| AWS re:Invent 2018: Fully Realizing the Microservices Vision with Service Mesh (DEV312-S) |
- an infra layer for service-to–service
- happy marriage between service and proxy
- Control plane is the proxies
- Auto retry; circuit breaker
- load-balancing
- request routing
- security – auth, encryption
- solves probs of code libs – proxy is an api construct, policy-driven behavior
- policy-driven configs
- audit and enforce continually
- adapt config based on feedback
- testing – chaos engineering
- monitoring: traces, metrics, logs
- fix spotty adoption via auto-instrumentation of all comms
- unified vendor-agnostic target
- standardized collection of RED
- dependency-aware directed triage
- SignalFx supports telemetry from service mesh
|
| AWS re:Invent 2018: How Vanguard Matured IAM Controls to Support Micro Accounts (SEC324) |
- IAM primer: Principals, Authorization
- Permissions Boundary: Limit max perms of principals created by delegated admins – CompanyBoundary example – these are similar to acct-level SCPs – these can be used together
- See also SEC316 – IAM perm boundaries in depth
- Traditional IAM: Audit who is doing what when, where from
- Future IAM: Systematically keep users within their boundary
- Traditional approach: LDAP role 1:1 mapping to IAM role – role sprawl
- Future approach: Create micro-sized accounts
- Declarative networking (PrivateLink) instead of VPC peering
- Indirect mapping to accounts using OU
- New approach: LDAP Role: 1:1: AWS OU – group by child OUs
- IAM Boundaries: explicit denies
- Vanguard “DevOps” person is someone on a dev team, not an IAM or Security admin
- Move IAM deny statements into Permission Boundary – every role subsequently created is subject to permission boundary
- Takeaways: Use permission boundaries; Automate account creation (including Role creation if federating); Give DevOps teams max flex & autonomomy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
26thcentury 