AWS re:Invent 2018 session notes


description notes
CON361- Deep Dive on Amazon EKS
CON409 – Running Kubernetes Across Multiple AWS Accounts


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


%d bloggers like this: